Now that you understand the types of Processes available in Microsoft Dynamics 365, let’s break down the settings you will need to configure for workflows. It can be very confusing while working on your first workflow to see the half-page of settings you need to fill out!
|Background Workflow Options|
Today will will cover the left side of the settings – Available to Run and Workflow Job Retention.
Available to Run
The Available to Run Settings determine when and how this workflow should run.
- Automatically – this is determined by the settings on the right hand side and by the “How”
- On-Demand – this means that a user manually clicks “Run Workflow” and selects this process to start
- TIP: It is always a good idea to allow workflows to be run On-Demand while testing. This allows you to test on a smaller group of records before exposing to a larger group.
- When running an On-Demand workflow it always runs as the users who triggered the workflow
- Child Process – in this case, the workflow is called from another workflow. This is very helpful in long or complicated workflows where you may want to split portions of logic out into smaller sections
- Child workflows are especially useful if you have long-running workflows with multiple wait conditions. A workflow will always run as it was defined at the time it started.
- For example, you have a workflow that starts when a lead is created, waits 6 months and then creates a task with instructions to call the lead
- Say the Business decides now they want the instructions to say to email the lead instead of call
- If all one workflow: all leads created before the change was made will still say “Call”. That means in 6 months they are still getting “Call” tasks
- If using a child workflow after the wait (creating the task): then all leads that reach their 6 month mark after the change (not just created after the change) will get “Email” instructions. When they hit the wait/timeout, it will move to the new child workflow and pick up the new task details
|Real-Time Workflow Options|
- In the Background (Asynchronous) – when the workflow is triggered it will get added to a queue of workflows that are processed in order. The change is not visible on the screen but should be complete before the next time the open the record
- This always runs as the Owner of the workflow. This means it follows their security (can’t delete if the owner does not have access to) and shows that name in the “Modified By” fields
- Real-Time (Synchronous) – when the workflow is selected to run in Real-Time additional options will appear to define this (Scope and Start When). You can configure the workflow to fire before the save event occurs (ex. return an error to the user for validation) or before a delete (capture some data before letting the delete proceed), etc.
- This should be used in moderation as it can slow performance for the end user. For example, the user clicks save but has to wait while the workflow runs before the screen refreshes
- This will run before any background processes waiting to run
- In the case of Real-Time workflows you can also switch who the workflow run as. This means who is shown as the “Modified By” and whose security is used. By default this is the Owner of the workflow except in the case of On-Demand where it is whoever triggered it. For Real-Time workflows you can select which behavior to follow.