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);

[Laszlo Balla]

I won't be able to give you step by step instructions based on this, but what you need to make sure of is basically that you follow the state model with your updates on the change requests.

For example, let's say want to set a normal change request to Closed state, that is currently in Scheduled state:

• The Closed state has an "Enter condition" that defined State = Review, which means that the change request must be in Review state, before it can be set to Closed.
• So let's look at Review next. Is has the enter condition State = Implement, so the change must be in Implement state before it can be set to Review.
• So now we look at Implement state in our state model. We see that is has the enter condition State = Scheduled, so this is our final stop here.

In the above example, your flow would need to have 3 separate update record steps to move a change request from Scheduled to Closed:

1. Scheduled --> Implement
2. Implement --> Review
3. Review --> Closed

As I mentioned, this is an example only, your actual details will depend on how the state model looks like for changes in your system (which is probably different for each change model).

In case you don't want to bother with multiple updates, your can update your state models (or create new ones) where you change the enter condition for your target state, e.g. by allowing to set Closed not just from Review, but from some other states as well. That way, a single update in the flow would be enough, and the business rule would work as well (however as I mentioned earlier, it would also allow your users to set a change to Closed from other states, unless you apply further restrictions).

If you think this is too cumbersome, you are right. There is a good reason why ServiceNow created a strict state model for Change Requests. as the Change Management process is a quite delicate one that gets audited a lot, and you simply don't want people to skips certain stages of the process and so on.

[Arjun Reddy Yer]

If I create the Business Rule / Flow Designer as per the below mentioned state of Change Request depending on Catalog Task will it be work @Anurag Tripathi @Laszlo Balla @priyasunku @Ankur Bawiskar @BharathChintala @Sumalatha Y @AnveshKumar M @Allen Andreas @asifnoor @Brad Tilton @Pradeep Sharma 

Catalog Task                                           Change Request

1. New                                           =     New

2. Open                                         =     Scheduled

3. Assigned To                              =     Implementation

4. Work In Progress                     =     Review

5. Closed Complete                     =     Closed

6. Closed Incomplete/Skipped   =     Canceled 

[Laszlo Balla · Accepted solution]

@Arjun Reddy Yer once again, please look at the different state models for your change requests:

State Management --> State Models. Look for state models that are active and have the table set to change_request. Do you have any records there?

If not, you will need to modify the script include for changes, again, per change model. The good thing is it's documented, check here.

For reference, check out this link too about state progression, which might give you an idea why your record updates always landed at Cancel state.

[Arjun Reddy Yer]

As below mentioned Script is there in Script Include.

So, if I skip Review or Implement State in Change Request then the State of Change Request will get auto Canceled State right.

To get this out what should I need to do exactly can anyone help me @Anurag Tripathi @Laszlo Balla @priyasunku @Ankur Bawiskar @BharathChintala @Sumalatha Y @AnveshKumar M @Allen Andreas @asifnoor @Brad Tilton @Pradeep Sharma @Sonu Parab 

Script Include:

var ChangeRequestStateModel_standard = Class.create();
ChangeRequestStateModel_standard.prototype = Object.extendsObject(ChangeRequestStateModelSNC_standard, {
draft: {
nextState: [ "scheduled" ],

scheduled: {
moving: function() {
return this.toScheduled_moving();
},

canMove: function() {
return this.toScheduled_canMove();
}
},

canceled: {
moving: function() {
return this.toCanceled_moving();
},

canMove: function() {
return this.toCanceled_canMove();
}
}
},

scheduled: {
nextState: [ "implement" ],

implement: {
moving: function() {
return this.toImplement_moving();
},
canMove: function() {
return this.toImplement_canMove();
}
},

canceled: {
moving: function() {
return this.toCanceled_moving();
},

canMove: function() {
return this.toCanceled_canMove();
}
}
},

implement: {
nextState: [ "review" ],

review: {
moving: function() {
return this.toReview_moving();
},

canMove: function() {
return this.toReview_canMove();
}
},

canceled: {
moving: function() {
return this.toCanceled_moving();
},

canMove: function() {
return this.toCanceled_canMove();
}
}
},

review: {
nextState: [ "closed" ],

closed: {
moving: function() {
return this.toClosed_moving();
},

canMove: function() {
return this.toClosed_canMove();
}
}
},

closed: {},

canceled: {},

type: "ChangeRequestStateModel_standard"
});

[Anurag Tripathi]

Add Log to see if the code is coming into the if condition.

There could be some other BR in the system that might be aborting the operation.