In the fall release of Dynamics 365, we included many updates and improvement to Business Process Flows (BPF), including support for multiple instances of BPFs on the same record. This removes the restriction in previous releases of allowing only a single business process running against a specific record. It also prevents the accidental orphaning of a record in the case where it was being used as part of another BPF.
This change also introduces an important consideration when using BPFs. With this change, the ProcessId, StageId, and TraversedPath fields can no longer reliably be used to determine which process is running on a record or as triggers to workflows or other automated tracking. This is because there are other ways to create or update business process instances that may not rely on these fields. These field will be deprecated in some future release of Dynamics. The recommended way is to use the new BPF entities for actions like create, update, delete and retrieve.
When , it creates a restriction of binging the record to a single business process instance. With enhanced security models around BPFs, it also can expose information about the record or process flow running on it.
The December 2016 update also includes a stronger security model around entities that enables you to control access to them via security role privileges. You can also take advantage of the Dynamics client and server APIs to interact with BPFs and run workflows on them. Using related entity triggers, you can move stages or set values on another participating entity when a field step changes.
So, one would wonder, when there are multiple business processes running on a single record, how does the system display the BPF to a Dynamics 365 user when it is opened considering the new entity model?
When a record associated with a BPF is opened in the Dynamics 365 app, the system uses a selection algorithm to look for all actively running instance in the Read Only business process instance entity table. This table is also the intersect table for all BPFs in the system. The record may be part of the primary entity on the BPF, or one of the participating entities in the flow. Participating entities are the entities present in the BPF that are different than the entity of the first stage. The algorithm then filters the returned entity collection by user permission and sorts in descending order by the value of the
Additional complexity is introduced in the case where there are multiple users updating the same record using the same BPF. When the record is reopened or updated again the BPF displayed on the record may be different than the previous access or update to the record. To maintain the user selection, the system uses a user-specific cache that keeps track of the BPF instance selection per record. The selection persistence is temporary. It is used to ensure that the user selection does not change within the same session. In a limited manner, it is also persisted across sessions so that if the user opens the same record the selection is remembered. More specifically, the system uses the same Most Recently Used (MRU) cache to keep track of user selection and holds up to 40 user selections, for example record to BPF instances. Note that the records accessed via API or async servers
This is all great, but there may still be some confusion about this when compared to previous behavior. Consider the following:
- The ProcessId field on the record may not represent the BPF for which the instance may appear when the record is opened in the Dynamics 365 app. This is expected, and different users will see either the default based on the selection algorithm, or, if previously accessed, a value from its cache.
- If there are workflows on the participating entity using the fields like StageId or ProcessId, they may no longer work reliably.
- If you change the BPF running in the record to another one via the switch process, it is now local to your view and does not change the BPF instance displayed to other users.
- Even if you have programmatically set or switched the BPF on a record via a client script, it only changes the view of the specific user and not for other users.
You’re probably asking: So how do I change the BPF for other users when I change a BPF instance on the record. Well, since the view of the BPF running on the record is now personal or local to the user, it cannot and should not be altered directly. If it’s really needed, You can run a script on loading of the page to switch it to another instance to a more appropriate one based on the condition desired such as the role of the user.
Please let us know what additions you would like to see with regard to viewing of the business process instances. We welcome your comments and feedback. Thank you.
For more information about Business Process Flows, see the following:
- Business Process Flow overview: https://www.microsoft.com/en-us/Dynamics/crm-customer-center/business-process-flows-overview.aspx
- Model business process flows: https://msdn.microsoft.com/en-us/library/dn481586.aspx
- Business process flow automation in Dynamics 365: https://blogs.msdn.microsoft.com/crm/2017/03/28/business-process-flow-automation-in-dynamics-365/
- Best practices for automating business process stage progression in Dynamics 365: https://blogs.msdn.microsoft.com/crm/2017/06/16/best-practices-for-automating-business-process-stage-progression-in-dynamics-365/