MrDave's (David Yack) CRM Blog!

One of the things you might want to do is trigger a workflow to run from the web service API. Using this you are able to trigger the workflow without having a platform event. The ExecuteWorkflowRequest and ExecuteWorkflowResponse messages are provided by the API to allow this to happen.

In order to make this happen we must first create an instance of ExecuteWorkflowRequest. This class exposes two public properties to set prior to making the request

public Guid WorkflowId { get; set; }

The WorkflowId property indicates which workflow instance you want to invoke. There’s a number of ways you could retrieve this Id the simplest is by double clicking on the workflow from the list of workflows and grabbing the GUID from the edit page. As you can see below the GUID is highlighted.

While this works, it’s pretty fragile because if you were to try this on different installs the ID for any given workflow would be most likely different. Another way you could accomplish this is by doing some sort of a query using a Retrieve to get the workflow ID. In this scenario you could be more specific on the Name given to the workflow – you still might need to deal with the fact there could be multiple with the same matching name.

public Guid EntityId { get; set; }

The other public property is EntityID. This property indicates the ID of the primary entity that is being processed. Expect an exception to be thrown by the service.Execute method if you don’t provide a value or it can’t find the value being passed.

The ExecuteWorkflowResponse is a simple class and only provides one property that you can evaluate and use.

public Guid Id { get; set; }

This property returns you the ID of System Job AKA asyncoperation entity instance that was created to track this request. Using that ID, you could query the System Job to monitor status or perhaps retrieve the workflow log instances associated with the System Job.

Now let’s look at a complete example – this example assumes a few things. First, GetService does just that using the magic you use everywhere else. RetreiveFirst simply does a retrieve by a string attribute and gets back a DynamicEntity (simple collection of properties). Finally, I’m assuming a fixed GUID for the EntityID – obviously you would set that as appropriate in your solution.

GetService();

DynamicEntity workFlow = RetrieveFirstBySingleString("workflow", "name", "MyTestWorkflow1");

ExecuteWorkflowRequest req = new ExecuteWorkflowRequest();

Key key = workFlow.Properties["workflowid"] as Key;

req.WorkflowId = key.Value;

req.EntityId = new Guid("957F7F2A-D26F-DC11-97B3-0003FF71B934");

ExecuteWorkflowResponse resp = _service.Execute(req) as

ExecuteWorkflowResponse;

The SDK documentation is a little light on this currently (says TBD) so take this with a grain of salt and we will explore it in more detail and some possible ways to use this when the full documentation is available.