How to Make a Field Read-Only in a ServiceNow List View

Controlling field editability in ServiceNow list views is important for maintaining data integrity and security. ServiceNow’s list view allows inline editing (also called list editing) by default, meaning users can quickly modify records directly from a list without opening a form. While this can boost efficiency, it may lead to unauthorized or accidental changes if sensitive fields are freely editable. Ensuring certain fields are read-only in list view helps prevent mistakes and enforce business rules (for example, locking down a status field or a critical reference field).

To achieve read-only behavior in list view, ServiceNow provides several methods. The primary and most robust approach is using an Access Control List (ACL) rule with the special list_edit operation, which specifically governs whether a field can be edited from a list. ACLs are server-side and ensure security across the platform.

Other methods include client-side solutions like on-cell-edit client scripts and UI policies, as well as configuration options like List Controls or system properties:

• ACL (list_edit) – Field-level security that can restrict list editing by roles, conditions, etc. (This is our focus in this guide.)

  
  

• Client Scripts – Scripts running in the browser to disable or revert list edits (useful for additional UI feedback).

  
  

• UI Policies – Form rules to make fields read-only (note: they generally do not apply to list editing in the standard interface).

  
  

• List Control – A table configuration that can disable all list editing for that table (useful if you want no inline editing on a table at all).

  
  

• System Properties – A global property to enable/disable list editing system-wide (e.g. unchecking Enable list editing to turn off all inline edits).

  
  

In the sections below, we’ll walk through a step-by-step example of using an ACL to make a specific field read-only in list view. We’ll also highlight alternative solutions (client scripts, UI policies, etc.) and discuss common challenges, such as making a field read-only in one context but editable in another.

Implementing an ACL to Restrict List Editing (Step-by-Step)

The most effective way to make a field read-only in list view is to create a list_edit ACL on that field. An ACL will enforce security at the server level, meaning the restriction applies regardless of how the list is accessed (including different interfaces or APIs). Below is a step-by-step guide:

1. Elevate to security_admin role: Before editing or creating ACLs, you need to have the security_admin role and elevate your session to use it. To do this, click your profile in the top-right corner in ServiceNow, choose Elevate role, check security_admin, and submit. This temporary elevation allows you to modify security settings like ACLs.

   
   

2. Open the ACL configuration for the target field: Navigate to System Security > Access Control (ACL) and click New to create a new rule. (Alternatively, you can right-click the field label on a form and select Configure > Security Rules, which pre-fills the form for that field’s ACL.) This will open the Access Control form where you define the rule.

   
   

3. Define the ACL rule details: On the “New Access Control” form, fill out the following key fields:

   
   

   • Type: Select Record (since we are securing a record object/field).

     
     

   • Operation: Select list_edit. This special operation controls inline list editing. (By contrast, the write operation controls editability on forms or via API in general, but list_edit specifically targets the list view editor.)

     
     

   • Name (Table and Field): Specify the table and the field you want to restrict. For example, if making the State field on the Incident table read-only in lists, you would choose Table = “Incident” and Field = “State”. The ACL Name will then show as Incident.State. This means the rule applies only to that field on that table. (If you wanted to cover all fields on a table, you could use Incident.*, but here we are targeting one field.)

     
     

   • Active: Ensure this is checked (the ACL will be active once saved).

     
     

   • Admin overrides: Decide if administrators should be exempt from this restriction. If Admin overrides is checked (the default), any user with the admin role will automatically bypass this ACL. If you want even admins to be disallowed from list-editing this field, uncheck Admin overrides.

     
     

   • Requires role: If you want to allow only certain roles to edit the field in list view (and make it read-only for everyone else), specify those roles here. For example, to allow only admins to list-edit, add the admin role in the Requires role list. Users with admin role will then pass the ACL, while users without admin will be prevented from editing in the list. If you leave this blank, then no specific role is required by this ACL (you would then rely on a script or just the admin override setting to control access).

     
     

   • Advanced Script: If you need more complex logic than just roles or simple conditions, check the Advanced box to reveal the script field. In the script, you can write a condition that sets the variable answer to true or false to allow or deny list editing. For a basic “deny everyone” rule, you can simply use answer = false; (meaning no one is allowed to inline-edit that field). You might use a script if, for instance, you want to allow editing only under certain record conditions or for certain groups not easily defined by a single role. (If you use a script, remember that the script runs only if the user passes the role and condition requirements above. The ACL evaluates true (grants access) only if all three checks – roles, condition, and script – are satisfied.)

     
     

   An example ACL rule configuration for making a field read-only in list view. In this screenshot, we create a list_edit ACL on the Incident table’s State field (1 – Operation is list_edit, 2 – Table is Incident, 3 – Field is State). The rule is set to Active and Admin overrides is unchecked (to also restrict admins). A condition (4) is defined as “Category is Inquiry/Help”, meaning the State field will be read-only in list view only for incidents in the Inquiry/Help category. If no roles are listed and the script (not shown) returns false or is empty, this effectively denies list editing on that field for everyone who meets the condition.

   
   

