We've updated the ServiceNow Community Code of Conduct, adding guidelines around AI usage, professionalism, and content violations. Read more

Problem Task Close Code defaulting to "Completed" due to OOB ProblemModalUIHelpers

dattanarend
Tera Expert

Hi Everyone,

We recently introduced a new Problem Task type (e.g., action item). As part of the requirement, the client asked us to have a different set of Close Code choices when this task type is moved to the Closed state.

Instead of creating a new field, we decided to reuse the OOB close_code field on the Problem Task (problem_task) table and added the required additional choice values to it.

However, when a Problem Task is closed using the Complete UI Action, the popup dialog automatically populates the Close Code as "Completed".

After investigating, we found that this behavior comes from the OOB UI Script ProblemModalUIHelpers, where the following line appears to be hardcoded:

g_form.setValue("close_code", "completed");

Because of this, whenever a Problem Task is moved to Closed, the Close Code in the popup always defaults to "Completed", regardless of the task type.

Requirement:

For the newly created Problem Task type:

  • The Close Code should default to --None-- instead of Completed

  • Users should select one of the newly added Close Code choices

  • The field should also be mandatory before closing the task

We tried approaches like:

  • Client Scripts (onLoad / onChange)

  • UI Policies

  • Dictionary configuration

But since the value is being set inside the modal helper UI Script, it overrides the client-side logic.

Question:

What would be the recommended best practice to achieve this requirement without modifying the OOB ProblemModalUIHelpers UI Script?

Any suggestions or guidance would be greatly appreciated.

Thanks in advance!

2 REPLIES 2

Dr Atul G- LNG
Tera Patron

Hi @dattanarend 

 

Technically, you only need to update the UI Script on the instance where the configuration has been defined.”

*************************************************************************************************************
Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/dratulgrover [ Connect for 1-1 Session]

****************************************************************************************************************

HaimNizri
Tera Contributor

This is a tricky one because that UI Script is indeed setting the value directly in the modal, which makes it hard to override cleanly.

The most elegant solution I've found is to extend the ProblemModalUIHelpers rather than modify it. You can create a new UI Script that runs after the OOB one and conditionally overrides the behavior based on your task type.

Create a new UI Script (let's call it "CustomProblemModalUIHelpers") and set it to load after the OOB one by giving it a higher order value. Something like this:

```javascript
// Check if this is your custom task type
var taskType = g_form.getValue('type'); // or whatever field you're using to identify the type
if (taskType == 'your_custom_type_value') {
// Override the close_code value set by OOB script
g_form.setValue('close_code', '');

// Make it mandatory
g_form.setMandatory('close_code', true);

// Optional: Add some visual feedback
g_form.showFieldMsg('close_code', 'Please select an appropriate close code', 'info');
}
```

The key here is the execution order - your script needs to run after the OOB ProblemModalUIHelpers sets the "completed" value, so it can immediately clear it for your custom task types.

You'll also want to add a Client Script on the problem_task table (onLoad event) to handle the mandatory validation:

```javascript
function onLoad() {
var taskType = g_form.getValue('type');
if (taskType == 'your_custom_type_value' && g_form.getValue('state') == 'closed') {
g_form.setMandatory('close_code', true);
}
}
```

One heads up though - this approach assumes the modal is using the same form context. If ServiceNow changes how that modal works in future releases, you might need to revisit this.

Have you considered creating a custom UI Action instead of using the OOB Complete action? That would give you full control over the modal behavior without having to work around the existing script.