How Do I Restrict Related Lists In ServiceNow?

You can restrict related lists in ServiceNow using Access Control Lists (ACLs), List Control filters, or client-side scripts like UI Policies and Client Scripts.

The best approach depends on whether you want to restrict visibility for all users, filter the records shown, or dynamically hide/show the list based on specific conditions.

1. Restrict record visibility using Access Control Lists (ACLs)

ACLs are the most secure method for restricting related list data. This method hides the records within the list, but not the list itself. It is ideal for security requirements where certain data must be completely inaccessible to a subset of users.

How to implement:

1. Navigate to the related list's table. For example, if your related list shows task_sla records on an Incident form, the table is task_sla.
2. Go to System Security > Access Control (ACL).
3. Click New to create a new ACL.
4. Configure the ACL with the following settings:
   • Type:record
   • Operation:read
   • Name:[table_name].* (e.g., task_sla.*) to apply the ACL to all records in that table.
   • Condition: Add any conditions to restrict access (e.g., State is not Active).
   • Requires role: Add roles that are allowed to see the records. The list of records will only be visible to users with one of the specified roles.

2. Filter records using List Control

List Control allows you to set a default filter for a related list that applies to all users. This method is useful for applying a consistent business rule to the displayed records, such as only showing non-active records.

How to implement:

1. Navigate to a form that contains the related list you want to filter.
2. Right-click the header of the related list and select Configure > List Control.
3. If the Edit default filter field is not visible, personalize the form layout to add it.
4. In the Edit default filter field, specify your filter conditions (e.g., Active``is``true).
5. Save the changes.

Analysis:

• This method is easy to implement and sets a global filter for all users.
• The filter is not a security measure. Users can still see and remove the filter, which may reveal all records.

3. Dynamically hide/show the related list using UI Policy or Client Script

For conditional visibility based on the record's state, a user's role, or other form field values, you can use client-side logic. This approach hides or shows the entire related list tab, not just the records within it.

Option A: Use a UI Policy

UI Policies are generally preferred over Client Scripts for dynamic form logic, as they require no coding.

How to implement:

1. Navigate to the form's table (e.g., Incident).
2. Go to System UI > UI Policies.
3. Click New to create a new UI Policy.
4. Set the Condition for when the related list should be hidden or shown (e.g., State``is``New).
5. In the Script section, check the Run scripts box.
6. In the Execute if true script, add g_form.hideRelatedList('related_list_table_name').
7. In the Execute if false script, add g_form.showRelatedList('related_list_table_name').
8. To find the related_list_table_name, right-click the related list header, select Configure > List Control, and copy the value from the Related list field.

Option B: Use a Client Script

For more complex logic or when you need to check a user's role, a Client Script is a powerful alternative.

How to implement:

1. Navigate to the form's table (e.g., Incident).
2. Go to System UI > Client Scripts.
3. Click New to create a new Client Script.
4. Select Type as onLoad to run when the form loads, or onChange to run when a specific field value changes.
5. In the Script field, use conditional logic and g_form.hideRelatedList() or g_form.showRelatedList().

Example using onLoad to hide based on role:

function onLoad() {
  // If the user does not have the 'itil' role, hide the related list
  if (!g_user.hasRole('itil')) {
    g_form.hideRelatedList('related_list_table_name');
  }
}

Use code with caution.

Analysis of client-side methods:

• UI Policies are non-technical and preferred for simple, predictable conditions.
• Client Scripts offer greater flexibility for complex logic, such as checking multiple user roles or other form-field values.
• Both methods control the visibility of the related list tab itself. They do not prevent a user from accessing the underlying data if they know the correct URL. For true security, always use ACLs in addition to client-side visibility controls.

Summary of restriction methods