Dynamics 365 Project Service Automation: Project Approval delegation on project level

Tested on:
Dynamics 365 version 9.0.2 (web client)

While Time Entries can be delegated in Dynamics 365 Project Service Automation, Project Approvals work differently. To approve Time and Expense entries, one must have Project Approver set to Yes under the related Project Team Member record. A Project Approver can then approve all submitted Time and Expense entries for a project.

While it’s certainly possible to simply add a user directly as a Project Team Member, I decided to explore a different approach. What if I just wanted a simple list of Project Approvers. A list where I could add Project Approvers as needed and remove them when they’re no longer needed. Say someone needs to jump in as an approver for a few weeks while the person primarily responsible for approvals is on vacation. What would be a simple way to achieve this? I decided to solve this by using a custom entity and by setting simple cascading rules.

The logic in a nutshell:
– Adding a delegate record adds a user on a Project as a Project Team Member with Project Approver = Yes.
– Deleting a delegate record removes a user from Project Team Members on a related Project.
– Deleting a Project or a Project Team Member sets a delegate record status to Inactive.

1. Create a custom entity with relevant fields

Create a custom entity and set the entity metadata according to your business requirements. I have also created two custom fields called From Date and To Date. In step 3 you need to define from and to dates for a Project Team Member record so it is handy to define them while creating a Project Approval delegate record.

If you want to build on this example and idea, you could define additional logic for the From Date and To Date by, for example, automatically removing a delegate record when a To Date is exceeded.

Custom entity PSA Approval Delegation

Custom fields From Date and To Date on the custom entity

2. Create entity relationships

After a new custom entity has been created, relationships between the relevant related entities are also required. The name of the custom entity in this example is PSA Approval Delegation. It can be a good idea to set cascading so that that you are not left with extra, irrelevant records in Dynamics 365 Project Service Automation if your Project Approval delegate records are removed.

I encourage you to test how cascading affects other entities before deciding on relationship behavior between entities. Dynamics 365 Project Service Automation is a pretty fine tuned system so testing is recommended to avoid clashes with PSA’s pug-ins. For more information on entity relationships, see here.

Primary Entity Related Entity Relationship Relationship Behavior
PSA Approval Delegation Project Team Member 1:N Parental
Bookable Resource PSA Approval Delegation 1:N Referential
Project PSA Approval Delegation 1:N Referential

When the entity relationships are ready, place the new lookup fields on the custom entity’s main form. Your form should now look similar to the one shown in the image below. Project and Delegate are Business Recommended. From Date and To Date fields are Business Required as the values on these fields are copied to a Project Team Member record in step 3.

3. Create a workflow that creates a new Project Team Member record

When a new PSA Approval Delegate (remember this is the custom entity created) record is created, a workflow creates a new Project Team Member record. I have created this workflow as a synchronous workflow to get immediate results in my demos. Note that the workflow is fired off only when a new record is created.

Before the properties for this workflow are set, the Calendar Id (msdyn_calendarid) field is to be set as Optional and a lookup field to the custom entity is to be placed on the Project Team Member main form (in this example the lookup is named Project Approvals Delegate Record). Note that even though Allocation method (msdyn_allocationmethod) is an Optional field, it’s necessary to provide a value to that field so that a Project Team Member record can be created. I have set Allocation method to None and I’m user the OOTB Team Member as a value on the Role field.

4. Create a workflow that sets the status of a Project Approvals Delegate record to Inactive

A second workflow will set an Project Approvals Delegate (again, this is the custom entity) record’s status to Inactive when the related Project or Project Team Member record is deleted. This way you won’t have an irrelevant active record for a delegate if the related Project or Project Team Member record is deleted (deleting a Project naturally always deletes all related PTMs).

I hope this brief article gives you ideas on how to set up delegates for Project Approvals. With some additional customization this idea can be taken a bit further especially when it comes to cascading and additional automation on end dates for delegates.

All my blog posts reflect my personal opinions and findings unless otherwise stated.