Missing Write ACL results in read-only form

ladrian1610 · 4 weeks ago

Hey there, a basic ACL thing:

I've created an application with 3 roles, with permissions as follows:
x.admin - crud.
x.team - create, read, write;
x.user - create, read;

Now, while testing I see that users belonging to a group with:
✅x.admin - can do all;
✅x.team - can create, read, write;
⚠️x.user - can read, BUT even though can click NEW, the form fields are greyed out. Moreover, I can Submit the form (even though short_description is mandatory) and the new record is created.

When I give the x.user role the Write ACL, it can create new records (the fields are not read only).

Best regards
Adrian

tiagomacul · 4 weeks ago

Hi @ladrian1610 ,

What you’re seeing is expected behavior when only part of the CRUD set of permissions is granted.

🔎 CRUD and ACLs in ServiceNow

Create → controls if a user can insert a new record into the table.
Read → controls if a user can view the record/fields.
Update (Write) → controls if a user can change values in fields (both on existing records and when filling in a new record).
Delete → controls if a user can remove a record.

In your case:

x.user has Create but not Write → that allows the record insert, but since Update/Write is missing, all fields on the form appear read-only.
When fields are read-only, the client-side mandatory check is skipped, which is why you can submit the form and still create a record without filling mandatory fields.

✅ How to fix / best practice

If a role is supposed to create records, it almost always needs Create + Write together.
If you don’t want them to have full edit rights, use field-level ACLs to allow write access only to the specific fields they should populate.
You can also layer in UI Policies or Client Scripts to control the form experience, but server-side ACLs should always be the authority.

🚀 Recommendation

Give x.user both Create and Write, then restrict which fields can actually be updated using field ACLs. This keeps the user experience consistent (fields editable when creating new records) while still enforcing proper security.

🛠️ Debug tip

You can also right-click on the form header and use “Show Security Info → Analyze Access” to debug ACL evaluation and see exactly why a user is being allowed or denied for Create, Read, Update, or Delete.

In some ACL, any one

2. Select your table

3. select user

4. Select Field

5. Evaluate access

View solution in original post

Sandeep Rajput · 4 weeks ago

@ladrian1610 This is expected behaviour with ACL. If the user has create and read role, they can read records and create records. However, they will not be able to edit records unless they have write permissions via ACLs.