Last week I took a look at event subscribers to see if there was a order if multiple ones got fired at the same time. It seemed like if there are multiple subscribers to an event, they are fired in order of codeunit ID and then in order they appear in the codeunit. This post I want to see if this is the same for workflow step responses. As you can have multiple responses to a single step. Again, this shouldn’t be an issue. As each response should be coded in a way that the responses are independent of each other. But if for whatever reason you have your responses rely on each other, knowing the order they fire is definitely needed
We are going to go back to our Customer Create event that we turned into a workflow step and work with that. To test this, we are going to make responses on two different codeunits. These responses will simply display a message box so we can see what code runs first. To set up our responses we need to create a function that subscribes to the “OnAddWorkflowResponsesToLibrary” from the “Workflow Response Handling” codeunit. In this function we also need a “Workflow Response Handling” codeunit variable. Our response adding function should look something like this:
WorkflowResponseHandling.AddResponseToLibrary('RESPONSEONECODE', DATABASE::Customer, 'Show message one.', 'GROUP 50000');
WorkflowResponseHandling.AddResponseToLibrary('RESPONSETWOCODE', DATABASE::Customer, 'Show message two.', 'GROUP 50000');
To handle the responses we need an other function that subscribes to the “OnExecuteWorkflowResponse” event from again the “Workflow Response Handling” codeunit. We also need a “Workflow Response” record variable.
[EventSubscriber] ExecuteResponses(VAR ResponseEeecuted : Boolean; Variant;xVariant : Variant; ResponseWorkflowStepInstance :Record "Workflow Step Instance")
IF WorkflowResponse.GET(ResponseWorkflowStepInstance."Funcation Name") THEN BEGIN
CASE WorkflowResponse."Function Name" OF
MESSAGE('Response one FIRE!');
ResponseExecuted :- TRUE;
MESSAGE('Response two FIRE!');
ResponseExecuted :- TRUE;
Do the previous again for an other codeunit, but with different messages so we know which one is actually firing. Now that we have our responses and the function to add our responses, we just have to set up the workflow.
Now lets test it. When we create our customer we can see all four message appear. They appear in order, message one, message two, three and four. So we should try changing the order the responses were added to the responses list. Lets put the fourth response after the first one. Create another customer. This time we see the message in the order of first, fourth, second, third. Wooo! A pattern. Doing a few more tests like changing IDs, code names, and a few other settings don’t seem to do anything to the order of our responses. Only changing the order that they appear in the reposes list has any effect.
So, if for some reason the order of responses matter to you when making workflows. Just remember that they go in the order you put them in. Proper design would state that each response should be independent of each other. But this is Nav and you sometimes just have to break convention. Even though we had two different subscribers to the “OnExecuteWorkflowResponse” event. It didn’t matter about the codeunit IDs. This is because in each subscriber we only act when we see the appropriate code, and act accordingly.