What is the correct way to POST to Change API with Change Models

[motto]

All

I am having difficulty creating a new change using change models through a POST call.

ServiceNow documentation says the following regarding query parameters: (https://docs.servicenow.com/bundle/rome-application-development/page/integrate/inbound-rest/concept/change-management-api.html#change-POST-change):

"Note: To create a change request for a desired model or type, rather than the default of "Normal", you must pass in either the model or type parameter. For example, chg_model=Normal or type=Normal."

When I POST using chg_model as the parameter and define any value, INCLUDING the sys_id of the model type, the change registers as follows (likely because it does not recognize the value):
Does anyone have the EXACT query parameter needed to post to this model? A sample URI string with all the query parameters in tact would be awesome - example (except not broken)

https://<instancename>.service-now.com/api/sn_chg_rest/change?chg_model=Change%20Registration

Thank you all

[Tony Chatfield1]

Hi, the URL format should be
https://instanceName.service-now.com/api/sn_chg_rest/change/standard/templateSysID

I found testing the REST API explorer worked fine,
but in Postman while I could set change type with a parameter key 'type' and a value of 'yourrequiredtype'
to set a standard change template I needed to drop the type parameter and hard code the type and sys_id directly into the URL.

[motto]

Thanks for the reply Tony

This query string works well for ITIL mode 1 change models tied to standard, normal and emergency changes, where the API is established based on those models. As you are aware, these models have been built out into the API. (https://developer.servicenow.com/dev.do#!/reference/api/rome/rest/change-management-api#changemgmt-POST-std-create-chng-req)

Change models as introduced in Quebec do not have to work the same way. Mode 2 ITIL change allows for the creation of custom models with custom state models and custom state transitions. The problem here is calling to one of the OOB "new" change models OR a new change model with unique states. (see https://docs.servicenow.com/bundle/quebec-it-service-management/page/product/change-management/concept/change-models.html)

If I create a new change manually based on the new(ish) Change Registration model, the change appears as a NORMAL change type, with the model set as "Change Registration." This model is designed for devops and other teams who work through a CI/CD pipeline for validations and approvals. The model is used to register the change without all the ITIL normal overhead. Clearly doing this manually only defeats the point the request type.

What was previously straight forward based on fixed ITIL mode 1 change models is no longer straight forward. Trial and error on forming the query string is simply wasting time.

[Tony Chatfield1]

Hi, testing quickly in Rome PDI via PostMan
I find that using parameter chg_model, sys_idOfTheModel
works for the standard OOB change types  - emergency, normal, standard
but not for the other OOB models - Change Registration, Cloud Infrastructure, Unauthorized Change, as the insert is prevented by BR Change Model: Check State Transition

   "error": {
        "detail": "",
        "message": "Could not create Change Request. Operation against file 'change_request' was aborted by Business Rule 'Change Model: Check State Transition^04a4bc761b6d4910b2210fabdc4bcbb7'. Business Rule Stack:Change Model: Check State Transition"
    },

With this BR inactive a Change Request is created for these 'new' models using the same parameter format; But I was unable to reproduce the issue shown in your screenshot with a 'NativeArray' string shown instead of a type value.

So I believe that in Rome (at least) the POST functionality is working as expected,
but it appears that 'State' transition functionality has an impact - exactly what and why I haven't figured out yet.

[motto]

Thanks Tony - that's helpful, and a reason to migrate production to Rome if needed.

Q: Do you know what the implications are of disabling that BR? I have to look later - that said, it seems to be demanding the declaration of a state. If you submit the query parameter of state as review, does it work with the BR in tact?

Thank you again.