CRM 2013 Beta: Real-Time Workflows

In this post I shall discuss real-time workflows, a very nice functionality that Microsoft introduced in Dynamics CRM 2013. The concept of workflows have been around since Dynamics CRM 3.0, but throughout the releases for Dynamics CRM 4.0 and Dynamics CRM 2011, workflows have always been asynchronous (once triggered, the process is run in the background). In this latest incarnation of Dynamics CRM 2013, the ability to build real-time workflow means developers no longer have to rely on writing client-side JavaScript or CRM plugins to handle synchronous processes.

Note: Workflows in Dynamics CRM should not be confused with “Business Rules” and “Business Process Flows”. For more information on both of those topics, see my earlier posts on Business Rules and Business Process Flows.

Real-Time Workflows

Note: CRM 2013 is not due to be released until October 2013. The information provided in this blog might different from the final product.

The ability to build (asynchronous) workflows have been around since the release of Dynamics CRM 3.0 (and CRM 4.0 and the current release of CRM 2011). In Dynamics CRM 2013 however, Microsoft introduced Real-Time Workflows, which means developers no longer have to rely on writing client-side JavaScript or CRM plugins to handle synchronous processes.

Some key points about real-time workflows:

  • Real-time workflow runs in the same transaction at the same time as the event that triggered off the workflow in the first place. That is, if a workflow is set to fire on the creation of an account record, the workflow process will now be handled by the w3wp worker process. If for some reason the real-time workflow is “cancelled” (e.g. user cancelling the workflow or the workflow has a step which sets its own status to “Cancelled”), the whole transaction will be rolled back, including the event that triggers the workflow in the first place, to prevent the entire operation.
  • You can choose to run real-time workflows either as the CRM user who owns the workflow or as the CRM user whose action triggered the workflow. This is set as “Execute As”. It is a useful option for synchronous workflows as there might be operations within the workflow which should be completed by the calling user for audit tracking (e.g. audit tracking should show that the calling user has updated a field that is processed by a real-time workflow). For asynchronous workflows however, they can only be run by the owner of the workflow and not by the calling user in CRM.
  • Real-time workflow offers you the option of starting the process either BEFORE or AFTER the event that triggers the workflow. This mirrors the pre-operation (stage 20) and post-operation (stage 40) pipelines that are available to plugins.


Time to go build some real-time workflows! Let’s start with the following simple requirements:

1) On the creation of an account record, if an end-user completes the “Phone” field, we would like to change the “Contact Method” dropdown on the account form to specify “Phone” option as the “Contact Method.



2) If the “Phone” field is updated afterwards, we want the “Contact Method” and “Phone” preference be set according to the following table

Contact Method Phone Preference
Phone Has Data Phone Allow
Phone Has No Data Email Do Not Allow

3) All changes related to “Contact Methods” for an account must be displayed to the user immediately after account creation or update of “Phone” field.

It is worth emphasising here that the above 2 requirements can be satisfied with either JavaScript or plugin code, whereas workflow will not require any coding at all for this scenario.

Building A Custom Real-Time Workflow

Here is what the workflow builder looks like in CRM 2013: important step here is to leave the “Run this workflow in the background (recommended)” if you are building a real-time workflow.


Here is how I set up my real-time workflow to meet the above requirements.


Key points to note are:

  • I would like the workflow to run “after” account creation and also “after” field changes so I left the “As an on-demand process” and “as a child process” unchecked in the workflow builder.  The “record fields changed” option I have set to trigger on “Phone”.
  • I have set this workflow to execute as “the user who made changes to the record”, as I would like the end-user who creates the account or changes the phone field to also be the logged on the audit as the end-user who sets the “Contact Method” and “Phone” preference.
  • The workflow steps are very simple. It checks if the account record’s phone field contains data or not. If yes, update the account’s “Contact Method” and “Phone” preference
  • If not, update the account’s “Contact Method” and “Phone” preference accordingly

Now all that is needed is to save and activate this workflow. To check this this workflow is functioning correctly, let’s create a new account in CRM using the “quick create” form and set the “Main Phone” number.


Looking at the newly created account record, the workflow has set the “Contact Preferences” to correct values.


Removing the Phone field on this account record will trigger the workflow again and sets the “Contact Preferences” accordingly.


That’s it! No code involved! Very simple!

Of course, workflows can be a very powerful functionality. Even in this new real-time workflow, you can trigger child workflows (real-time or asynchronous) or trigger custom workflow activity (code) after the dll is built and registered in the CRM solution via the Plugin Registration Tool. In fact, the introduction of real-time workflow has blurred the boundaries between workflows and plugins. As a developer, I can now choose to work in either workflows or plugins or JavaScript for many synchronous operations. To me, real-time workflow represents a powerful new functionality in Dynamics CRM 2013.

6 thoughts on “CRM 2013 Beta: Real-Time Workflows

  1. Hi Priscilla

    Thanks for the article!

    A question though…
    I have a real-time workflow (post Create) and a synchronous plug-in (message Create)

    The synchronous plug-in will be executed in stage 40, but will the realtime workflow be part of stage 30, or does it depend on the message used?

    Can I be ensured that the workflow is executed first?
    …or should I built everything into the plug-in or a workflow activity?

    Hope you can help?

    Thanks – kr Bredel

    1. Hello!

      I haven’t tried both a postcreate and a sync (post-op) plugin together, but I suspect the post create workflow will likely also execute at stage 40. If this is the case, which one goes first might depend on complilation date but I am not certain.

      Instead I would ask if you can change your logic? Can all logic live inside a plugin? Or as you say a workflow activity as part of the existing workflow? Or perhaps create an extra “marker” field on the record that can be switched ON/OFF by the workflow, and causes your plugin to fire instead?

      Hope that helps and good luck!

      Cheers, Priscilla.

      1. I agree that one of those would be the most certain way, nevertheless I was just wondering, and haven’t been able to find anything about where in the pipeline stage the real-time workflows are executed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s