This post forms part of a series I am creating aimed at helping people prepare for the MB2-712 certification. (Microsoft Dynamics CRM 2016 Customization and Configuration). This time I will cover the topic of workflows.
There are several types of processes in CRM 2016 including;
- Workflows – Used to automatic business processes that don’t need user input. Can be started automatically or manually by users. Can run in background or real time.
- Dialogs – Used to automate step by step business processes that require user input. (Via a wizard style interface.) Are started manually by users. Run real-time. Often used for agent scripts.
- Actions – Allow transaction custom API calls. Can be called on demand from code or via workflows. Allow the specification of input / output parameters.
- Business Process Flows – Used to create a visualization of a guided business process that is shown within CRM forms.
In this post I will concentrate on workflows but will cover other aspects of processes in future posts.
Workflows
Workflows are a powerful tool which can be used to automate business processes. Think of them as a macro that can be triggered from within the CRM application.
They can be configured to run in background or in real time. When fired in background the user can continue to use the application. When fired real-time the user cannot continue until the workflow finishes. (Meaning they have an impact on performance!)
Typical uses of background workflow include;
- Sending an email when a new case is created.
- Assigning a new lead to a sales person.
- Creating a follow-up phone call when a case is resolved.
- Etc etc etc.
Real-time workflows can run as the user who caused the triggering action to take place. Meaning, for example, if a new record is created by the workflow it would automatically be owned by the user who caused the workflow to start.
There is a separate security privilege to control real-time workflow activation. See below that in the customization tab of security roles you can allow someone to execute workflows and activate real-time processes as two separate security privelages.
Workflows can start automatically, for example being triggered by a record being created or a field updated. Or they can be run manually “on demand” by a user.
Workflows can enter a wait state. Meaning they can be triggered when something happens but then wait a period of time until continuing. For example, we might send out an email to customer two days after a case was resolved.
Workflows do not required input from a user to run. (Dialogs are used when user input is required.)
Running an on demand workflow
Below you can see that I have selected multiple leads. I can then select the run workflow option. This is demonstrating a nice feature of on demand workflows. As they can be manually fired on one or multiple records.
Having selected one or more records, the run workflow option lets me search for the workflow I want to run. In my simple example I only have one workflow defined. But you could potentially have a large number of actions you allow users to manually run.
Next I simply confirm the correct workflow has been selected and away I go!
Tip: I often find on demand workflows are useful in support situations! Say I have a number of leads that are missing a vital piece of information. I can quickly create an on demand workflow, run it against the effected records. Another tip is that this approach will also work on “qualified” leads. Which are read-only and can’t normally be updated using a CRM form.
Creating a workflow.
You will find the processes option in the settings area of CRM. From here you can create a new workflow. The first step will be to give the workflow a name and select the entity associated with the workflow. Each workflow is always triggered or manually run from a specific entity.
In this example I opted to create a BACKGROUND workflow. If I unselected the “Run this workflow in the background” option, it would have become a real-time work flow.
Next you will be presented with a screen similar to the one below. Before we start defining the steps / actions the workflow will actually do we have a number of other fields to consider.
| Field | Description |
| Process Name | This is the name of the workflow you will have given in the first step, it can be changed. |
| Activate As | For now, we are going to leave this option as “Process”. But you could change it to “Process template”. Say you have a number of workflows that are very similar, then you could create a template and use that as a basis for any future processes you create. |
| Entity | This is read-only and therefore cannot be changes. The entity is defined in the first step of creating the workflow. If you get it wrong, you need to start again! |
| Category | Also read-only. You can’t convert a workflow into a business process etc! |
| Run this workflow in the background | This option appears to be read-only! But you will find a “Convert to a real-time workflow” option in the ribbon bar that can be used if you decide this workflow really should be a real-time workflow. |
| As an on-demand process | If you want users to be able to manually run this workflow that select this option. |
| As a child process | A workflow can call another workflow. (Known as a child workflow.) Selecting this option would make this workflow capable of being called from another workflow.
Tip: You can select multiple options under available to run. Often I will have a background workflow that can also be run on demand! Say you have a workflow to send an email. It might run automatically when a record is created. But also having the ability to run on demand to resend the email is really useful! |
| Automatically delete completed workflow jobs | Each time a workflow runs a system job is generated. Having access to these can be very useful when debugging a problem. But they can also take up space. Selecting this option will remove these system job records after the workflow successfully completes. |
| Scope | The options include User, Business Unit, Parent Child Business Units and Organisation.
The default is User. Each workflow has an owner. The workflow will run as that owner. The scope defines if it will be applied when just this user updates a record, anyone in their business unit, anyone in the child business units of their business unit or if the workflow applies to the whole organisation. Note: Almost always I personally select the organisation option. A common support issue will be that the workflow runs for some users and not others. If this happens the scope will be incorrectly set! |
| Start when – record is created | As it sounds, if selected the workflow will start as a record is created. |
| Start when – Record status changes | If the status of the record changes that the workflow will be created. For example, running a workflow on change of status on a lead would allow you to say if the status = “qualified” then do ….. |
| Start when – Record is assigned | As it sounds, if the owner of a record changes this triggers the workflow. |
| Start when – Record fields change | If this option is selected, you then click the “Select” button to choose which fields will cause this workflow to be triggered.
|
| Start when – Record is deleted | As it sounds trigger a workflow if someone deletes a record.
With a background workflow the workflow is executed AFTER the record is deleted. You cannot pull any information from the deleted workflow. If that is needed use a real-time workflow. |
Having decided the scope of the workflow and when it will be triggered etc, we can move our attention to the steps it will perform. Workflows can be very simple or very complicated! As you can see below I have quite a few options on possible steps. Including conditions, creating records, updating records, sending emails etc.
Tip: It is also possible for developers to create custom workflow actions that can further extend the available steps.
Just as an example I have shown a very simply workflow below. Notice that above each step in the workflow I can add a comment. Doing this makes them easier to understand and therefore maintain.
The best preparation at this point will be to create several workflows and experiment with the capabilities. Meaning I am not going to cover all of the capabilities of the steps within a workflow in this post!!
Notice how I have a “Set Properties” button next to the send email option. You will see this on several types of steps. Including send email, update record and create record. Clicking this button will open a screen allowing you to define the fields needed in the email etc.
Note: I have simply added steps to my workflow. This is quite typical. But there is a concept of creating stages and then having multiple steps within each stage. This is sometimes useful to help organise large workflows into logical parts. But honestly I have rarely use stages!
Wait Conditions
If I create a wait condition step, I can make the workflow pause until a condition is met and the continue. Often this might be based on waiting until a particular value on the record is set. But I can also wait a predetermined amount of time. For example, below I have set my wait condition to wait for 7 days after the order was created.
Tip: The first field of “Process” will default to looking at the entity of the workflow. Changing it to process lets me select the timeout option. I can then say 7 days after created on etc etc.
Below you can see I have shown an example workflow using a wait. When an order is created I send a thankyou email. Then after a week I send another email checking the customer is happy with their purchase. (Great customer service, zero effort. Nice!)
It is also possible to wait for “n” months, days, hours or minutes before a date.
Tip: You can also create parallel wait conditions!
NOTE:
Be very careful with wait conditions if using real-time workflows, don’t forget the real-time workflows prevent the user from continuing!
ALSO NOTE: Also consider the implications of having large numbers of workflow waiting for potentially long periods of time. Wait states are great but you need to be mindful of performance and maintainability if you end up with large numbers of workflows waiting around for “stuff” to happen. Think of them as chocolate. A lovely thing but too much of a good thing can be bad!!
Real-time Workflows
Below I have converted my workflow into a real-time workflow. Hopefully you can immediately see that the options have changed! The logic of the steps of a real-time workflow and a
| Field | Details |
| Start When | The start when is important!
The values for when a record is created or deleted are always after and before. Logically you couldn’t start a workflow before a record was created! And it is always going to be best to star the workflow after the user has said they intend to delete the record but before the delete has happened. As then I can do “stuff” using values from the record before it is gone. You can change the value of start when it either after or before for record status change, record is assigned or fields changing. Typically, you will leave this set to after. But occasionally running a workflow knowing the original values is useful. If example, if the owner is changed I might want to send the old owner as email! |
| Execute as | Here I can define if the workflow will run as a using running the workflow or the user who changed the record. Often I want the workflow to run as the user who changed the record and that is the default. But say you need to create a record on an entity that the user doesn’t have access to. Then you might have the workflow owned by the system administrator and run it as the owner of the workflow. |
Workflows are a very important part of CRM as they enable you to quickly automate the key processes within an organisation. It will be very important for you to spend time learning how these work and the best way to do that is to create and test multiple variations. Think of this post as starting point or revision guide only! Hopefully it has given you the basic information you will need for the MB2-712 exam. J
NEIL PARKHURST 
Leave a comment