Using Bookable Resources in Dynamics 365 | Project Service Automation

Welcome to Part 2 of my Dynamics 365 Project Service Automation (PSA) blog series for this year. For this post, I’m going to focus on why you should and shouldn’t create a Bookable Resource as a User Resource Type, and how to get Resources created as Users. If you haven’t had a chance to review Part 1, read it here: Qualify a Lead into Dynamics 365 PSA the Right Way.

Dynamics 365 PSA allows you to setup Bookable Resources in Dynamics 365 (D365) as the following options:

• Generic
• Contact
• User
• Equipment
• Account
• Crew

However, there is one distinguishing factor to consider when creating the resources as Users. That factor is: will you have your resources enter their own time for Projects and Project Tasks by logging into D365? If so, they will all need to be created as User Bookable Resources. If they are created as a Contact/Account, when they are later setup to enter time – you will have two Bookable Resources for the same person.

With that being said, this introduces a “gotcha” in your PSA implementation. The Resources will need to get created as Disabled Users first before the Bookable Resource record is created, in order to reference the right User lookup value. If an anticipated Resource is already an active User, then you will not have to worry about setting them up before creating the Bookable Resource record.

If you are an organization that has a large number of subcontractors and you have someone else within your organization that enters the time for them via portal or manual entries, then you wouldn’t have to consider creating them as User Resources.

So say I’ve decided my anticipated Bookable Resources will need to enter time for themselves, what are the proper steps to get this done? Unless you’re a small organization and you only have a handful of resources, you’re looking at at least some level of data migration. These next set of steps are CRITICAL. Otherwise, you’re going to have the wrong Bookable Resource created and potential duplicate data.

The following steps will show you how to create the User as a Disabled User. When you are ready for them to enter time, you can assign the proper license. I advise creating them as a Disabled User, since the subcontractors will not need a license when they aren’t on a project.

• When migrating your Disabled Users to D365, make sure the User Name matches the Primary email to the rest of your organization DIRECTLY. This determines which Users created in D365 are unique because it maps to the Windows ID as the GUID (Globally Unique Identifier).

• Use the following table columns to migrate the Disabled Users:

First Name

Last Name

UPN (Primary Email) XXXXX@domain.com

UserID (Primary Email) XXXXX@domain.com

Owner

• You can also migrate the following columns if you have the information, but the columns are a MUST:

Title

Personal Email

Mobile Phone

Main Phone

• If you are using the CRM Import Wizard, you can use the following mapping scheme:

Things to take note of before migrating Disabled Users:

• You cannot delete a Disabled User, only deactivate them.
• Again, it is CRITICAL to make sure the UPN/UserID match the Primary Email and User Name of the User record.
  • When later this User (Resource) needs to get created in Office 365 to assign them a D365 PSA license, Office 365 syncs with D365 by User Name and Primary Email.
• Make sure the Disabled User you create does not have any symbols or characters as I mentioned above, or you won’t be able to delete them.

This seems like a lot of work, however; it’s necessary work so you and your organization aren’t dealing with duplicate records and a big data overhaul. Happy PSA’ing! Please contact us if you have any questions about Dynamics 365 Project Service Automation.