When and How to use Child Workflows in Dynamics CRM
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.
3: I haven’t learned the third verse (yet)
The 2012 Olympics were a wonder to behold, but it was a bit embarrassing at times to see the medal winners standing on the podium and singing their national anthem so proudly – until it got to about the third verse, where they started to falter. Some workflow designs are a bit like this, the user stories are gathered and you start to build a great workflow only to find that the last bit is “to be confirmed”.
Now, in some cases it may be perfectly reasonable to activate what you have so far and it may run just fine – it does not do all the things the business might later require but everything in it so far is good to go. Simply create a second workflow, available as a child, activate, and call it as the last step of the one you already built. The child does not even have to contain any steps yet, it just means you can build phase 2 while phase 1 is already up and running.
What about using a “development” environment?
In a perfect world you would possibly avoid some of this class of problem by only building this stuff in a development environment and then publish to Live (possibly via Test, UAT, Training or whatever other formal stages you want to go through). So you could possibly go back and simply change the workflow to accommodate the new logic or extra steps, re-activate and export / import along to the next system as a whole and finished job.
Small CRM deployments using Workgroup Edition, or CRM online will not have that luxury – you can’t just spin up another organisation for free. You would have to set up a virtual machine or an additional server and actually install CRM – avoidance of which may be why you went with the online version in the first place…
Even in a development environment, you might only have one organisation which various people work on at once, so you may not be able to just activate and deactivate workflows without seriously disrupting others in their work or testing. Equally, depending on how you manage your version control, you might want to be able to export and import a solution which contains only the child workflow you changed, not any others, so it is clear that they were not affected by the solution import and publication.
4: Passing the gravy boat
Not one that immediately jumps out as a use for a child workflow is to update grandparent records.
A simple example could be that when an Opportunity is won, you want to update the customer relationship type on the Account to “Customer”. But maybe the Opportunity is associated with a Contact as the “Customer” because your business model works better this way to capture the person who is the main contact, decision maker, budget holder or whatever (and of course you would still see the Opportunity under the Account record because of the roll-up views).
You run a workflow on the Opportunity and want to go and update the parent Account of the customer Contact. But you can only reach up one level of the hierarchy in a workflow using an update step. So you create a child workflow to run on Contacts called “Update Parent Account to Customer”, then from the Opportunity you call this child for the customer Contact.
I think of this as being a bit like sitting round the family dinner table and passing the gravy boat to your Mum to pass on to Grandma, and possibly for her to pass on to Great-Granny too, because you can’t reach far enough from where you are.
So when my readers ‘across the pond’ are sat at the Thanksgiving table on Thursday, they can say to their gathered family, “It’s great to get all these generations of the family round a table together like this – did you know this is a bit like when you use child workflows in CRM to update records which are not immediately available in the process editing dialogue? No? Oh well, pass the sauce, junior”
I have used this to “pass the baton” twice in succession in one scenario where there were some custom entities involved in a fairly deep hierarchy. It might be better to do this using a custom workflow assembly, but until right now you still can’t use those in CRM Online (this is due to be made available as part of the Polaris release in Q4 2012).
5: What are we waiting for?
If you have a workflow that has a really long wait* built into the middle of it, consider breaking out everything after the wait into a child workflow instead. Many times I have had a business user describe a process such as “when someone signs up to come to an event, wait until two days before then send them a reminder email with this information on…”. This seems reasonable.
How about “when a customer places an order for a year’s licence / membership / support, wait 11 months then create a phone call” – equally reasonable but maybe we could just create the phone call record now, with a due date for 11 months time? (but what if they cancel mid-year, or the primary contact changes – better to wait and create it later so you call the right person).
In both cases you could build this and the business merrily starts signing event attendees up, or getting customers to place orders. But sometimes, they know they need to wait, but they are not yet sure what exactly it is they are waiting for, and what will happen when you get there. Then (inevitably) someone comes along and says “actually, that email we are sending needs changing”, or “actually, we don’t want to phone them, we want to create an Opportunity and add the phone call to that instead”.
You would have to deactivate the workflow, make the changes and re-activate. No problem. Except that all the workflows which have already been started and are running will continue to run with the definition they had when they were triggered, which is really not what you want. So you might have to cancel all of those and call the revised version of the workflow again on demand, which is more work, and might not be ideal if the other steps of the workflow are things you don’t want to do again (such as sending an acknowledgement email right at the start of the workflow – you don’t want that going out again).
*How long is a long wait?
About as long as a piece of string. It varies. Mainly depending on your business and your own level of risk-aversion.
One possible definition: “any time interval long enough for a user to change their mind on a whim”. In some businesses with well-defined processes, this could be many months; in others it might be measured in minutes.
Also consider how many times the workflow would be started during the waiting period – if you are waiting for a week but the records which kick off this process are created at a rate of several hundred a day, this would be a big enough mess to clean up if a change was requested in that short time, so that would be long enough to meet my definition. If you wait for a year on something which only happens a handful of times a week that might be less of a pain to sort out, but the chance of someone thinking of a newer better process in that time (or a key stakeholder changing jobs and being replaced) is much higher. My rule of thumb tends to be anything longer than a month I would split off, anything shorter – “it depends”.
Using child workflows to manage wait stages
A better way to handle the problem would be a model like this:
- Workflow is triggered and “does stuff”
- This workflow waits for set duration or until a specified date/time (maybe dynamic eg 11 months after Order created) or other condition to become true
- Workflow does nothing else except call child workflow (or maybe does a conditional check first, then only calls the child if it still needs to)
- Child workflow does all the later steps.
This works really well – if someone wants to change the logic of what happens inside the child workflow you can deactivate, make the changes and re-activate, and all the waiting ones will call this and you get the new logic when you get to end of the waiting period.
I have even used this approach where the business process described was “wait a year and then we will do something but we don’t know exactly what yet”. So I created a child workflow and called it from the one which waits for a year – we now have a whole year to find out exactly what they want the child process to do before we have to build it, yet it will take effect just as it should when the time comes.
Are we nearly there yet?
A further extension of this approach can handle the scenario of “we need to wait for a while but we are not sure exactly how long, then do some stuff we have not yet defined”. Agree some kind of sensible trial figure for the waiting period (maybe this is a week, or a year), then do this:
- Workflow does stuff
- Workflow calls child workflow 1
- Child workflow 1 does nothing but wait, then call child workflow 2
- Child workflow 2 does the later steps.
You can now change child 1 or 2, to adjust how the wait logic works (eg don’t wait 11 months, wait until one month before the end date, which might be something other than a year away) or what happens when we get there. Of course changing child 1 would only affect new processes starting from the beginning, not ones already in their waiting period, but you could use the next technique to work around this.
As above, you may want to add some conditions at the end of the wait to make sure the logic is still valid – I see lots of people build complex workflows which fail after a wait state because the later steps try to do things like update a record which has been deactivated in the mean time (especially things like Opportunities or Cases being closed).
6: The Red Button
Once your CRM implementation is up and running, users will come up with all sorts of ideas for things which they find hard to invent and conceptualise when they have not yet used the system to do their actual real daily job.
For example they may find that when they create an Account and then the first Contact it would be really handy if that Contact could automatically be set as the primary contact for the Account. (yes, they could add and qualify a Lead instead, but let’s take the requirement as set out). So you set up a simple workflow triggered on creation of a Contact that checks if the Account has a Primary Contact yet, and if not it uses this Contact. (You can also do this in a single step with just a clever dynamic field on the update form, but a condition would be easier to read and understand for someone else later).
Great. Job done. But they also want to build a time machine and apply this to all the records they already created. Easy enough to do, you say – I’ll just make the workflow available on demand. Except while it is available on demand some user will go and run it against the wrong contact. Or all contacts…
Now, you do want to be able to call it on demand, but under controlled conditions against the right set of records (only Contacts whose parents do not have a Primary Contact set, and in created date order to replicate the logic that the first one entered is made primary, and later ones are not). And maybe, as a kind of audit trail, you want to keep the system jobs that were run on demand but don’t want to keep the ones which are run automatically (many of which would do nothing anyway if the Account already has a primary contact)
So don’t make your fancy new workflow available to run on demand, make it available as a child. Then create a new workflow which I would call a “trigger workflow” and this is available on demand and this simply calls the child one.
Activate it and run it once against the results of an Advanced Find for the contacts you need, sorted by created on date. Then deactivate it, and indeed delete it if you want to, as long as you make sure no users can ‘accidentally’ use it when they should not. You can see from a record if it had this specific workflow run against it by it’s unique name, and can find them through advanced find if you need to. If you just made the original one available on demand then you would have to deactivate it , change and re-activate – maybe not so easy if it is live and people might create a Contact at any moment which could get missed.
It’s a bit like nuclear disarmament – it is not sooo bad if the nukes are still there, as long as you take the red button out of the hands of idiots…
To use this in the above scenario for changing the middle “wait” workflow you would possibly want the trigger to update some temporary new field before calling the updated child workflow which does the waiting. So you find the records which already have a workflow job with this name running and waiting, then run the new on demand “trigger” to call the updated version, then find the system jobs which are waiting but were started before you just hit the trigger and cancel them (don’t cancel them first or it is much harder to find the set of records that had the waiting workflow running).
Downsides of using child workflows
So, there are at least 6 good reasons to build your workflows in such a way that part of the work is done by a child workflow. But one downside of this approach can be that there is no built-in way to call the child workflow and wait for it to be finished before carrying on.
You can work round this by adding a specific custom field on the primary entity (maybe that Case from our scenario 2) which is then updated by the child workflow – this could be as simple as a bit field (eg checkbox) called “new_TaskCreated” which is filled in or not. You then call the child workflow (to create a Task, say) and add a wait step after that in the main workflow to wait until the field is filled in. The next step might be to reset it ready for the next time round (depends on the business process whether you would need to do this or not).
If you are using staged workflows to manage your sales pipeline so that you can leverage the built in Sales Pipeline report then you will need to make sure to do this cleanly by getting your main and child workflows to delete the related jobs when they are completed, where that is appropriate, otherwise if you have more than one workflow run against the same Opportunity it will be double counted under two different “sales process” columns of your charts.
Another general downside of child workflows is simply that you end up with more workflows. You need better naming conventions to handle these (and do please fill in the description field too to describe what they are for and intended to do in more detail). If you use CRM Online there is a limit of how many activated workflows you can have at any one time – you are not likely to reach this limit but it would be possible if you had lots of complex needs.
No comments:
Post a Comment