Why the RITM's workflow that ends when REQ is auto approved, does not close the RITM record - Support and Troubleshooting

Why the RITM's workflow that ends when REQ is auto approved, does not close the RITM record Issue The REQ is auto approving, the workflow running on RITM that does not have any tasks or approvals, or the workflow follows a path where it reaches the end activity. However, the RITM still remains open.

In this example, I keep things simple, the only customization in this sample workflow is the stage on the "end" activity being set to "completed."

While the expected behavior in this scenario is that when the workflow ended, the RITM's state should have set to "close completed," active field should have moved to false and set all the closure fields.

If we review the XML of the RITM, we can see that the state is still "work in progress," active field is still true, and none of the closure fields were set (closed_at, closed_by)

From the calendar history, we see the following on the RITM, the record was created, followed by an update, which moved the stage field from "waiting for approval" to "Completed." Which is what we have set our workflow to do.

Release All

Cause What did not happen was the business rule "Set Active Flag" (before, 100), this BR should have triggered based on the stage changing to "complete" but did not.

The sequence of business rules that should have triggered to set the fields, active, state, closed_at, closed_by are ran in the following order: Set Active Flag (sc_req_item, before, 100, [insert, update]) , this is triggered by the stage changing to "complete" and is responsible for setting the active field to false.

Task closer (task, before, 900, [insert, update]) , this is triggered by the active flag changes to "false" among other checks (inOpenState & InSupportedTable), and is responsible for setting the state field to "Closed Complete"

Set Closure Fields (task, before, 10000, [insert, update]) this is triggered when active changes to false, and is responsible for setting the closed_by & closed_at fields.

So why did these business rules not triggered?

Before we answer this question, let's figure out how the RITM's workflow got triggered. As we already know the RITMs get created first and then the request. When the request record is inserted this triggers its workflow. Which auto approves the request, this, in turn, kicked off the following business rule:

Cascade Request Approval to Request Item (sc_request,after, 1300,[insert, update]) , when the approval changes, this, in turn, propagates the state down to the requested items, in this case, "approved" from the script we can see the following:

if (gr.stage == "waiting_for_approval" && current.approval == "approved") {

gr.approval = "requested";

gr.stage = "request_approved";

And then later on:

gr.update();

In summary, the requested items are created by default with a stage of "waiting_for_approval" which is waiting on the gated approval from the request's workflow. However, in this case, the request's workflow auto-approved, and trigger the above code, changes the stage to "request_approved" and sending the dot update to the RITMs. This is the update being done on from the calendar history (see above screenshot).

So with the stage being moved to "request_approved" and the RITMs being updated, this triggers the next business rule, in this glide record update:

Start Workflow (before, 10000) , when the stage changes to 'request_approved' this BR launches causing the RITM's workflow to start.

var context = w.startFlow(id, current, current.operation(), getVars());

Note, that the startFlow method from the Workflow script include does not cause the changes from the workflow launching to commit, that is being done from the glide record update from the previous business rule. In other words, if we were to manually launch this workflow from "Scripts - Background' module, the workflow will launch and a context would be created, however, the "end" activity setting the stage to "completed" will not be committed. You will need to do a glide record update, following this script for the workflow changes to commit.

So with this BR launching by the glide record update, once the BR finishes, we can see from the "when" and "order" of the first three business rules (Set Active Flag, Task closer, Set Closure Fields) they will not run again. The requested item, because of the workflow moving the stage to "completed" will have committed. As we can see in the calendar history above.

Resolution out-of-the-box we have two business rules that were introduced in Madrid that would resolve this issue. Set Active Flag After Workflows (sc_req_item, before, 10,100, [insert, update]) (/sys_id=3c1faea173002300097f6508caf6a7b9) Set Closure Fields After Workflows (task, before, 10,200, [insert, update]) (/sys_script.do?sys_id=8ebfaa6573002300097f6508caf6a7c3)

You will have to enable both if you're facing this issue as both are disabled by default

Note that even after enabling these new Business Rules, the state will not be set. Due to "task closer" not running again, you could copy this business rule and set the order to 10,150 so that it's sandwiched between the new business rules. However, customers usually set the state via the "Set Values" workflow activity.

Related Links PRB1269804: Added Set Closure Fields for after workflows