How do I skip "Scheduled" in a change management workflow?

ServiceNowSteve
Giga Guru

Hello all,

I am building out our Change Management piece of ServiceNow and one of the requirements was to skip the "Scheduled" phase and go straight into Implement after approval. If I change the workflow to set the state to implement instead of Scheduled it just doesn't do it and in fact it will freeze up the whole process because it's expecting to first goto Scheduled before it proceeds. We are OOB for the most part, any idea how I can accomplish this?

1 ACCEPTED SOLUTION

nyancer3
Tera Expert

Change request flows are now built on a set of script includes. The script includes come in pairs; one includes "SNC" in the name and is read-only. The other has the same name, but without "SNC" and is available for you to customize. That is the best-practice method for customizing change management for instances running the Change Management - State Model plugin.

Take a look at the script include "ChangeRequestStateModel_normal" to see the structure of the state models used by the Change Management application to control state flow. There are also script includes for Standard and Emergency changes.

You can see that there is a property in the script include for each state value. This property is an object with several of its own properties. The one you need for your question is the "next_state" array. Find the "authorize" property and change the next_state array from "scheduled" to "implement" in order to make that the next state. You will also want to update the workflow activity that sets the state to Scheduled and make it Implement (looks like you already did that).

However, I would caution that this will also populate the actual start date on the change request immediately after approval. You need to be sure this is what you want to do.

Hope that helps.

View solution in original post

26 REPLIES 26

Moy1
Kilo Guru

Could you provide screenshots please?

Different workflows are associated with different types of change request. Make sure that you have updated the correct workflow.

nyancer3
Tera Expert

Change request flows are now built on a set of script includes. The script includes come in pairs; one includes "SNC" in the name and is read-only. The other has the same name, but without "SNC" and is available for you to customize. That is the best-practice method for customizing change management for instances running the Change Management - State Model plugin.

Take a look at the script include "ChangeRequestStateModel_normal" to see the structure of the state models used by the Change Management application to control state flow. There are also script includes for Standard and Emergency changes.

You can see that there is a property in the script include for each state value. This property is an object with several of its own properties. The one you need for your question is the "next_state" array. Find the "authorize" property and change the next_state array from "scheduled" to "implement" in order to make that the next state. You will also want to update the workflow activity that sets the state to Scheduled and make it Implement (looks like you already did that).

However, I would caution that this will also populate the actual start date on the change request immediately after approval. You need to be sure this is what you want to do.

Hope that helps.

When you create a new change type and duplicate an existing script include, you only create one (of the pairs you mention above). 

I've noticed that my newly created "ChangeRequestStateModel_unauthorized" references an object that doesn't really exist. Will this cause me problems or do I replace with another SNC type script include, such as "ChangeRequestStateModelSNC_normal"?

Example:

Object.extendsObject(ChangeRequestStateModelsnc_unauthorized, {

I think you should be okay extending ChangeRequestStateModelSNC_normal, or emergency, whichever looks more like what your new type should do. The functions in the snc script include can be overridden in your script include (just give them the same name) and anything that you don't need to customize will just come from the parent object.

What is the use case for that change type? Seems very far out of line for best practice.