I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around workflows.
You can see below that we have a section of the exam which covers managing the user experience and within that workflows are mentioned.
There are several types of processes in Dynamics 365 including;
- Workflows – Used to automatic processes that don’t need user input. Can be started automatically or manually (on demand) 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 – Are processes that can be called on demand from code or via workflows. They allow the specification of input / output parameters.
- Business Process Flows – Used to create a visualization of a guided business process that is shown within Dynamics 365 forms.
Note:
With Dynamics 365 we also have the ability to use Microsoft Flow which is Microsoft’s newer workflow engine that provides many more capabilities. (I will cover Flow in a separate post!) As shown below, you may sometimes see Microsoft recommending you consider using Flow in preference to background workflows!
In this post I will concentrate on workflows but will cover other aspects of processes in future posts. (Such as business process flows.)
Workflows – Overview
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 Dynamics 365 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 a direct impact on performance!)
Some 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.
Alternatively real-time workflows can optionally be run as the owner of the workflow. (Often this will be an admin user proving additional security privileges over the user who changed the record.)
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.)
Workflows – Security Roles
A users role will grant them privileges to run workflows. There are 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 privileges.
Additionally if you wish your users to be able to run OnDemand workflows or flows then you may need to show the Microsoft Flow option in the Dynamics 365 site map. To do this open the PowerPlatform admin center and check the settings for your environment. https://admin.powerplatform.microsoft.com
Running an on demand workflow
Below you can see that I have selected multiple leads. I can then select the “Flow” option! No under the run workflow heading I can access my on-demand workflow. This is demonstrating a nice feature of on demand workflows. As they can be manually fired on one or multiple records.
Note: As mentioned in the security section above you must have Microsoft Flow enabled in the site map to access the on-demand workflows! Also this hints at another feature to run Flows on the selected records. (Giving us multiple options for triggering workflows against selected records!)
Before the workflow is triggered I will be given a confirmation dialog. Notice that it will tell me how many records this workflow will be run against. It might be important to check that number is correct before clicking ok!
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 Dynamics 365 form. (Hence why I find this approach useful in support situations!)
Creating and Amending workflows
We have two ways to amend customizations! Classic and the newer make.powerapps.com experience. We can amend workflows from our solutions within make.powerapps.com or from within the classic experience.
But to create a new workflows you’ll need to swap to the classic experience. I typically do this from the “switch to classic” button from within PowerApps.
Within the classic experience you will find a processes option. You will find a New option here!
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 we have a number of other fields to consider.
The table below describes all of the fields you might need to consider before build the actions the work flow will actually execute;
| 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 future processes. |
| 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 then 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. |
| 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: Personally, I almost always 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 | 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 | 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 record. If that is needed use a real-time workflow, as they can run before the delete is actually applied. |
Having decided the scope of the workflow and when it will be triggered, 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 steps for creating records, updating records, sending emails, starting child workflows etc.
Tip: It is also possible for developers to create custom workflow actions that can further extend the available steps. If you have some Dynamics 365 Apps installed you may notice some custom workflow actions that relate to these. (For example, below you can see that I have Field Service installed and therefore below the out of the box actions I have additional ones relating to bookable resource, invoices etc.)
Just as an example I’ve 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. Therefore 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 organize large workflows into logical parts. But speaking 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 then 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!
Real-time workflows have some additional options to consider! Including when they will start and who they will execute as;
| Field | Details |
| Start When | The “start when” section is important!
Notice that we can opt to select that the real-time workflow runs before or after the trigger. Importantly the options for when a record is created or deleted are read-only. Meaning real-time workflows are always triggered before the delete has been completed. (Plus logically you couldn’t start a workflow before a record was created!) 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 Dynamics 365 as they enable you to quickly automate the key processes. 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 MB 200 exam.
NEIL PARKHURST 
Leave a comment