4. Save the ACL: Click Submit to save the new ACL rule. The ACL is now in effect. (If you used the right-click method to create the ACL, saving it will also return you to the previous screen.)

   
   

5. Test the behavior: To verify the ACL is working:

   
   

   • Impersonate or log in as a user who should not have list edit permission on that field (for example, a non-admin ITIL user if you allowed only admins in the ACL). Go to the list view of the table (e.g., Incident list). Try to inline edit the field you secured. You should find that you cannot – the field will appear read-only. Typically, the pencil icon for editing won’t appear on hover, or if you double-click the cell, nothing happens. In newer versions or in Agent Workspace list view, you might see a lock icon or a message. For example, if a user without permission tries to edit, they may see a warning message like “Security prevents writing to this field”, and the change will not be saved.

     
     

   • Now test with a user who should have access (e.g., an admin, if you allowed admin). That user should be able to inline edit the field as usual. In our example, an admin user would still see the pencil icon and can change the State from the list.

     
     

If everything is configured correctly, the field is effectively read-only in list view for the unauthorized users. Under the hood, the list editor is checking the new ACL rule: users who fail the ACL will simply be prevented from making changes from the list. (They would still be able to open the record and edit the field on the form if they have normal write access – our ACL targeted only the list context, not form edit.) This approach lets you enforce that certain fields are only editable through the form or by privileged roles, not casually via list edits.

A Note on “list_edit” vs. Other ACLs

It’s worth noting how the list_edit ACL relates to the regular write ACL. If no list_edit ACL exists for a field, ServiceNow will default to the normal write ACL to determine if a user can inline edit. In other words, out-of-the-box, if a user has write access to a record, they can usually inline edit it from a list. By creating a list_edit ACL, you add an additional constraint specifically on the list editing operation. The user must pass both the write ACL (to save changes at all) and the list_edit ACL (to use inline edit). This means you can allow a role to edit a field on the form, but still block them from editing in the list. For example, you might want users to go through the form for certain changes (to trigger on-form client scripts or just to ensure they see important related info) rather than doing it inline.

When designing ACLs, also consider the Admin overrides setting carefully. If you check it, any admin user will bypass the rule entirely. In many cases this is fine (admins can do anything), but if the field is so sensitive that even admins shouldn’t edit via list, leave it unchecked as we did in our example. Additionally, you can combine multiple requirements: for instance, specify a role and a condition script. A common pattern is to allow list editing only if a certain condition on the record is true – you would set up the ACL with no roles (or certain roles) and use a Condition or script to allow/deny based on record data. The screenshot above (with the Category condition) is an example where list editing is only allowed for incidents of a certain category; other categories would be read-only in list for that field.

Alternative Solutions for Read-Only Fields in List View

While a list_edit ACL is the recommended way to enforce read-only behavior in list view (because it’s secure and applies universally), there are a few alternative or complementary methods worth mentioning:

