web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :

Project schedule APIs in D365 Project Operations

Sneha Daggubati Profile Picture Sneha Daggubati

In this blog post, I would like to share about the Project scheduling APIs in D365 Project Operations and how we can use scheduling APIs with Power automate to CUD scheduling tables. We have detailed documentation on the scheduling APIs, C# samples, and limitations. 

Background: 

We know that project for the web is embedded in D365 Project Operations and the scheduling engine (PSS) of project for the web which is a multi-tenant Azure-hosted service introduced to improve the co-authoring capabilities of project for the web (built on Dataverse). Project for the web capabilities in Project Operations were preventing certain scheduling tables/entities from create, update, and delete programmatic access.  

We have enhanced APIs so customers or partners can develop custom solutions utilizing this API. To put it simply, Scheduling tables can’t be updated directly in Dataverse, so the APIs were created as a means of executing CUD operations against the scheduling engine of project for the web. Both out-of-box fields and custom fields are supported. 

When a user changes values in the D365 project Operations WBS (project for the web UI) for columns like task start/end, duration, or effort, project for the web sends the requests to PSS in Azure. PSS accepts change requests, processes them, and then immediately returns the result. PSS asynchronously persists to Dataverse and doesn't block users from performing other operations. If the asynchronous operation persisting changes fails, changes made in the UI won’t be written to Dataverse and the user sees the data roll back in the project for the web UI. 

ProjectOps_2D00_Pic1.png

As part of the Project schedule APIs, a unit-of-work pattern has been added. This pattern is known as an OperationSet, and it can be used when several requests must be processed in a single transaction. It is always better to Group as many operations together as possible. The average runtime for bulk operations is better than the average runtime for single-record operations. The smaller the number of OperationSets in use, the faster the average execution time will be. More details here 

I highly recommend the blogposts by Antti Pajunen on the PSS and others on Project Operations.  

When create, update, or delete operations are programmatically run-on work breakdown structure (WBS) entities, errors might occur. To track these errors and the history of operations, two new administrative logs have been implemented:?Operation Set?and?Project Scheduling Service (PSS). To access these logs, go to?Settings?>?Schedule Integration. By default, both Project Scheduling Service error logs and the Operation Set log can be cleaned up every 90 days. Any records that are older than 90 days will be deleted.?More details here. 

Possible Usecases for Schedule APIs: 

  1. When we need to indicate which set of API operations would need to happen in a transaction scope. 
  2. To know the state of the API calls.

  ProjectOps_2D00_Pic2.png

3. Integration with Field Service to deliver work orders executed within the context of the Project. Changes that impact the start, finish, effort, or duration of the work order, are synced to a Project Task or a Resource Assignment. These changes are typically asynchronous. 

4. The customer requires bulk operations to aid users in schedule creation on projects with 200+ tasks. For example, Contoso needs the ability to select N number of resources and bulk assign them to multiple tasks in the WBS. 

5. 3rd party ERP interface running to update projects and tasks, potentially 1,000+ update/create calls a day 

6. During the data migration process, when a customer is ingesting a high volume of projects from multiple legacy systems. 

7. Customers need to generate resource assignment contours based on specific effort distribution using a custom dialog. 

8. Customers need Inbound data from legacy applications to drive resource management and project financials. 

Scheduling Tables: Supported Operations and Restricted fields 

The Project schedule APIs are designed to work with the following work breakdown structure (WBS) entities:  

  • Project (msdyn_project) 
  • Project Task (msdyn_projecttask) 
  • Project Task Dependency (msdyn_projecttaskdependency) 
  • Project Team Member (msdyn_projectteam) 
  • Resource Assignment (msdyn_resourceassignment)
  • Project Bucket (msdyn_projectbucket) 

Here are some important considerations for the above scheduling entities and restricted fields on those entities. 

Also, please note that Project Schedule APIs can only be used by?Users with Microsoft Project License. They can't be used by: Application users, System users, Integration users, other users that don't have the required license 

Code Samples 

Some sample implementations of Schedule APIs to create projects, tasks from sample WBS and to create and execute Operation sets. 

Schedule APIs with Power Automate 

Here is the article that shows a demo of how to use Schedule APIs in Flows.  

https://docs.microsoft.com/en-us/dynamics365/project-operations/project-management/scheduling-apis-powerautomate 

ProjectOps_2D00_Pic3.png

Comments

*This post is locked for comments