Microsoft Dynamics CRM 2013 introduced cross-entity business process flows. Up to five different entities can be combined in the same process flow.
Dynamics CRM includes an example cross-entity process flow called “Lead to Opportunity Sales Process”
In this process flow, the Qualify stage is on the Lead entity, while the develop, propose, and close stages are on the Opportunity entity.
Before a lead is qualified, the opportunity level stages are unavailable to be clicked.
After the lead is qualified, the next stages become available. When you click on the qualify stage, it toggles back to the lead form, when you click on “Develop,” it toggles to the Opportunity form.
So cross-entity process flows enable some really exciting user experiences:
- They link multiple records together in one process, providing a smooth user experience, as if they were the same record.
- They make moving between records in a process very easy (easier than popping up another window or drilling through).
Now that you are excited about cross-entity process flows, what about using them with custom entities or other system entities. What is the user experience?
Like with the standard lead to opportunity business process flow, you can define a business process flow that links up to five entities, including custom entities.
When you do, like with the lead example, when you create the first record, only the stages on the first record will be clickable. When you want to move to the second record, the user will click “next stage” on the business process flow.
When the stage advances to a stage on another entity, the user will be asked to select which related record that they want to link to (or create a new record).
This is because the related entity is a 1:N relationship, and CRM cannot decide which related record that you want linked in the process. If there is only one related record, the user will be presented that record, but the user will have to select that record to link in the process flow.
Using a real-time workflow, you could have CRM automatically create a related record to use in the process flow so the user doesn’t manually have to create the related record, but the user will still have to select that record to use in the process flow when moving the stage the first time.
Note this is a one time thing per record. Once the related record is selected, the user will never be asked again which record to link for that stage on that record.
Under the hood
So what is going on with cross-entity process flows behind the scenes? When you move the stage to the related records stage, CRM is creating a record in the process instance table. This background table stores the process ID and the GUID’s of the related records. While it is possible to populate this table directly, it is highly unsupported and not recommended, as there are additional application business processes that run when records are linked in business process flow.
What this means is that the only supported way to link records and set stages in cross entity business process flow is by users doing it manually and moving the stage via the user interface.
If you are deploying CRM now and think that a cross-entity business process flow would be of value “some day,” it may be advantageous to implement it from the beginning rather than waiting and having a large number of legacy records that are not linked when you want to start using it later.
If you have an existing CRM deployment and want to move to cross-entity process flows, think through what the impact will be to existing records. Do you need to update all of the legacy records, or can you just start with the new process on new records created going forward?
If updating existing records is a requirement, just consider that somebody will need to open each record and move the stage to one of the second entity stages.
Alternatives
So if you have a large number of existing records where you need to update the stage programmatically, what are the alternatives to cross-entity process flows?
One alternative, suggested by , for situations where you need to have related records share a process flow and be able to update the stage on existing records, is to use individual process flows for each entity, but have a process like a plugin that programmatically sets the stage on the child records based on a change in the parent record.
While this approach does not give you the nice related record visibility in the master record process flow, it does tie them together in a related process, so that moving the stage on the parent record also updates the stage on the related records. Plus, you can update existing records process stages in a supported manner using tools like the
by Customer Effective
