The snc_read_only role

[Lucy10]

Hi,

I have got the snc_read_only role active for a few users but they're now facings issues with raising incidents via the record producer.

The incident table is not exempt from the role, but can I allow a few fields on the incident table exempt? so the record producer can create an incident?

Thanks,

Lucy

[Chuck Tomasi · Accepted solution]

Hi Lucy,

snc_read_only is read-only for every table (except a few system tables like event log, and history.) The whole idea behind it is to make the system read-only. There are no exceptions. It is hard coded in the platform.

[Chuck Tomasi]

If you need a similar role to allow incident creation and writable to a few fields, you can create your own role and grant ACLs accordingly.

Docs: Access control rules

Docs: Contextual security  

Security Best Practices - ServiceNow Wiki

[Lucy10]

Thanks for the info.

So If I create another role similar to snc_read_only and enforce the rule via glide.security an exempt the incident table   and then grant ACL's rules on fields on the incident table, that should work?

[Chuck Tomasi]

Hi Lucy,

You are essentially correct. The key to remember is that security (ACLs) defaults to deny. The role by itself doesn't do anything for you. So all records, all fields are not impacted. Anyone with no role has what they have based on existing ACLs. The new role doesn't make everything read-only, it just doesn't open up any new access. If the non-roled person had access to their own open incidents before, that's what they'll have with the new role - plus what ever you grant them with new ACLs that include the new role. Whereas snc_read_only, which locks down everything - no exceptions.

Example:

Today:

Non-roled user has write access to A, B, C (where A, B, C represent records and/or fields on those records)

ITIL user has write access to A, B, C, D, E, F

Admin has write access to A-Z

snc_read_only has write access to none.

If you create a new role (and no new ACLs), everything remains the same.

If you grant the new role to your non-roled user, everything remains the same.

If you create a write ACL on D for the new role, then your original non-roled user (now with the new role) has access to A, B, C, D.

There is no "everything read-only except D" unless you completely destroy the write access a non-roled user has - and you don't want to go there.