![Microsoft Dynamics 365/CRM User Group]()
Workflows are an incredibly powerful tool for admins in Microsoft Dynamics 365/CRM that allow them to implement logic without using customization code.
There are various Use Cases for Workflows, and you can really use them for a variety of things, but when it comes to the difference between Real-time vs. Background Workflows, what separates them may not be as clear.
The differences between Real-time vs. Background Workflows are important for admins to know when navigating this dynamic tool.
First of all, Real-time Workflows roll back all changes if it fails. As the Workflow is going through the process itself, if it fails, it will roll back all of the prior steps taken.
Whereas, with Background Workflows, actions will not roll back if it fails. All changes are up-to-date until the failure occurs. The workflow will stop at this point due to the failure.
Real-time Workflows, of course, run in real-time on the form, so changes will be noticed instantly by users. As soon as you hit save, changes will be noticed.
Background Workflows run behind the scenes and require page refreshes to be seen.
Uncheck the box that tells you to delete process sessions to allow you to troubleshoot if anything goes wrong during your Workflow while using Background. This is essential to your progress and use of a Background Workflow.
Successful process sessions are deleted in Real-time, whereas you can review them with Background Workflows when you uncheck the box mentioned above.
Real-time Workflows require the user to wait until it completes, however, in most cases, it is not noticeable to the user. You must also consider that the user is not waiting until it completes and can work until it completes with a Background Workflow.
Real-time requires more system resources, whereas Background Workflows do not.
Real-time Workflows can run as the user triggers that Workflow, but Background Workflows run as the Owner of the Workflow and both Real-time and Background run as the User that triggered the Workflow if they are run on-demand.
Last, but not least, Real-time Workflows will show the errors to your users as they occur so you know the workflow failed, while a Background Workflow will not show you that it failed.
The only way to tell that a Background Workflow is failing is to perform a review of your System Job Failures, this is also known as a Monthly Health Check, this can be a lifesaver for an Admin.
Whatever style you use, you want to prevent multiple Workflow triggers from causing problems. So, imagine the Vice President of Sales within your company wants to be notified of top-level opportunities.
There are times when you want to send an email to your Vice President based on certain conditions, Est. Revenue over $50,00 for example, but this condition can be triggered multiple times, so you set a flag to be set at the end of the workflow to be set so that a second email does not get sent.
With Background Workflows, if the user filled it out to $50,000 and quickly changed it to $50,001, the Workflow would now be triggered twice, so now everything will fall together and go through the process, but as the conditions are met, both will be sending emails because with Background Workflows processes can run at the same time and our flag to prevent multiple emails has not yet been checked.
With Real-time, the process must through the entire process and checkmark the flag before the next triggered workflow process start.
Because of this, the VP is only notified once and the second process run is stopped by the conditions of the Workflow.
Consider the importance of checking this. You don’t want to be sending multiple notifications to your customers, right?
It’s important you check all the boxes with Workflows that you need to, but it’s even more important you check all the marks when it comes to realizing their full potential.
To learn more about the possibilities of using Workflows in your organization and how to use them, watch our latest user group webinar here.
![Microsoft Dynamics 365 CRM User Group Webinar]()
![]()
