Concurrent business process flows in Dynamics 365
Applies to: Dynamics 365
The Fall 2016 release of Dynamics 365 introduces concurrent business process flows. This allows multiple processes to run concurrently against the same record, which enables very powerful real-world business scenarios. For example, while the Sales department is running a sales process with a customer, the Customer Service department might be helping that same customer with a previous purchase that generated a support ticket guided by a service process. Concurrently, the Collections department might be reaching out to that customer and following their own process to claim a past payment that was not registered by the system. All three processes run against the same account record, completely isolated from one another.
Keep in mind that no two instances of the same business process flow definition can start on the same record, but a cross-entity definition can converge on the same record.
We made this possible by changing the business process flow infrastructure to store processes as full-featured entities. A business process flow definition is represented by an entity and an instance of a process is represented as a record. Each record is associated with a data record (like an account, contact, lead, opportunity etc.) and, in the case of cross-entity processes, with one data record for each participating entity.
This new architecture provides fine-grained control of access permissions per operation and per security role, and exposure of process data to the charting and reporting infrastructure. Another big benefit is that processes can be manipulated internally by workflows and externally by other services through the OData interface.
Security
Prior to the Fall 2016 release of Dynamics 365, System Administrators and Customizers could limit or restrict processes by security role, but for the Apply (or Create) action only. Once a process was applied, other security roles would have full access to manipulate that process. Now as a full-fledged entity, business process flows follow the organization-level security model and the Create, Read, Update, and Delete actions can be fine-tuned for each security role.
For example, Customer Service Reps could have full access to manipulate service-related processes, while Sales Reps have only Read access in order to monitor the post-sales activities for each customer.
A Collections process might involve critical information that should not leak outside of the Collections department. Restricting that process to only that specific security role guarantees information privacy.
To configure security for a business process flow, follow these steps:
- Launch the Business Process Flow designer.
- Click Enable Security Roles.
- Select the security role that you want to change.
- Click the Business Process Flow tab, and find the process on the list.
- Set the security for each operation per business requirements.
Upgrade and Solution Import/Export
Because the process infrastructure in previous versions of CRM have a simpler security model, business process flows from upgraded orgs and imported solutions automatically receive a standard set of permissions for the enabled roles. System Administrators and Customizers should stage and review the permissions before releasing the processes to their production environments.
Programmability – SDK
The full documentation can be found on the MSDN reference page.
Creating (applying), updating and deleting process instances can be done through the OData endpoint:
[org URI]/api/data/v8.2/process_instance_id
… where process_instance_id refers to the process definition unique id, which is the same structure used to manipulate regular data entities.
Programmability – Client API
We made changes to the process-related Client API calls, but maintained compatibility with previous versions by not modifying existing signatures and keeping the general behavior of all functions. More details can be found on the MSDN reference page.
The new or refactored functions are listed below. For all these calls, the user context and security privileges are taken into account:
(Async) Xrm.Page.data.process.setActiveProcess(processDefinitionId, callback)
Receives a process definition id and tries to create a new instance of that process. If there are no instances of that definition running, it creates that process record and associates it with the data record while returning that instance id. If there is already an instance of that process running, it renders that process on the process control and returns that existing instance id. If there are multiple active instances of that process definition running, it renders the “first” and returns that existing instance id. The “first” instance is the last one to be manipulated.
(Async) Xrm.Page.data.process.setProcessInstance(processInstanceId, callback)
Renders an existing process instance on the process control.
(Async) Xrm.Page.data.process.getProcessInstances(callback)
Returns a list of process instances, across all process types, that are running against the record.
For more information on the new Business Process Flow designer, see: Help & Training: Create a business process flow.
Carlos Mendonça | LinkedIn
Program Manager
Dynamics 365 team
