Project Templates in Dynamics 365 Project Operations

Back in Project Service Automation, we got used to Project Templates and to reusing them in our daily work. Default sets of Work Breakdown Structures (WBS) with predefined estimates provided us with a lot of different project templates for every project manager’s need.

With the new Project Operations, this feature no longer exists, but there are work-arounds to get it back.

Back in the Project Operations preview phase, we recognized the missing project templates as an issue every customer would ask about and thought about a way to bring them back. We came across the Copy Project Function where the user clicks on the Ribbon in an existing Project and a copy including WBS elements was created.

There is also a Microsoft article how this can be used with code to provide Project Template functionality.

Developer code is good and functional, but for each prototype or customer demo we needed a friendly way of implementation. Therefore, and because it was asked so many times how to implement and use project templates again, we will explain how to bring them back using cloud flows.

Dataverse customization

As a first step, we need to add our Customizations to support a project template functionality.

For this, we will add a Flag to mark Projects as templates, to filter them on Views, add a Sitemap Navigation and add a Project Lookup to reference our Template data.

Project Entity

First, we will add a lookup from Project to Project (self-reference) and call it Project Template.

As a second step, we will add our Bool flag to mark a Project as a Template. The default option will be “no” to ensure that we create Projects by default.

Project views

To get a better understanding of what templates and what projects are, we need to add new views to filter our data. With the new field “is template” this is very easy. Simply copy (save as) an existing view and adjust the filter properties to show either projects or templates.

Project form

Use any form of your choice. In our sample, we created a new one; don’t be surprised that it is from a Playground instance and will not look like the default one at all.

In the form, we place our new Fields and change the used view for the project template lookup to use our “All Project Templates” view. This will ensure that we do not use a project. If you like, projects will also work, but we want to keep a clean line between Template data and Project data. We will explain the handling of Template data or Project data in the Cloud Flow Section.

Project Copy and Project Columns

In each customer environment, it is required to add new fields and logic to the project entity. All the new fields are not known to the out-of-the-box function of Project Operations.

To resolve that, Microsoft added a special View called “Copy Project Columns” to the project entity. All the added fields in this view will be considered by the Copy Project function.

So, when you need to add custom fields for the template, do not forget to add them to this view.
This is also the case when you have to use the Copy Project function as it is, based on new custom fields at the project entity.

Cloud Flow

Our main logic will be handled by the Copy Project functionality provided by Microsoft. It is a Project Operations Action, and we can call it by using code or via Cloud Flows. A workflow should work as well, but this is something we haven’t tested.

Project from Template Flow

We create a new Flow and set our Trigger to Dataverse Create. To use the Copy Project Action, a Project needs to exist, so in our process flow we create the new Project in Dataverse and set at Template in the related lookup Field to trigger our new logic.

We can add a trigger condition, so the Flow is only triggered when a Template is set; using Filter row will have a similar result. The steps to enter are very straight forward, select your Entity, Scope, Filter rows and Run as as desired.

When we export the Cloud Flow and check the JSON file, this part would look like this:

 "triggers": {
     "Project_with_Template_created": {
         "type": "OpenApiConnectionWebhook",
         "inputs": {
             "host": {
                 "connectionName": "shared_commondataserviceforapps",
                 "operationId": "SubscribeWebhookTrigger",
                 "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
             },
             "parameters": {
                 "subscriptionRequest/message": 1,
                 "subscriptionRequest/entityname": "msdyn_project",
                 "subscriptionRequest/scope": 4,
                 "subscriptionRequest/filterexpression": "_promx_projecttemplateid_value ne null"
             },
             "authentication": "@parameters('$authentication')"
         }
     }
 }

Now, as a final step, add the Bound Action to the flow and select “project” as entity and “CopyProjectV3.” Now the action will change and display tons of fields; don’t be surprised, this is normal when using actions.

At the Row ID, we need to set the ID of the “Target” Project we just created.

Use search to find “projectid” in the huge list of project fields and set the ID of the “Source” Project Template we want to use provided in our new created Project.

At the bottom of the bound action, we will find two option fields to define the Copy Project logic to be used. We are using Project Templates where we already defined Generic Resources to have a predefined set for the Project Manager. In that case, we want to keep the assigned Team Members and also want to keep the Generic Resources holding our Role and Resourcing Unit information.

When we export the Cloud Flow and check the JSON file, this part would look like this:

"actions": {
     "Create_WBS_from_Template": {
         "runAfter": {},
         "type": "OpenApiConnection",
         "inputs": {
             "host": {
                 "connectionName": "shared_commondataserviceforapps",
                 "operationId": "PerformBoundAction",
                 "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
             },
             "parameters": {
                 "entityName": "msdyn_projects",
                 "actionName": "Microsoft.Dynamics.CRM.msdyn_CopyProjectV3",
                 "recordId": "@triggerOutputs()?['body/msdyn_projectid']",
                 "item/SourceProject/msdyn_projectid": "@triggerOutputs()?['body/_promx_projecttemplateid_value']",
                 "item/ClearTeamsAndAssignments": false,
                 "item/ReplaceNamedResources": true
             },
             "authentication": "@parameters('$authentication')"
         }
     }
 }

Copy Project Parameters

We have two options in the Copy Project Action. They define the logic applied when WBS is created.

• {“clearTeamsAndAssignments”:true}: The default behavior for Project for the Web; it will remove all assignments and team members.
• {“removeNamedResources”:true} The default behavior for Project Operations; it will revert assignments to generic resources.

At the Cloud Flow, we can find them at the bottom of the bound action, which will look like this:

Here we can decide if we want to create a blank WBS without assignments or if we want to use the Generic Resources instead.

The Options are also handy when you want to use an existing Project where we could have staffed Members. Then we can toggle to create our new Project WBS by using Generic Resources or without anything, and only create Project Tasks (WBS) without Team Members or Resources on them to let the Project Manager start planning from scratch.

Conclusion

The copy-project function in Project Operations is very handy for different scenarios. We introduced the use of Project Templates, but there are other possibilities to use it.

Due to the restriction of direct access to entities like Project Task, we cannot use this flow to update the WBS. To do so, we would require using the Project Scheduling API, but with the flow it is easy to address custom Project-related data and therefore create a set of Predefined Project we can reuse any time in our daily business.