Hello @AryanJha ,
In servicenow there is one OOTB business rule which set active field to false when ritm state in closed complete,closed incomplete state. Can you please check that br is active or not . You can also check is there any setWorkflow(false)/setUseEngines(false) done by you during your any script.
Business rule name : Set Active Flag
You can also refer this : https://www.servicenow.com/community/servicenow-ai-platform-forum/issue-with-catalog-item-request-re...
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0791021
If this above article not open then following content is from that article :
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.
If this helps you then you can mark it as helpful and accept as solution.
Regards,
Aditya
