Real Time Workflows in Dynamics 365

Organization’s business logics will always be part of the CRM implementation strategy and mostly they can be classified as two types, one which will get implemented at real time and another one which gets implemented little late termed as synchronous and asynchronous in nature. In Dynamics 365 for customer engagement, workflows helps us to automate business processes without a user interface especially when we don’t require any user interaction. Recently Microsoft is moving towards the strategy where they are encouraging to use Power Automate in case we have to run some logic in the background as asynchronous workflows. But real-time workflows are still our old workflows. In this blog, we will discuss about the real-time workflows in detail.

As you might be aware, workflows in dynamics 365 refers to the customization part where the administrator or a functional consultant can design workflows in such a way that the logic we want can be performed using stages and steps, mostly without the need of writing code. Stages do not really affect the logic or behavior of workflows but that makes the workflow logic easier to read, and explain the workflow logic. Steps are the actual unit which contains the business logic. Steps is what holds the conditions, actions, other steps or a combination of these elements. We can include different actions to the workflow along with different conditions as required by the business. Lets get a deep dive into each of these ideas in details below.

Actions, Conditions, Triggers and Setting value

Workflows are used to implement business logic and without performing something how can we get it done. That is where actions come into place and we have a pretty good list of actions available out of the box which does particular task for us. Below is a list of them.

• Create Row: Create a new record in the system and gives us the option to set values statically or dynamically.
• Update Row: Updates an existing record in the system.
• Assign Row: We can assign a record in real time.
• Send Email: Sends an email. When we are sending an email, it can be either after creating a new email message or it can be from an email template configured.
• Start Child Workflow: Starts a real-time workflow process that has been configured as a child workflow.
• Change Status: Changes the status of the record.
• Stop Workflow: Stops the current workflow. We can set the status of the workflow either to succeeded or cancelled and specify a status message. If we are configuring it to be cancelled then it will prevent the event action from completing an displaying the user with the heading Business Process Error along with the status message configured.
• Custom Step: This is where the beauty of the workflow lies (personal opinion). It gives us the opportunity to extend the workflows in such a way that developers can create custom workflow steps that define a specific action and can be used as a step inside a real-time workflow. You can read more about this here.

While we are doing an action, we can set values of records using the Set Properties where we get the option to set valued for the record, append, increment, decrement, multiply or clear values. This can be even done for those fields which are not part of the form. We can set either static or dynamics values using the form assistant. This gives us the ability to pull in valued from current record as well as from related record where we have many to one relationship. Form assistant itself helps in filtering the values which will fit into the field depending on the data type.

When we talk about logic one of the possible thing which we can’t avoid is putting a condition as that will be a common case in most of the real time scenarios, for example for a particular department the logic might be in one way and for another one the logic might be in another way. For this also workflows gives the have an option to include conditions and branching to accommodate the real time scenarios for the business. Different options we have are,

• Check Condition: This is nothing but a logical if-then statement, where we can check for a condition and if it matches then implement a specific logic. We have the option to use the most common operators like Equal, Does Not Equal, Contains Data, Does Not Contain Data, Under and Not Under. In these operators Under and Not Under can only be used for tables/entities which are enabled with hierarchical relationship.
• Conditional Branch: This is another logical statement which used “else-if-then”. We can include this by selecting another check condition and have this added and both combined gives us the complete if-else-then kind of set up.
• Default Action: Logical “else” statement. We can club this with check condition, conditional branch, wait condition, or parallel wait branch previously defined to use a default action and include steps to implement branch elements to execute the scenario of else part of logic.
• Wait Condition: Enables this workflow to wait/pause until a particular criteria is defined. Workflow will automatically resumed when the criteria is met. This is normally used for background/asynchronous workflows and not for real-time workflows.
• Parallel Wait Branch: This is the wait logic which can be used by the real-time workflows. These steps will be performed only when the initial criterion is met. This can be used to create time limits in workflow logic and help in preventing the workflow from waiting indefinitely until the criteria defined in a wait condition have been met.
• Custom Step: This gives us the opportunity to extend the workflows in such a way that developers can create custom workflow steps that define a specific action and can be used as a step inside a real-time workflow. You can read more about this here.

We have talked about the actions and conditions in which the actions will be executed. For automating processes, we are missing one more component which is the trigger for these actions. We do have the option to trigger these workflows either after or before a particular action in the system. Here After corresponds to the PostOperation and Before corresponds to the PreOperation. This can be tied up with either Create, Status Change, Assign, Update, or Delete. Except for Create and Delete all others have the option for the workflow to start either after or before the action while Create only have the option After and Delete only have the option Before which is logical. Even though real-time workflows gives us immediate result, its always recommended to use background workflows as it gives the server option to scheduled the activities as per the availability of resources and thus making sure server is not loaded unnecessarily. This will ensure the performance of the system is on the better side. Everything comes with a disadvantage or drawback. Here we cannot predict when the workflow will get executed. So the ground rule would be in case we want to immediately see the results of the process or need the ability to cancel the operation use the real-time workflow. System gives us the option to toggle between background and real-time workflow through a convert button in the toolbar. In case we are converting a background workflow to a real-time then any wait condition which was part of the background workflow will become invalid and we won’t be able to activate that until we convert the workflow back to background.

Best Practices

Everything in the world comes up with best practices to make sure we are getting the better of the better results. Our real-time workflow is not an exception as well.

• Avoid infinite loops, even though system takes care of this to some extend by cancelling the workflow after running it for a maximum of 16 times, its better for us to make sure we use the resources judiciously.
• User real-time workflow templates – this is more towards using an existing pattern and thus reducing chances of human error to the maximum.
• Use Child Workflows – This is something similar to creating a method and call that instead of repeating the same logic in multiple places.
• Keep the logs for real-time workflow jobs that encountered errors.
• Limit the number of workflows that update the same table – this is required to make sure we are not creating a situation of locking the table by running multiple instances of all these workflows and thus resulting in locking the table.
• Use Notes to keep track of changes – This is more of a process related practice to make sure the team has a very good transition plan in place from day 1.

I was trying to create a capsule like write up to include everything we need to know about real-time workflows in dynamics 365. Hope I was successful in that attempt and this blog helped you in someway. Thanks for your time reading this blog.