"Read Only" fields can't be update via REST API?

[carlh]

Hello,

We have a nightly process that updates our CORE_COMPANY table with the latest data on our Accounting system tables.

Because we get this data from an external source, I want the fields we're updating to be read only to anyone (including Admin role).   But, there are also fields that are on CORE_COMPANY table that are not on the source tables and I need people to be able to write to/edit those fields.

Do I need a client script or is there a way to set the ACL for each field?

Advice is appreciated.

Thank you

Carl

[carlh]

Sorry if I have made this confusing.

The desired behavior is to only give "write" access to the Admin and Service Account for SOME Fields.

All of the Gray fields are set to read only in the dictionary.   I had to change the phone and extension fields to NOT be read only in order for the Service Account to have access to update the record.   I now assume these other read only fields aren't being updated either but we just figured it out today since we have been working on the phone / extension fields (in source they come over as 14 digits and we parse out the last 4 before putting in ServiceNow)

As mrswann mentioned, you can set access by field.   I assume that because I need some but not all that I will need to set it by field.   Am I making sense or totally lost?

[Chuck Tomasi]

You are correct. You can set these by record or by field.

Use the ACL debugger to determine what rules are in effect and why fields are read-only or editable.

Debugging Tools Best Practices - ServiceNow Wiki

[carlh]

I'm back to this one.  

I think I have too much going on in the ACL already so my thought is to get it back to whatever out of the box setting is and then give only admin access to the whole table which would include my service accounts.

Then I could go to the fields I want to give access to as it would be less work... I think?

Any thoughts on this plan?   I would need help knowing what the Out of box settings were (these were changed by our vendor and at the time I didn't know what they were.)

On the fields I want to open up to this custom role, is it as simple as adding that role to the "write" ACL on each field?

(the role is a custom restricted_vendor_manager role which basically excludes ITIL role...not sure about that decision either as I think I have this mess because we should have just made the Application Menus available to groups.)

A client script, while not the most secure, may do the trick for now while we straighten things out.   The only concern I have right now is that a user would be able to change a field thinking it would stay there and I have a nightly process that updates from the source data and would overwrite their changes.  

In the future, as we get further and make ServiceNow the authoritative source for Vendor Management, we will have to go with ACL's so I am not sure what the best thing to do it.

[Chuck Tomasi]

Hi Carl,

An easy way to see what OOB is, is to go to https://developer.servicenow.com and request a personal developer instance. That will give you a fresh instance either Fuji, Geneva, or Helsinki (your choice.)

As for the ACL, yes, if you apply write access to table.*, you grant write access to all fields within that table. Remember that they may also require table.none to get write access to the record. One does not imply the other. table.fieldname is for individual fields (handy when you want to grant access of individual fields, but not all.)

Using Access Control Rules - ServiceNow Wiki

Security Best Practices - ServiceNow Wiki

Contextual Security - ServiceNow Wiki