An instance uses access control list (ACL) rules, also called access control rules, to control what data users can access and how they can access it. ACL rules require users to pass a set of requirements in order to gain access to particular data.
Users with the admin role can view Access Control records but cannot create, delete, or update Access Controls. All Access control operations except read require elevated security privileges. Elevated security privileges are also known as the security_admin role.
In the Elevate Roles dialog, select security_admin then click the OK button.
1. Records 2. Client callable Script Includes 3. Processors 4. REST Endpoints 5. UI Pages
- Requires Role
In order for permission to be granted to access a table/field, the Requires Role, Condition, and Script sections must all return true. If there is no value, the section returns true.
Use the Name field in the Access Control configuration to specify which records and which field are secured.
The example rule is a write rule:
Write: [incident] [Email Received Date]
Use the Requires role list to specify the role(s) required to access records. Click the Insert a new row… line to add a role to the list. If there are multiple rows in the list, the user only needs one of the roles for Requires role to return true.
Use the Condition field to create the condition(s) required to grant access. In the example, the Requested for value must be the currently logged in user.
Select the Advanced option to see the Script field.
Access Control scripts execute server-side. For best performance, avoid Access Control scripts that use GlideRecord queries as they can adversely impact performance.
Restrict the script logic only to security-related logic. If other logic is included, such as managing date formats or validating record data, it can be difficult to debug problems in the future as you might not think to look in Access Control scripts for those actions.
GlideSystem: getUser(), getUserID(), getUserName(), hasRole(), isLoggedIn(), isInteractive(), getSession() GlideRecord: isNewRecord()
Access Control scripts must set the answer variable to true or false.
Access Controls do not stand alone; they are part of list known as an Access Control List (ACL). An ACL is an ordered list of all Access Controls that apply in a particular circumstance.
Recall that the incident table extends the Task table.
Due to inheritance, the Task table Access Controls can potentially grant or deny access to Incident table records if no Access Controls specific to the Incident table exist. If no Access Control exists on the table, the parent table Access Controls are searched.
When deciding whether to grant or deny access, the ACL is searched from the most specific to the most generic match. For example, when determining whether to grant access to the Incident table Short description field, the search order is:
- Match the table and field name: x_58872_incident.short_description - Match the parent table and field name: task.short_description - Match any table with the field name: *.short_description - Match the table and any field (wildcard): x_58872_incident.* - Match the parent table and any field (wildcard): task.* - Match any table (wildcard) and any field (wildcard): *.*
When Access Controls are submitted or updated The Access Control Configuration Watcher runs to determine if there are other Access Controls acting on the same set of records. The Access Control Configuration Watcher displays a list known as the execution plan. The results are indicated by:
- Red text: An Access Control that was activated or deactivated.
- Blue text: An Access Control that was modified.
- Green text: An Access Control that is added or has become active.
- Masked: An Access Control that was effective until you made a change.
- Unmasked: An Access Control that was made effective when you made a change.
The Access Control Configuration Watcher also indicates whether the Access Control affects table rows or fields. Select the Show All link to see the complete ACL and not just the Access Controls impacted by the change.
*To or Not to *
The Name field in an Access Control specifies the table records to protect and a field to protect. The field list has a –None– option and a * option.
- –None–: Grant access to records and all fields in the records.
- *: Grant access to all fields where there is no field-specific Access Control.
At first glance, --None-- and * seem to grant the same thing: access to all fields on a record.To tell the difference in behavior, review how --None-- and * work together and with other Access Controls in a demonstration.
When creating * Access Controls, also create a None Access Control because only None grants access to records. When writing an ACL that mostly grants access, use only None. When writing an ACL that mostly denies access, use None and *.
The examples use an application called Generic that has a single table called Table. Table has five columns: Field 1, Field 2, Field 3, Field 4, and Field 5.
The application has two roles:
x_58872_generic.admin, assigned to Fred Luddy x_58872_generic.table_user, assigned to Beth Anglin
None – without
Examine the two read Access Controls. Pay attention to the field value and the roles. The screenshots have been edited to show only the pertinent parts of the Access Control.
Using this Access Control List (ACL), Fred can see:
Fred can see all rows all fields Using this ACL, Beth can see:
Beth cannot see Field 3
*How does this work?
The None Access Control granted all rows and all fields to both Fred and Beth. The Field 3 Access Control granted Field 3 access to Fred. Giving Field 3 explicitly to Fred removed Field 3 access from Beth even though she was granted Field 3 access by the None Access Control.
None – with
Examine the three read Access Controls. Pay attention to the field value and the roles. The screenshots have been edited to show only the pertinent parts of the Access Control.
Using this ACL, Fred can see:
Fred can see all fields and all rows
Using this ACL, Beth can see:
Beth can see only Field 3
How does this work?
The None Access Control granted all rows and all fields to both Fred and Beth. The * Access Control granted all rows and all fields to Fred. It seems redundant to have this Access Control because Fred already had access to all rows and all fields. The purpose of this Access Control is to deny access to all other roles, even roles granted permission by the None Access Control. The Field 3 Access Control explicitly gives Beth access to Field 3 even though Beth was denied access to Field 3 by the * Access Control. Field-specific Access Controls take precedence over * Access Controls.
- You cannot write * Access Controls without None because only None grants access to records.
- When writing an ACL that mostly grants access, use only None.
- When writing an ACL that mostly denies access, use None and *.
Goto sys_security_acl table and create a new record .The type will be ux_page.The most important part here is the “Name” field.
The Name field is hybrid field it can acts as reference field as well as plain text field. We are going to use as plain text field and provide the full path of the url of the ux page
Format to follow
Suppose our url is :
Then the transformed Name will be
Observe that here “/” gets replaced with “.”.
Note: ServiceNow will not validated if we give wrong url here. Our acl will not just work. So we have to carefully give the correct format.
1.By using UI page ACL, we can make UI page secure.
2.Only read operation ACL works on UI pages.
3.For getting endpoint available for UI page, we must define it in a custom scope.
4.Below are the UI Page link:
5.ACL Name convention for UI page is shown below
6.Below is the acl that we have created for ui page
- Understanding Request, RITM, Task in ServiceNow
- Steps to create a case in ServiceNow (CSM)
- Performance Analytics in 10 mins
- Event Management in 10 minutes - part1
- Event Management in 10 minutes - part2
- Custom Lookup List
- Script includes in 5 minutes
- Interactive Filter in 5 minutes
- UI Policy in 6 Minutes
- Client Side Script Versus Server Side Script in 3 minutes
- Performance Analytics
- ServiceNow Scripts
- Script include
- Useful scripts
- Basic Glide Scripts
- Client Script
- Advance Glide Script
- Glide System Script
- Import Set
- Work Flow
- Core Application
- UI Policy
- UI Action
- Client Script
- CAB Workbech
- Data Policy
- Connect Support
- Event Management
- SSO Integration
- LDAP Integration
- SCCM Integration
- AWS Intergration
- Slack Integration
- CTI Integration
- Jira Integration
- Ebonding ServiceNow
- SOAP Integration
- IBM Netcool Integration
- VIP Mobile App Integration
- Rest Integration
- Service Portal
- Performance analytics(PA) Interactive Filter
- Various Configurations in Performance analytics(PA)
- Service Portal
- Performance Analytics(PA) Widgets
- Performance Analytics(PA) Indicator
- Performance Analytics(PA) Buckets
- Performance Analytics(PA) Automated Breakdown
- Client Script
- Rest Integration
- Understanding the Request, RITM, Task
- Service Catalogs
- Events in ServiceNow
- Advance glide script in ServiceNow
- CAB Workbench