Missing Write ACL results in read-only form

[ladrian1610]

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 · Accepted solution]

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

[ladrian1610]

Hello, thank you for your answer! When I give the Update (Write) permission to the x.user then they are able to Update (Write) all the records in the table, including those that were created by other users.

[ladrian1610]

Write permission allows the regular users to edit all the records in the table which I don't want. Do I need to use script 

answer = (current.sys_created_by ==  gs.getUserID()); ?

[kaushal_snow]

hI @ladrian1610 ,

You are missing Create ACL rather than a missing Write ACL........

Key points for ACL:

Write ACL determines if a user can edit existing records.

Create ACL controls whether a user can populate fields when creating a new record...

In your case, the x.user role has a Write ACL but lacks a Create ACL. This lets them open the form and even submit but the form is read only and fields remain empty or mandatory validation can be bypassed because the form isn't truly active or editable.....

Note: You need to add a Create ACL for your custom table...

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.