Automatically approving change request

Joe Stoner
Kilo Contributor

We created a business rule, based on sysapproval_approver, that should automatically approve a change request if the creator of the change request is a member of the approval group. The script seems to work, but the change request then throws an "invalid update" error, and the state of the change request moves back to new. Has anyone else encountered this? Is there a better way to achieve this same functionality?

Here's the code we're using:

skipSupervisorApproval();

function skipSupervisorApproval(){

  var sys_user_table = new GlideRecord('sys_user');

  var creater_sys_id;

  sys_user_table.addQuery('user_name', current.sys_created_by);

  sys_user_table.query();

  while(sys_user_table.next()) {

  creater_sys_id = sys_user_table.sys_id;

  if(creater_sys_id == current.approver){

  //set the state to approved and add comments

  current.state = 'approved';

  current.comments = "Marked by system as 'Approved' because I requested the approval and I am also in the approver group.";

  }

  }

  }

3 REPLIES 3

Pradeep Sharma
ServiceNow Employee
ServiceNow Employee

Hello Joe,



Invalid update message is generally seen when there is the Business rule on the table aborting the update. Can you please check for the same on your instance once.


karthik73
Mega Guru

Hi Joe,



You are not setting the approval to 'Approved', hence setting the task as approved gets invalidated.



you can write a BR on the sysapproval table to run only for CR



if(current.approver == current.syapproval.sys_created_by){


current.state = 'Approved';


current.update();


}



This should update the approval state on the task type to approved


Dominik Simunek
Tera Guru

Hi Joe,



The reason of that behavior is this business rule "State model - Can change state?" which checks if the transition from previous state to current state is valid. In your case the issue is that once you Request Approval for a change request, the workflow is executed, it generates the approvals that are auto-approved immediately and so the workflow goes further to Authorize or Scheduled state (depending if the user is approver also for CAB approval). But all this happens within one update and even before it is stored in database. Once system tries to store the record, it looks like you moved from New state to Authorize or Scheduled directly which is not allowed.



I am not sure now about the best solution to this. You could allow such transition in change management configuration, but this can have other impacts as it changes the state model.



Other option is instead of approving the user approval directly in the business rule, just generate an event for "delayed" auto-approval. You could have then a script action that would approve it few seconds later when Change Request is already saved in "Assess" state and so once approved transition from Assess to Authorize is valid update.


(function executeRule(current, previous /*null when async*/) {



  var userGR = new GlideRecord('sys_user');


  if (userGR.get('user_name', current.getValue('sys_created_by'))) {


      if (userGR.sys_id == current.approver) {


          // to be auto-approved later


          gs.eventQueue('sysapproval_approver.auto_approve', current, gs.getUserID(), gs.getUserName());


      }


  }



})(current, previous);



In the history you should then see nicely that change request was firstly saved from New state to Assess state and later on approved and moved to Authorize state.



Best regards,


Dominik