Upgrade - Not authorized to update this record

[JohnnySnow]

Hi Team,

After upgrading to Washington when working on the skipped logs, I have found few security acls which when we open says 'Not authorized to update this record' as shown below.

I can see that the changes in the customized column is not something we have customized. Hence my understanding is to revert to base system which I'm able to do from the previous window(2nd screenshot).

My query is if I should 'Revert to base system' or since it is not authorized to update , should I set it to 'Reviewed'?

Any thoughts?

[Community Alums]

Hi @JohnnySnow ,

What i read from your screenshot, you have script condition, you want to check with your dev team as in why that change has been made, if you don't need it then "revert to base" else, mark it as `Reviewed".

[Mark Roethof · Accepted solution]

Hi there,

Might this just be an access issue like Elevate role to security_admin?

I can't reproduce at this moment since I don't have any pending Skipped records open, though since it is about sys_security_acl, I'm thinking it's in the area of Elevate role.

[JohnnySnow]

Thanks @Mark Roethof , I somehow forgot to elevate roles and hence the 'Not authorized to update message'.

Also in terms of the action taken on those would be 'Reviewed  & Reverted'.

[PLOUFFEM]

Hi Mark,  

I have the same issues and therefore the same question.

Now, Iike you, I'm not satisfied with the few answers provided below.  When dealing with a conflict to resolve like the above, the first reflex is to go to the table in question (sys_security_acl) on the conflicting record (name:  sys_cs_context_profile_promoted_skill) and look at the number of versions your instance has for this record and which one is the 'current' one.... In my case, as you can see below, the customized side of the conflict is the 2024-01-24 version of the record, source from the 'Update Set: Default'.   All the subsequent versions of the record are conflicting and were not retained therefore were never made 'current'.   My thinking is, has mentioned is a few replies.

 My thinking was, has mentioned is a few replies,  to elevate myself to 'security_admin' which allow to modify ACLs and allowed me to resolve the conflict and merge the changes which were in  'description' and 'a scripted condition'.

Note:  I understand that some of you have suggested to simply set the Skipped Record Resolution to 'Reviewed', but you have to provide a rational for with this decision, otherwise you might be putting dust under the carpet.

[JohnnySnow]

Hey,

If you've elevated the role to the Security Admin role and no longer receiving the info message, you'll need to 'revert to base system' for this record.

The changes are from ServiceNow's side, and the record in default update set doesn't appear to be customized.

These changes were implemented by ServiceNow in previous versions. To confirm, compare the Default with any previous versions (state = History) to check if any changes were made, or if you reverted to the base system/merged in a previous version, resulting in it being in the default update set.