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