top of page

Experiencing challenges with ServiceNow support?

Access professional, reliable assistance tailored to your needs—without breaking your budget.

Dynamically Making ServiceNow Variables Read-Only on Your Requested Items

Updated: Mar 26


In the world of ServiceNow, controlling how users interact with data is crucial for maintaining data integrity and streamlining workflows. A common requirement is to make certain fields or variables read-only under specific conditions. This is particularly relevant for Requested Items (RITMs) generated from service catalog requests, where you might want to restrict modifications based on the item requested or the team responsible for it. This article explores how you can dynamically set variables to read-only on your ServiceNow RITMs, ensuring the right information is editable at the right time.


The Scenario: Controlling Variable Editability on RITMs

Imagine a scenario where you have a service catalog item, for example, "Employee Requirements". Once this item is requested and an RITM is generated, you need to make all the associated variables read-only, but only if the assignment group handling the request is not "NAR CIB Onboarding". This kind of conditional read-only requirement ensures that the variables, which capture the initial needs of the employee, are not inadvertently changed by the wrong team.

ServiceNow offers a couple of effective ways to achieve this dynamic behavior. Let's delve into the recommended approach and an alternative method.


Recommended Solution: Leveraging Catalog UI Policies

The most robust and generally preferred method for controlling the read-only state of variables on RITMs is by using Catalog UI Policies. UI Policies provide a declarative way to define client-side behavior without writing code, making them easier to manage and less prone to issues during upgrades. Here's how you can implement this:

  1. Navigate to Catalog UI Policies: In your ServiceNow instance, use the Application Navigator (the filter navigator on the left) to search for "Catalog UI Policies" and open the module under "Service Catalog".

  2. Create a New UI Policy: Click the "New" button to create a new Catalog UI Policy.

  3. Specify Applies To:

    • Applies to: A Catalog Item

    • Catalog item: Employee Requirements

    • Short description: Set Variables Read-Only on RITM when Assignment group is not NAR CIB Onboarding

  4. Define the Condition: This is where you specify when the variables should become read-only. In the "When to Apply" section:

    • Ensure the "Applies on Requested Items" checkbox is selected. This ensures the policy will apply to RITMs.

    • You can leave "Applies on Catalog Tasks" unchecked unless your requirements extend to catalog tasks as well.

    • Add a condition based on the assignment group. You'll likely need to reference the "Assignment group" field on the RITM record (which might be accessible through a related list or a field on the RITM form). The condition should be 'Assignment group is not NAR CIB Onboarding'. If the group selection in UI Policies requires an exact match, you may need to use the sys_id of the 'NAR CIB Onboarding' group.

  5. Configure UI Policy Actions: In the "UI Policy Actions" section, you will define what happens when the condition is met.

    • Click "New" to add a new action.

    • In the 'Variable name' field, select the variables that need to be set as read-only individually. If multiple variables need to be controlled, you may need to create separate UI Policy Actions for each variable.

    • Set the "Read-only" field to "True".

  6. Save the UI Policy: Click "Save" to activate your new Catalog UI Policy.


Now, whenever an "Employee Requirements" item is requested and the resulting RITM is assigned to an assignment group other than "NAR CIB Onboarding", all the variables on that RITM will automatically become read-only.


Alternative Solution: Utilizing Client Scripts (with Caution)

While UI Policies are generally recommended, you can also achieve this using a Client Script. However, it's important to note that client scripts involve writing code and might be slightly more complex to maintain.

Here's how you could do it with an onLoad client script on the Requested Item table (sc_req_item):

  1. Navigate to Client Scripts: In the Application Navigator, search for "Client Scripts" and open the module under "System Client Scripts".

  2. Create a New Client Script: Click "New".

  3. Configure the Client Script:

    • Name: Give your script a descriptive name, like "Set Variables Read-Only on RITM".

    • Table: Select "Requested Item [sc_req_item]".

    • UI Type: Choose "All" to ensure it works in both the standard UI and Service Portal.

    • Type: Select "onLoad". This will make the script run when the RITM form loads.

    • Script: In the "Script" field, enter the following code, replacing the placeholder sys_ids with the actual sys_ids of your "Employee Requirements" catalog item and "NAR CIB Onboarding" assignment group:

function onLoad() { 
    var catalogItemSysId = 'YOUR_EMPLOYEE_REQUIREMENTS_SYS_ID'; 
    var assignmentGroupSysId = 'YOUR_NAR_CIB_ONBOARDING_SYS_ID';
    
    if (g_form.getValue('cat_item') == catalogItemSysId && 
g_form.getValue('assignment_group') != assignmentGroupSysId) { 
	   // Get all editable variables
        var variables = g_form.getEditableVariables(); 
        for (var i = 0; i < variables.length; i++) {
            g_form.setReadOnly(variables[i].name, true);
        }
    }
}
  1. Save the Client Script: Click "Save".


Important Considerations for Client Scripts:

  • Best Practice: While g_form.setVariablesReadOnly(true) is sometimes used to make all variables read-only at once, it's undocumented and may not behave consistently across all environments. This script takes a safer approach by retrieving all editable variables and applying g_form.setReadOnly() to each one individually.

  • Service Portal Compatibility: Ensure your script works correctly in the Service Portal if your users access RITMs through it. Some APIs, including g_form.getEditableVariables(), may behave differently in the portal compared to the standard UI. If issues arise, consider explicitly defining variable names and setting them as read-only with g_form.setReadOnly().

  • Service Portal: Ensure your script is compatible with the Service Portal if your users access ServiceNow through it. The provided script with "UI Type: All" should generally work.

  • Maintainability: UI Policies are often easier to understand and maintain over time compared to code-based solutions.


Conclusion: Choosing the Right Approach for Read-Only Variables

Both Catalog UI Policies and Client Scripts can be used to dynamically set variables as read-only on your ServiceNow RITMs. However, for this specific scenario and for general best practices, using Catalog UI Policies is the recommended approach due to its declarative nature, ease of maintenance, and robustness across different ServiceNow interfaces. By implementing a Catalog UI Policy, you can effectively control the editability of your variables based on the catalog item and assignment group, ensuring a more controlled and efficient workflow within your ServiceNow environment. Remember to always test your configurations thoroughly in a non-production environment before deploying them to your live instance.

Experiencing challenges with ServiceNow support?

Access professional, reliable assistance tailored to your needs—without breaking your budget.

CONTACT

New Zealand HQ

Integrated Knowledge Consulting Office

Level 3, 93 Grafton Road

Auckland

South Korea

Integrated Knowledge Consulting Office

BMY역삼타워 6층

서울특별시 강남구 역삼동 678-10번지

 

info@ikconsulting.com

Thanks for submitting!

  • LinkedIn Social Icon

© Copyright 2025 Integrated Knowledge Consulting. All rights reserved.

bottom of page