Dynamics Community Forum Thread Details

On-demand Synchronous (Real-time) Workflow on the Unified Interface app

Hello

Microsoft recently announced that CRM users are forced to take the Unified Interface into use by fall 2020, so I've created a Unified Interface app for our CRM for a review.

We use a few Workflows, one of which is assigning incoming Leads to Users based on information stored in the associated Product.

The Product holds fields for Owner, Coworking User, and a field (Last Assignee) to store whom the previous lead was assigned to.

The Workflow is run as an on-demand, real-time Workflow to selected multiple Leads on a (queue) view.

The workflow is able to split every second Lead between Product Owner and Coworking User, and it does this by keeping a record on whom the Lead was assigned (Product owner or the coworking User) to previously. Therefore it is essential that each lead is processed before processing the next one.

In the traditional interface, the workflow is run on one Lead at a time, so it works perfectly.

In the Unified Interface, however, it seems to run asynchronously in the background and does not update Last Assignee right.

Does anyone know a) will Microsoft make real-time workflows work on the Unified Interface in the same way as they do now or b) is there a way to make it execute one by one in the background?

Hello,

First, synchronous workflows always run synchronously, both on legacy web client and Unified Interface.
However on Unified Interface they might not be handled the same way, and that might why you get the impression that they run asynchronously.

For example in the legacy web client, the view is automatically refreshed after the workflow is run, and it reflects the changes that were made.
In Unified Interface, you need to manually refresh the view after the workflow execution to reflect the changes.

If you capture Fiddler traces, you can have more details on what is actually happening:

Legacy web client - on 3 accounts: 3 sequential POST requests are made
Each record is processed in sequence and one call is made per record to run the workflow:

POST /_grid/cmds/dlg_runworkflow.aspx?iObjType=1&iTotal=1&iIndex=0&wfId={40F602BF-84C8-4E6D-8F48-3AD0B04833DF}&sIds=&iId={48FF807B-9E7C-E911-A96A-000D3AB45D02}
POST /_grid/cmds/dlg_runworkflow.aspx?iObjType=1&iTotal=1&iIndex=1&wfId={40F602BF-84C8-4E6D-8F48-3AD0B04833DF}&sIds=&iId={5DC35205-3B9E-E911-A96D-000D3AB45014}
POST /_grid/cmds/dlg_runworkflow.aspx?iObjType=1&iTotal=1&iIndex=2&wfId={40F602BF-84C8-4E6D-8F48-3AD0B04833DF}&sIds=&iId={DE0553AE-2181-E911-A96A-000D3AB45D02}

And then there a grid refresh:
POST /AppWebServices/AppGridWebService.ashx?operation=Refresh

Unified Interface - on 3 accounts: 1 single POST batch request
When the workflow is run on multiple records, a batch request to the Web API, meaning it's optimized to make only one call to the server, and this single call contains the instruction to run the workflow on multiple records:

POST /api/data/v9.0/$batch

The body of that request contains the instruction to run the workflow on the 3 records (the EntityId is different):

--batch_1578054265243
Content-Type: application/http
Content-Transfer-Encoding: binary

POST /api/data/v9.0/workflows(40f602bf-84c8-4e6d-8f48-3ad0b04833df)/Microsoft.Dynamics.CRM.ExecuteWorkflow HTTP/1.1
Accept: application/json
Prefer: odata.include-annotations="*"
Content-Type: application/json;type=entry

{"InputArguments":null,"entity":{"@odata.type":"Microsoft.Dynamics.CRM.workflow","workflowid":"40f602bf-84c8-4e6d-8f48-3ad0b04833df"},"EntityId":"48ff807b-9e7c-e911-a96a-000d3ab45d02"}
--batch_1578054265243
Content-Type: application/http
Content-Transfer-Encoding: binary

{"InputArguments":null,"entity":{"@odata.type":"Microsoft.Dynamics.CRM.workflow","workflowid":"40f602bf-84c8-4e6d-8f48-3ad0b04833df"},"EntityId":"5dc35205-3b9e-e911-a96d-000d3ab45014"}
--batch_1578054265243
Content-Type: application/http
Content-Transfer-Encoding: binary

{"InputArguments":null,"entity":{"@odata.type":"Microsoft.Dynamics.CRM.workflow","workflowid":"40f602bf-84c8-4e6d-8f48-3ad0b04833df"},"EntityId":"464b65e3-b698-e911-a968-000d3ab4594e"}
--batch_1578054265243--

When executed in batch, workflows might be executed in parallel and not in sequence, like in the legacy web client, hence explaining what you are experiencing.
I would advise that you raise a support request https://admin.powerplatform.microsoft.com/support for guidance.

As an alternative, you might be able to achieve your goal by a mix of workflows and custom actions (C#) that could lock your related "Product" entity to make sure it's not being updated by parallel executions.
Some useful resources if you want to go that way (they refer to auto-numbering, but it's a fairly close problem):
Scalable Customization Design in Microsoft Dynamics CRM: download the document called ScalableDynamicsCRMCustomizations.docx. It is a white paper that contains a "Why it’s important to understand transactions: Auto numbering example."
This blog article can also help: How to Implement Robust Auto-Numbering Using Transactions in Microsoft Dynamics CRM.

Henry

Quick Links

Leaderboard