• List Control Settings: If your goal is to disable all inline editing for a particular list or table, you can use the List Control configuration. Navigate to any list of the table (e.g., open the table’s list view), right-click the header (or gear icon) and choose System UI > List Control. In the List Control record, there is an option called List edit type – set this to Disable list editing and save. This will completely turn off the pencil icons and inline edit ability for that table (in that view). Use this if, for example, the table contains many critical fields and you prefer all edits to happen in forms. Keep in mind, List Control is not field-specific – it’s all or nothing for that table’s list. You can, however, have different List Control settings per view or module. For instance, you might disable list editing on a “All Incidents” module but allow it on a specialized view for a certain role, by configuring different list control entries for different views. This addresses scenarios where in one list context the field should be read-only but in another context (perhaps for a different audience or use case) inline editing is allowed.

  
  

• Client Scripts (On-Cell Edit): ServiceNow provides an onCellEdit client script type that can run when a cell is edited in a list. You could write a client script to intercept edits to a particular field and prevent them on the client side. For example, a script could check the field name and user role and then call return false to cancel the edit if the user isn’t allowed. A simple onCellEdit script might pop up an alert like “You do not have permission to edit this field” and abort the change. This can improve user experience by immediately notifying the user. However, client scripts alone are not secure, since a savvy user could bypass them – always pair such a script with a server-side control (like an ACL or a Business Rule) to truly enforce the rule. One advantage of an onCellEdit client script is granularity – you could allow edit in one list view and not in another by adding logic (for instance, check some UI context or user criteria) but this can get complex. Generally, if you find yourself needing a client script to manage list edits, make sure it’s for user feedback rather than the primary enforcement.

  
  

• UI Policies and Data Policies: UI Policies are great for making fields read-only on forms based on conditions, but they do not apply to list view edits in the standard interface (list v2). In classic UI16 lists, a UI policy won’t stop someone from inline editing because UI policies run on forms. (In Agent Workspace or list v3, there is some client-side enforcement, but relying on UI policy for list editing is not consistent across the platform.) Data Policies, on the other hand, are server-side and can enforce read-only or mandatory rules on insert/update operations globally. You could create a Data Policy to prevent changes to a field under certain conditions even if attempted via list edit. For example, a Data Policy could say “if State is Closed, make Resolution field read-only” and apply to all interfaces – this would cause an error if someone tried to change Resolution in the list for a Closed record. Data Policies can ensure data integrity but they will present an error after the fact; they don’t grey out the field in the UI. If you only need to enforce a rule on the data level (and are okay with an error message), a Data Policy is an option. In summary, UI Policies won’t directly help for list view, and Data Policies can block changes but won’t give a read-only appearance in the list UI.

  
  

• System Property (Global Switch): As mentioned, there is a system property Enable list editing (glide.ui.list_edit) which is true by default. If you set this to false (via System Properties > UI Properties), it will disable inline editing globally on the platform. This is a blunt instrument – it means no list for any table can be inline edited. Usually, you would not do this unless there is a broad requirement to turn off all inline edits (which is rare, since inline edit is useful). More commonly, you leave it enabled globally and control specific cases with ACLs or List Control as described above.

  
  

Each of these methods can be useful in certain scenarios. For example, you might use a List Control to disable editing on a highly sensitive table entirely, and use ACLs for finer control on other tables. Or use an onCellEdit script to give user feedback (“this field is read-only in list view”) while the ACL silently enforces it. The key is understanding that only server-side measures (ACLs, Data Policies, Business Rules) truly enforce security. Client-side measures (Client Scripts, UI Policies) should be considered usability enhancements or secondary checks, since they can be bypassed or may not run in all interfaces.

