Need a related tab be edited in with the acl in Servicenow

[Feroz1]

Hi Team,

on the incident form I have a tab called xyz that should he edited only when state is resolved only. In the instance I could find a acl write acl incident.* and state is not one of closed or resolved condition that is restricting to it so I have written another write acl on incident.particular field so after that also it is not reaching my requirement can any one help me?

[GlideFather]

Hi @Feroz1,

please share that ACL that you created

[Feroz1]

Incident. In the related tab is click one filed only populated based on clicking the option in that I have given the backend of field “business cuz’ condition state is resolved role utility.

[GlideFather]

Please share that ACL record that you created if possible, to review it @Feroz1 

[Naveen20]

The existing wildcard ACL incident.* (write) with the condition "state is not one of closed or resolved" is evaluated for every field on the incident form. When the state is anything other than Resolved or Closed, this ACL grants write access. When the state is Resolved or Closed, this ACL denies write access to all fields — including your "xyz" tab fields.

The key thing to understand is how ServiceNow evaluates ACLs: when you create a more specific field-level ACL like incident.your_field (write), both the wildcard incident.* and the field-level incident.your_field ACL are evaluated, and all matching ACLs must return true for access to be granted. It's an AND logic, not an override.

So even though your field-level ACL might say "allow when state is Resolved," the wildcard incident.* ACL is still saying "deny when state is Resolved" — and since both must pass, access is denied.

How to fix this:

You have a couple of options:

1. Modify the wildcard ACL condition — Update the incident.* write ACL's condition or script to exclude your specific fields from its restriction. In the script, you can add something like:

   // In the incident.* write ACL script
   var excludeFields = ['your_field_1', 'your_field_2'];
   if (excludeFields.indexOf(current.getTableName() + '.' + current.getED().getName()) >= 0) {
       answer = true;
   } else {
       answer = current.state != 6 && current.state != 7;
       // 6 = Resolved, 7 = Closed (check your instance values)
   }
   

2. Use a UI Policy instead — Rather than fighting ACL logic, create a UI Policy on the Incident table that makes the xyz tab fields read-only when the state is not Resolved, and editable when it is Resolved. UI Policies control form-level behavior and are often simpler for this kind of requirement. Just remember that UI Policies are client-side only, so if you need server-side enforcement too, you'd still need the ACL approach.

3. Use gs.hasRole() or a condition in the wildcard ACL script — If you can't modify the OOTB ACL directly (best practice is to avoid modifying OOTB ACLs), create a before business rule that sets the fields to read-only using current.your_field.setReadOnly(true) based on state, and adjust your ACL strategy accordingly.

Recommended approach:

The cleanest solution is usually a combination: keep the existing incident.* ACL as-is, and use a UI Policy to handle the editability of your xyz tab fields based on state. If you need server-side protection as well, add a before business rule that aborts changes to those fields when the state isn't Resolved.