When is the right time to have your first child?
A difficult question with a whole range of possible answers, I’m sure you will agree, and there are other websites and forums much better placed to answer it. So instead I’ll answer something slightly easier and with more definitive answers which often comes up when I am delivering training for CRM customisers and super-users who build their own workflows:
“When should I have my first child workflow?”
There are simple answers to this and some more esoteric and more complex answers to this. Generally I would say there are six main use cases for child workflows, which I will discuss in this post in approximate order of obviousness (most to least).
1: “Let me get on with my job”
A very simple scenario for CRM 2011 – you want the user to work through a Dialog process and provide some details or make some decisions, at the end of which they should get on with other things while a workflow runs to do some other steps which can run on their own with no further intervention (such as creating related records, updating links or sending an automated email).
You don’t make your users stay in the dialog a second longer than necessary once their useful participation is over (“leave, puny human!”), and this also means you can call a child workflow which involves waiting for a while before doing something (like sending a reminder) – you can’t do a wait step in a dialog.
2: Wash, rinse, repeat
Often in a workflow you have several points at which you want to do one or more identical steps. Maybe you have to set up several conditions which set various fields to different values, then inside some of the conditions you do a step such as creating an activity which is essentially the same but takes lots of fiddling to get right? It can be pretty tedious to do all of this. And you can’t move or copy the tricky step if you later need to change the flow of the logic.
For example you might run a workflow against a service Case which checks the customer type and service level, or maybe the related product or contract line, sets fields on the case such as the expected completion date and assigns it to an appropriate user or team. For important customers you want to send an email to the account manager to let them know the Case has been logged and including details of who is dealing with it, and for high priority Cases you want to create a Task to get things moving, with a due date related to the SLA type and time the Case was logged.
The actual steps of creating the activities are not especially complex but to do all those dynamic fields and get them right several times over takes a while. And then takes even longer when your user acceptance testing asks you to change some of the detail – several times over.
Build the activities in a child workflow (or possibly two separate ones). Then each time you want to do the same step, call the child workflow (running against the same Case record). Now you only have to build it once and only have one place to make changes.
A nearly identical use case would be when you have several similar workflows which are triggered by different things such as record creation, fields being updated or status changes. In each of the workflows you can call the same child to do some of the work. Read 4 more scenarios where child workflows will help you out »