(ServiceNow Administration Fundamentals On Demand) Lab 4.2 Incident table ACL

[o_jay]

Hi All,

I'm working on Lab 4.2 in the ServiceNow Administration Fundamentals On Demand training.  We've just restricted (and successfully tested) user visibility to the study Application & Modules, and are now trying to restrict visibility / access to Incident records (in the Incident table) based on the Service Offering field in the incident.

The intro states: "In this section, we will hide the Infinity (HDD) records at the table level.  Additionally, we will add read, write, and create access controls for the u_xx role", and I've followed the instructions (and re-read them to make sure) to apply the required Read, Write and Create ACRs, for the specified role (assigned to only Service Desk and Training Support groups) where "Service Offering is Infinity (HDD)".  However, when I impersonate a user who doesn't have this role (proved in the earlier part of the lab - they can't see the Application or Modules in the all menu, but as they have ITIL and sn_incident_read/write roles) they can still see a test record in the Incident table with the appropriate Service Offering, and create a new one.

Further, as I understand the documentation, access controls are assessed on an "OR" basis - so if there's an ACR granting access to Incident records for all users with ITIL role, my new ACRs trying to limit access to certain groups based on the Service Offering type isn't going to be applied?

Has the lab / have I missed a step (adding a condition to other read access controls to exclude the given Service Offering for example)?  As far as I can see, I haven't been asked in the lab documentation to do anything that would "hide the Infinity (HDD) records at the table level." ...

[Tony Chatfield1 · Accepted solution]

Hi, I have not taken this course so guessing, but based on 'we will hide the Infinity (HDD) records at the table level'

my expectation would be that any existing table level ACL would be disabled, that is the read rules named 'tableName' (no need to disable 'tableName.*' or  'tablename.fieldName').
As you post indicates correctly, if existing ACL's are not disabled or modified, then they will still provide access to users who meet their criteria regardless of any new ACL's

[o_jay]

Thanks Tony.

So yes - there is no instruction to amend existing access controls. 

I can see - for example - 5 other read access controls granting read access to approvers (based on a script), the user who raised the incident, itil or sn_incident_read roles, and ml (machine learning?) roles.  These were in place as part of the lab baseline instance.

All 5 would need to be amended (to exclude the in-scope records) for my new access control role to be effective, correct?