Here is the 4th part to the series on extending Project for the Web. If you missed part 3, it can be found here: https://pwmather.wordpress.com/2019/12/23/extending-projectfortheweb-part3-ppm-cds-msdyn365-powerplatform-msproject-powerapps/
Part 3 covered adding a new Risks entity into Power Apps then adding this new entity into the example model driven Power App. In part 4 we will look at the Power Automate Flow used as part of the Risk to Issue escalation process and also look at adding a few more fields to the Project entity.
The Flow used for the Risk to Issue Escalation process is very simple in this example but it could easily be extended to add approvals in etc. if needed. The Flow can be seen below:
The Flow is triggered on the Common Data Service “When a record is updated” trigger, this is linked to the Risks entity and filtered to fire when the the “Escalate to Issue?” field is updated. Then a condition check is used to ensure the “Escalate to Issue?” field value label is set to “Yes”. The Flow then uses the “Create a new record” action to create the new record in the Issues entity:
This Flow action creates the Issue record with some data mapped from the escalated Risk record, as you can see from the image above we have the following mapping as an example:
- Issue Title = Risk Title
- Issue Description = Risk Description
- Originating Risk = Risks
- Related Project = Related Project
The final action in this simple Flow is an “Update a record” action to update the escalated Risk to tag the Risk as Closed and set the Escalated Date value:
That’s it, a simple Risk to Issue escalation process using the Power Platform with Power Apps and Power Automate. This could easily be extended to suit your organisations requirements, for example, you might want to auto escalate based on certain Risk field value criteria etc.
The next part in this post is adding some additional fields to the Project entity. This is very straightforward so I wont cover this step by step for each field, the process is the same as we have seen in the previous blog posts:
- Create the required fields in the entity
- Add the fields to the correct views / create new views in the entity
- Add the fields to the correct forms / create new forms in the entity
For this example we will add the following fields to the Project entity:
- Project Type
- Overall Status
- Estimated Cost
Creating the fields, navigate to the Project entity and click “Add field” and complete the form as required:
Where choice / pick lists are required, add the required option sets.
Now access the Views for the entity and update / create new views as required then save and publish the updates to the view/s. Navigate to the Forms for the entity and add the fields on the form/s as required then save and publish the form changes. Once completed editing the project entity the changes will be visible in the app.
Projects view I updated to include the new example fields (Note: I had previously created Project Department):
Project form that was updated to include new example fields:
There are some limitations with field data types that can’t be set / edited in the Project entity due to some pre-validation event handlers as part the Project for the Web solution. For example, fields using the Currency data type do not allow the project record to be updated / set. It will generate an error like this “We’re sorry. You cannot directly do ‘Update’ operation to ‘msdyn_project’. Try editing it through the Resource editing UI in Dynamics or via Project.” So my example “Estimated Cost” field is just a Whole number, rather than a Currency field. Something to be aware of when you are adding new fields to Project entity.
That’s it for part 4, in part 5 we will look at adding more features to this example app with Program and Status Update comments support with some text analysis thrown in!