Handling Business Process Flows (BPFs) on record Create
In this blog we ask the questions like: how to apply a specific BPF when creating a CRM entity records? How does system defaults on new record create (or) how do I override this behavior? Good questions! Let’s clarify.
When an entity record is being created and If there are multiple BPFs defined on that entity. The system would do the following:
- If the ProcessId field is set to Guid.Empty. The system will skip defaulting the BPF on that instance.
- If the ProcessId field is set to specific BPF entity reference. The system will default to the specified BPF.
- If the ProcessId field on the record is not set. The system will default the BPF.
Skipping the BPF initialization on create is quite handy if you are working on a complex scenario and would like to skip the system default and would like to create one or more appropriate BPF instances based on your requirement later. It would also useful to skip defaulting and use synchronous or asynchronous workflows to create BPFs on the created record based on complex conditions in an automated manner. When automating via the sdk or client api. one can interact directly with the associated BPF entity and create the appropriate BPF instance record too. Workflow as mentioned above come quite handy as it would not require and code writing.
To apply a specific BPF on created. Set the ProcessId field. This field can be set by the caller on set via plugin in the pre-validation or pre-operation of the event pipeline stage.
When no value is set to ProcessId field on created the system defaults. System defaults the BPF using the below multi step approach:
Step 1. Identify all the BPFs that apply to the created record. This is done by looking at the primary entity of the BPF specified in the “PrimaryEntity” field of the BPF. the BPF definitions are stored in the workflow table.
Step 2. Identify the BPFs applicable to the user’s role. In older releases (8.1 and older) there was a field on the workflow table “ProcessRoleAssignment”. This table column stored the roles on which the BPF was applicable. This column value if blank or contain the condition everyone. The BPF would apply to users of all role. If the BPF is restricted to a user set then the appropriate roles will be specified in this column. For example:
- <DisplayConditions><Everyone /></DisplayConditions>
- <DisplayConditions><Role Id=”{5FD0CBAA-2D72-E711-8104-000D3A7403B7}” /><Role Id=”{51D6CBAA-2D72-E711-8104-000D3A7403B7}” /></DisplayConditions>
In the more recent 8.2 release, the security model of the BPFs have been updated. The visibility and permission on the BPFs are driven off the privileges associated with the backing BPF entity. Every BPF has a backend BPF entity that stores its record instances. The BPF entity name can be found on the BPF record on its “UniqueName” field. The backing BPF entity has organization scope. The regular create, retrieve, update and delete privileges on this entity define the permission the user would have based on his/her assigned roles. By default, when the BPF is created, only system administrator and system customer is given all privileges to this BPF. for all other roles, the permission needs to be explicitly given. This behavior is more secure than the previous release where the application of the BPF based on the roles present in “ProcessRoleAssignment” column was only imposed during create time and only when defaulting the BPF on a newly created record. Once the create was successful. Any user having access to the created record had access to the BPF.
Step 3: the order of the BPFs. all BPFs defined in the system in subjected to a global order. (Q: is it entity level or global). The order of the BPF is stored in column “Order” on the workflow table. Post step 1 and 2. The BPFs are sorted based on this order value and the first one with the least order is picked.
Step 4: There is one other level of filtering if the records are being created from inside the app module. CRM system allows for users to also pick and choose the app module they would want to work in the context of. App module allows the user to work in a constrained environment where only relevant entities, BPFs, views and forms are exposed to the user. Each app module may contain one or more or No BPFs. If the app module does not contain any BPFs then defaulting as described above applies. If the app module has one or more BPFs then only the BPFs present in the app module would be applicable. So in this case when the user is working within an app module context the list of BPFs from step 3 are filtered to the BPFs that are present inside the app module and ordered. The BPF with the lowest order is picked and if no BPFs if found on the app module that applies for that entity and user then defaulting is skipped.
Thank you. We welcome your comments and feedback. Let us know if you have interesting create scenario not currently possible via the infrastructure.
Interesting Links
This blog talks about how to default a particular BPF on the specified form when creating a record via the app. https://blogs.msdn.microsoft.com/crm/2017/06/22/set-default-business-process-on-a-form-while-creating-new-record/
-Shashi Ranjan
