Allow the SCTASK to save with the variable blank. Prevents close if the variable is empty

[MIcheleWilliams]

My goal is 4 fold: 1) Allow the SCTASK to save when the "Client facing IP address" variable is blank, 2) Perform validation to prevents close if the variable is empty 3) Show an error message on the variable field and 4) Apply this validation only for specific SCTASKS.
Is the best way to accomplish only validating specific SCTASKS to create a custom field on sc_task in a sub-production instance, column lable = "Requires IP Validation", column name = "u_required_ip_validation".

The client script is as follows:
function onSubmit() {
var validationRequired = g_form.getValue('u_validation_required');
var state = g_form.getValue('state');
var ip = g_form.getValue('variables.client_facing_ip_address');
var closeStates = ['3', '4', 'closed_complete', 'closed_incomplete'];

if (validationRequired == 'true' && closeStates.indexOf(state) > -1) {
if (!ip || ip.trim() === '') {
g_form.showFieldMsg(
'variables.client_facing_ip_address',
'Client facing IP address is required before closing this task.',
'error'
);
return false;
}
}

return true;
}
Will this custom field disappear the next time production is cloned down to the sub-production instance?
How do I setup the new field to update the catalog task created in Flow Designer ?

[Suryansh Verma]

@MIcheleWilliams 

Keep the Client facing IP address variable non-mandatory at the catalog-item level so the fulfiller can save the SCTASK while it is blank. Make it mandatory only when a flagged Catalog Task is being moved to a closed state.

A task-level Boolean field is appropriate when only certain SCTASKs created for the same catalog item require this validation. Avoid identifying the task by short description or assignment group because those values can change.

Use:

Label: Requires IP validation
Name: u_required_ip_validation
Table: Catalog Task [sc_task]
Type: True/False
Default: false

Your script currently checks:

g_form.getValue('u_validation_required');

That does not match the proposed field name. It must use the exact internal name:

g_form.getValue('u_required_ip_validation');

1. Configure the Catalog Client Script

Create an onSubmit Catalog Client Script against the relevant catalog item.

Configure:

Setting Value

Type	onSubmit
Applies when item is requested	False
Applies on Requested Items	False
Applies on Catalog Tasks	True
UI Type	All
Catalog item	Target catalog item

Use:

function onSubmit() {
    var validationRequired =
        g_form.getValue('u_required_ip_validation') == 'true';

    var state = g_form.getValue('state');
    var closeStates = ['3', '4', '7'];

    var variableName =
        'variables.client_facing_ip_address';

    if (!validationRequired ||
        closeStates.indexOf(state) == -1) {

        g_form.setMandatory(variableName, false);
        g_form.hideFieldMsg(variableName, true);

        return true;
    }

    var ipAddress =
        (g_form.getValue(variableName) || '').trim();

    if (!ipAddress) {
        g_form.setMandatory(variableName, true);

        g_form.showFieldMsg(
            variableName,
            'Client facing IP address is required before closing this task.',
            'error'
        );

        g_form.addErrorMessage(
            'Client facing IP address is required before closing this task.'
        );

        return false;
    }

    g_form.setMandatory(variableName, false);
    g_form.hideFieldMsg(variableName, true);

    return true;
}

g_form.getValue() returns the internal field value, so the close-state array must contain actual choice values such as 3, 4, and 7, not labels such as closed_complete. setMandatory() then prevents submission while the field is empty.

2. Make the variable available on the Catalog Task

In the Flow Designer Create Catalog Task action:

1. Select the catalog item in Template Catalog Item.
2. Add Client facing IP address under Catalog Variables.
3. Under Fields, add: 

Requires IP validation = True

The Create Catalog Task action supports setting task field values through its Fields input and selecting which catalog variables appear on the task.

For tasks that do not require the check, leave the Boolean false.

Example:

Create Catalog Task: Network configuration
Requires IP validation = true

Create Catalog Task: Manager review
Requires IP validation = false

If the custom field does not immediately appear in the Fields picker, save the dictionary field, close and reopen the flow/action configuration.

3. Add server-side protection

Client-side validation improves the user experience, but it can be bypassed by imports, APIs, background scripts or other server-side updates. Add a Before Update Business Rule on sc_task.

Suggested configuration:

Table: Catalog Task [sc_task]
When: Before
Update: true
Condition:
Requires IP validation is true
AND State changes

Script:

(function executeRule(current, previous) {

    var closeStates = ['3', '4', '7'];
    var state = current.getValue('state');

    if (!current.getValue('u_required_ip_validation')) {
        return;
    }

    if (closeStates.indexOf(state) == -1) {
        return;
    }

    var ipAddress = '';

    var ritm = current.request_item.getRefRecord();

    if (ritm && ritm.isValidRecord()) {
        ipAddress =
            (ritm.variables.client_facing_ip_address || '')
                .toString()
                .trim();
    }

    if (ipAddress) {
        return;
    }

    gs.addErrorMessage(
        'Client facing IP address is required before closing this task.'
    );

    current.setAbortAction(true);

})(current, previous);

A Before Business Rule can cancel the database update using current.setAbortAction(true).

Will the custom field disappear after a production clone?

Yes, if the field exists only in the sub-production instance and has not been promoted to production, a production-to-sub-production clone can overwrite it.

Create the field and related scripts in an update set or application, then promote them to production. Once production contains the configuration, subsequent production clones will bring it back to lower environments. A clone restores the source database onto the target and then reapplies only configured exclusions and preservers.

Do not use a clone data preserver as the deployment mechanism for this customization.

If my response helped, please mark it as correct  and close the thread , this helps future readers find the solution faster!