'Successful' close code is not appearing on Change form

[Rachael12]

Hello,

Whenever any of the change tasks are 'Closed Incomplete', 'successful' close code disappears from its Change.

Its an OOB functionality. As per requirement, it should be requester's choice to close the change with relevant close code. 
I have searched BR, script includes and client scripts but had no luck.

Can some please point form where the close code 'Successful' disappears.

Thanks in advance 

[kaushal_snow]

Hi @Dr Atul G- LNG ,

I need to look into the documentation, but what I mentioned was told to me while I was working as a change implementer by one of my team’s ITSM architect.

[Dr Atul G- LNG]

Thanks for the update @kaushal_snow 

But what you mentioned is not correct—it might just be a customization in your instance.

[kaushal_snow]

Hi @Dr Atul G- LNG ,  that might be the case, thanks for highlighting it...

[Dr Atul G- LNG]

Hi @Rachael12 

First, OOTB there is no Closed Incomplete state in a Change Task. It looks like this is a custom state in your instance. For the same, there might be some Business Rule or script written that is causing the Close Code in Change to disappear.

[MackI]

HI @Rachael12 

Based on your previous query and the provided sources, the disappearance of the 'Successful' close code from a Change Request when any of its Change Tasks are 'Closed Incomplete' is part of ServiceNow's Out-of-the-Box (OOB) Change Management state model logic. To implement your requirement that the close code should be the requester's choice, you would need to customise this OOB state model behavior.

Here's the solution based on the principles of modifying ServiceNow's state models, as demonstrated in the sources:

The primary place where the logic for setting the Change Request's close code during state transitions resides is likely within the ChangeRequestStateModel_normal script include or a similar state model script if your instance uses a different baseline for Change Management.

The ServiceNow Product Documentation illustrate how states and their transitions for a Change Request are defined and can be manipulated:

Understanding State Model Logic:

A ChangeRequestStateHandler class (used by GlideAjax for state transitions) defines state values and names, such as COMPLETE having a numeric value like '-6'.
The ChangeRequestStateModel_normal script include contains state objects (e.g., complete, closed, canceled) which define their nextState options and associated functions like moving() and canMove(). These functions dictate whether a change can transition to a particular state and what actions occur during that transition.
For instance, the closed state's canMove function in the example checks a custom field u_needs_review. This highlights that custom logic can be embedded into these state transitions.
Identifying Where 'Successful' Disappears:

The OOB logic, as discussed, likely has a canMove() or moving() function associated with the closed state of the Change Request that evaluates the status of its child Change Tasks.
When it detects a 'Closed Incomplete' Change Task, it prevents the close_code from being 'successful' and instead sets it to a value like 'successful_issues'. While the exact script snippet for this specific scenario isn't in the provided sources, the examples of state definitions (e.g., for CLOSED_COMPLETE and CLOSED_INCOMPLETE in the previous conversation) indicate this mapping is handled by the state model.
Proposed Solution - Customizing the State Model: To allow the requester's choice for the close code, you would need to:

Modify the ChangeRequestStateModel_normal Script Include: You would need to locate the logic that governs the transition to the closed state for the Change Request and specifically where the close_code is determined based on Change Task outcomes.

Implement Custom Logic: Within the moving() or canMove() functions for the closed state (or a state that precedes final closure and sets the close code), you would introduce a condition to check for the requester's preference. This could involve checking a new custom field on the Change Request.
Example (Conceptual based on provided patterns):closed : {
moving : function() {
// Existing OOB logic for setting close_code based on tasks
// ...
// Your custom logic to allow requester's choice
if (this._gr.getValue("u_requester_close_choice_override") == "Yes" && this._gr.getValue("u_requester_close_code") == "successful") {
this._gr.setValue("close_code", "successful");
} else {
// Revert to OOB logic or set based on other conditions
return this.toClosed_moving();
}
},
canMove : function() {
// Potentially add conditions here as well to enable the choice
if (this._gr.getValue("u_needs_review") == "No")
return true;
return false;
}
}

Note: Directly modifying OOB script includes is generally discouraged. Best practice would be to extend the OOB functionality through custom script includes that override specific methods, or by using a sys_properties or a similar configuration if the OOB script is designed for extension. However, the provided sources show direct modification as an example.

Create a Custom Field on the Change Request Form:

You would introduce a new field, for example, u_requester_close_code (a choice list field with options like 'Successful', 'Successful with Issues', 'Unsuccessful', etc.) and potentially a checkbox u_requester_close_choice_override. These fields would capture the requester's desired close code.
Implement UI Policies/Client Scripts:

To make this user-friendly, you would need UI Policies or Client Scripts to display the u_requester_close_code field and u_requester_close_choice_override checkbox only when the Change Request is in a state where closure is imminent, and specifically when there are 'Closed Incomplete' tasks that would otherwise trigger the OOB "successful_issues" code. This allows the requester (or someone acting on their behalf) to input their preference.

Modify UI Action (if applicable):

If the closure is initiated via a UI Action (e.g., 'Close'), you might need to modify the onClick script of that UI Action to pass the value of your new custom field to the state handler, similar to how the moveToComplete() function is used in the example.
By customizing the underlying state model script and introducing user-facing fields with associated UI logic, you can achieve the flexibility of allowing the requester to choose the close code, even when OOB logic would normally override it due to 'Closed Incomplete' tasks.

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌ OR  mark it  Helpful ‌⛑‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community.