Best Practices of Workflow Structure for Microsoft Dynamics 365

Adam Murchison, 11 September 2017

This blog is going to help the reader to create workflows with the best, most desirable structure. This will allow the workflow to be easily readable, modifiable, and shows the user when their workflow stops or has errors specifically within the workflow.

To show the best practices while creating a workflow I am going to show an example of a workflow. The workflow will consist of; when an account is created with the address as “Christchurch” and when the Main Phone field contains data, call the account owner, and wait until the account owner has been contacted then assign a task. This will easily show the reader how to create a structured workflow.

Example: Undesirable Structure for a Workflow (Nested Check Conditions)

Example: Desirable Structure for a Workflow (Easily Editable Conditions)

Stopping the Workflow and Notifying Where it has Been Stopped

The first key point when structuring a workflow is to have the check condition (if statement) state: “If (Condition) does not satisfy a constraint” then “Stop the Workflow”. The reasoning why this is desirable is that it shows exactly where the work flow fails or stops.  This is shown in the screenshot for: “Desirable Structure for a Workflow”. Also, the user can “Set Properties” for the output in the System jobs section (Settings -> System -> System Jobs).

 
For example, if the account wasn’t from Christchurch, then the workflow would stop at that specific check condition. Assuming that the user set properties for the “Stop workflow with status of:” section then their message would appear in the System Jobs.

Avoiding the Maximum Depth (Max Depth = 5) with Conditions

Another key point when structuring a workflow is that if the check conditions are not nested then the implementer will never reach the maximum depth within an if statement. The maximum depth is at 5 conditions so having the conditions separated (like in the desirable structure) allows the implementer to avoid this.

When one tries to click “Add Step”, they are unable to.

Easily Editable Workflows

The final key point when structuring a workflow is that at a certain point in time, the implementer may not want the workflow to check if the Account is from Christchurch or some other condition. Deleting a step, especially the base step, is extremely frustrating when the conditions are nested. When the conditions are in the desirable structure format then deleting and editing the conditions is extremely simple and will save the implementer a lot of time in the long run. When the conditions are nested the editor has to delete all conditions that fall below the condition they’re trying to delete. In the desirable format it is possible to delete any condition within the workflow without modifying the others.