Workflow OR conditions in CRM 2013 SP1

Everyone is writing about all the big changes in Dynamics CRM 2013 Service Pack 1 (aka Spring ‘14 Release for CRM Online, previously codenamed “Leo”). There are tons of great features around Service management, new tools for developers, improved tablet support and so on.

If you want to find out all about the new service management functionality, how to enable and take advantage of the SLAs, entitlements, Case routing and related features, sign up for our in-person classroom training course What’s new in Dynamics CRM 2013 Spring ’14. In one day of accelerated training you will learn all about configuring new service features, as well as high-level coverage of other items such as tablet support, server-side synchronisation, status transition controls, and more!

At the CRMUG UK Meeting in July we are also focussing on “Service” and will have plenty of time to hear from Microsoft about the new release, as well as a session from Wael Hamze of Barclays for developers, including some of the new things in the SDK.

In all the kerfuffle there has not been much mention of a little feature that I have been waiting on for a long time, that will make a small but important difference to the development of Workflows. You can now create conditions and group clauses using OR and AND conditions. Read how to use OR conditions in Dynamics CRM 2013 Workflows with SP1 »

When and How to use Child Workflows in Dynamics CRM

Girl on Dads shoulders_smallWhen 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

Shampoo BottleOften 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 »