Handling Different List View Requirements: A common challenge is when a field should be read-only in one list context but editable in another. Since ACLs apply system-wide (per table/field), you can’t directly have two different ACL rules for two different list views of the same field. Instead, you need to differentiate by user role or some condition. For instance, if only a certain group of users uses List A and they should edit the field, but general users in List B should not, you could tie the permission to a role that only the first group has. Assign that role to the allowed users and include it in the ACL’s role requirements. The result: users in Group A (with the role) can edit in list, others cannot, effectively making it read-only for Group B. If the distinction truly isn’t by user, another approach is to create a separate interface for the editable scenario – e.g., a small custom UI or UI Action that allows editing that field under certain conditions, while keeping it read-only in the regular list. This might be more development effort. In many cases, differentiating by role is the cleanest solution for “read-only here, editable there.” You can also use the List Control “View name” to have one view of the list with editing disabled and another view enabled (though not field-specific). Ultimately, clarify the requirement: who exactly should be able to edit and when, and implement accordingly with roles/ACLs or separate modules.

Conclusion

Making a field read-only in a ServiceNow list view can be achieved reliably using a list_edit ACL, which adds a security layer specifically for inline editing. In this article, we introduced why controlling list editability matters and walked through creating an ACL step-by-step — from elevating to security_admin to configuring the ACL rule and testing it. The key takeaways and best practices include:

• Use ACLs for Security: An ACL with the list_edit operation is the recommended approach to restrict list view editing for a field. It ensures that no matter how a user tries to edit (UI, API, etc.), the rule is enforced at the server level. For example, we saw that adding a list_edit ACL on a field can make it read-only for all users except those with a specific role (like admin). Always document these ACLs so administrators understand why a field might be non-editable in list view.

  
  

• Follow Principle of Least Privilege: Grant edit rights only to roles that truly need it. If a field should rarely be changed, consider allowing only admins or a specific role via the ACL. If nobody should ever change it from a list, then deny everyone (script answer=false and no roles) so it’s read-only for all. This prevents accidental changes and safeguards data. Also, double-check the Admin overrides setting on the ACL; typically you leave it checked (admin can do anything), but uncheck it if even admins should be restrained for that list edit operation.

  
  

• Test in Non-Prod and Use Update Sets: ACL changes can have wide impact. Always test the new ACL in a sub-production instance with various roles (using impersonation) to ensure it behaves as expected. Capture the ACL in an Update Set for moving to production. If you face issues where the ACL isn’t working after migrating (for example, users still can edit when they shouldn’t), verify that the ACL exists and is active in the target instance and that no other ACL is conflicting. Remember that multiple ACLs on the same field could overlap – ServiceNow will evaluate all relevant ACLs, and the user must pass all of them to gain access. So if another ACL (like a general write ACL) grants access, but your list_edit ACL denies it, the deny will win (and vice versa) – the most restrictive effect applies if any ACL fails.

  
  

• Troubleshooting ACLs: If users see the message “Security prevents writing to this field” when attempting list edits, it’s a strong indicator that an ACL (or dictionary setting) is blocking the edit. This is expected if you set up a list_edit ACL. If you believe the user should be allowed, check that their roles meet the ACL requirements and that the record meets any ACL condition. Using the Security Diagnostics (right-click the field and choose “Security Rules” or enable ACL debug in System Security > Debug Security Rules) can help you see which rule is allowing or denying access. Also, ensure there isn’t a Data Policy or Business Rule interfering. In some cases, administrators forget to elevate to security_admin and thus the ACL wasn’t created or saved properly – always confirm the ACL is present in the ACL list.

  
  

• Maintaining Read-Only Behavior Consistently: Keep in mind that making a field read-only in list view doesn’t automatically make it read-only on forms. If you need it read-only everywhere, consider also a regular write ACL or a UI policy for forms. Conversely, you might allow form editing but not list editing, as we accomplished – this encourages users to go through the form for that field. Align these decisions with your governance policies. For example, if a field is critical, you might log changes to it (via an audit or business rule) and restrict quick edits.

  
  

In summary, ServiceNow provides flexible ways to control field editability. For list views, ACLs are a powerful tool to enforce who can edit which fields inline. Complement them with client-side scripts or UI messages for a better user experience as needed, and use table-level or global settings if you have broader requirements. By thoughtfully applying these controls, you can prevent unauthorized changes and ensure users make updates in the proper way. Effective management of field permissions not only protects data but also guides users to follow the correct processes in your ServiceNow environment.