how to auto set a state field depend on another table state field in servicenow

[Arjun Reddy Yer]

I got a task to auto set a state field depend on another table state field in servicenow.

As I tried with the below mentioned script but when the Catalog Task state changes to "Work in Progress" then the Changes Request state is changing to "Scheduled" after that when the Catalog Task State value changes to "Closed Complete" then the Change Request state value is changing to "Canceled" instead of "Close". With the logs able to view that only sample enter 1 is executing. @Allen Andreas @Brad Bowman  @Community Alums @Laszlo Balla @AndersBGS @Mark Roethof @Anurag Tripathi 

Task Table Values of State Field:

Change Request Table Values of State Field:

Business Rule which had written

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

var gr = new GlideRecord("change_request");
gr.addQuery("parent", current.request_item);
gr.query();
if (gr.next()) {

if(current.state == '2')

{
gr.state = '-2 || -1'; //choice Value For Scheduled or Implement
gs.info('sample enter 1');
}
else if (current.state == '3')
{
gr.state = '3'; //Choice Value for Closed
gs.info('sample enter 2');
}

else if(current.state == '4')
{
gr.state = '4'; //Choice value for Cancelled
gs.info('sample enter 3');
}

else if(current.state == '1')
{
gr.state = '-5'; //Choice value for open
gs.info('sample enter 4');
}
gr.update();

}
})(current, previous);

[Anurag Tripathi]

Try this

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

var gr = new GlideRecord("change_request");
gr.addQuery("parent", current.request_item);
gr.query();
if (gr.next()) {

if(current.state == 2)

{
gr.state = -2 ; //choice Value For Scheduled or Implement
gs.info('sample enter 1');
}
else if (current.state == 3)
{
gr.state = 3; //Choice Value for Closed
gs.info('sample enter 2');
}

else if(current.state ==4)
{
gr.state =4; //Choice value for Cancelled
gs.info('sample enter 3');
}

else if(current.state == 1)
{
gr.state = -5; //Choice value for open
gs.info('sample enter 4');
}
gr.update();

}
})(current, previous);

[Arjun Reddy Yer]

Tried with the below script but when the Catalog Task state changes to "Work in Progress" then the Changes Request state is changing to "Scheduled" after that when the Catalog Task State value changes to "Closed Complete" then the Change Request state value is changing to "Canceled" instead of "Close". With the logs able to view that only sample enter 1 & 2 are executing.

Task Table Values of State Field:

Change Request Table Values of State Field:

Business Rule which had written

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

var gr = new GlideRecord("change_request");
gr.addQuery("parent", current.request_item);
gr.query();
if (gr.next()) {

if(current.state == 1)

{
gr.state = -5 ; //choice Value For open
gs.info('sample enter 1');
}
else if (current.state == 2)
{
gr.state = -2; //Choice Value for Scheduled
gs.info('sample enter 2');
}
else if(current.state == 3)
{
gr.state = 3; //Choice value for Closed
gs.info('sample enter 3');
}
else if(current.state == 4)
{
gr.state = 4; //Choice value for Canceled
gs.info('sample enter 4');
}
gr.update();

}
})(current, previous);

[Laszlo Balla]

First of all, your script had a few flaws that Anurag fixed for you. 👏

Second, the state transitions for change requests are defined in their state models (typically 1 state model / change model). There is an out of the box business rule called 'State model - Can change state?'  that will verify that any state changes on a change request adhere to the respective state model.

So how can you deal with this? You have a few options, what you pick depends on your overall Change Management process, instance governance practices, etc. so consider carefully:

• You can edit the "Enter conditions" for the Closed state in the respective state model(s), so that for instance Closed state can be entered not just from Review state. One of the drawbacks is that this would also allow your users to set this state on the form from other states (unless you add other restrictions).
• You can follow the existing state model and do multiple, consecutive updates on the same change until you get to Closed. Doing this might be better managed in a Flow Designer (sub)flow rather than a BR. The drawback is clear, multiple, seemingly unnecessary updates to the server, that would trigger all other BRs every time, etc.
• You could also just disable or edit the OOTB BR, which may not be such a good idea, as in my opinion it does more good than trouble in the change process, but it's up to you.
• You could try adding gr.setWorkFlow(false); before your gr.update() line in your script, which should prevent the running of any subsequent BRs, including the OOB one mentioned above. Be careful with this, as it will also prevent the running of any other BRs, so it might not be such a good idea.

I am sure there are many other options to work around this, these are just some initial ideas to get you started. Here is the knowledge article on the support site about this.

[Arjun Reddy Yer]

As there is 'State model - Can change state' Business Rule which is over riding my Business Rule.

Can I know the things to keep in Flow Designer so that the State of Change Request will be auto change when the Catalog Task State changes. @Anurag Tripathi @Laszlo Balla @priyasunku @Ankur Bawiskar @BharathChintala @Sumalatha Y @AnveshKumar M @Allen Andreas @asifnoor @Brad Tilton 

Flow Designer: