How do you stop the wrong people from seeing or changing the wrong data in ServiceNow? That's the problem security and access controls solve. If you are studying for the SNOW-CAD exam, you must understand that every single record, field, and action in the platform has a set of invisible rules deciding who can do what, and those rules are the difference between a secure instance and a compliance disaster.
Jump to a section
A simple way to picture Security and Access Controls
Before you can walk into your apartment building at night, your security card fob must be scanned. That scan checks two things: do you have a valid fob at all, and does that fob grant you access to this specific door at this specific time? If the database says you're a resident of apartment 4B, you get through the front door. But that same fob won't open the maintenance room or the rooftop garden, because those areas require different permissions. This is precisely how access controls work in ServiceNow. The system does not guess who you are based on your face or your name. It checks your credentials — your security card — which maps directly to a set of rules. Those rules, called Access Control Lists (ACLs), act like the building's security database. They define who can see which records, who can edit them, and who can delete them. The fob itself is like your ServiceNow user account with its assigned roles. A role is a label — resident, maintenance, property manager — that bundles together a collection of permissions. Without the right role, your fob is just a piece of plastic. Without the right ACL, your role means nothing. The door either unlocks or it stays locked. That is the fundamental cause-and-effect: first the system identifies you via your account, then it evaluates your roles against the ACLs, and that evaluation decides whether you gain access or get blocked.
Now imagine a delivery driver tries to enter the building. They might have a valid reason to be there, but they don't have a fob. In ServiceNow, this is an unauthenticated user trying to read a record. The system does not even bother checking ACLs — it simply denies access because the user has no account. This is the first gate: authentication before authorisation. The building analogy also explains how administrators troubleshoot access problems. When a resident cannot get into the laundry room, the property manager does not look at the door lock — they check the fob assignment. In ServiceNow, if a user cannot see a ticket, an administrator reviews their roles and the ACL rules on that table. It is never personal. It is always a rule mismatch. The entire system relies on this consistent, repeatable, machine-readable logic — exactly like the security database in your apartment building.
Access controls in ServiceNow are the rules that decide who can read, write, create, delete, or execute actions on data. Without them, every user would see every ticket, every configuration item, and every customer record. That would be a security nightmare. So ServiceNow uses a layered system built on three main concepts: Access Control Lists (ACLs), roles, and permissions.
Let us start with the most basic building block: the Access Control List, or ACL. An ACL is a rule that sits on a table, a record, or even a single field. Think of it as a gatekeeper that asks three questions about every request: who is making the request, what type of operation are they trying to do (read, write, create, delete, or execute), and does the current context allow it? Each ACL has a condition that must evaluate to true for access to be granted. If the condition is false, the operation is blocked. ACLs are evaluated in a specific order: first by type (record-level versus field-level), then by the order they appear in the ACL list. The first matching ACL that explicitly denies access wins. If no ACL allows it, access is denied by default. This is called the principle of least privilege: nothing is allowed unless a rule explicitly says yes.
Now, roles are the way you bundle permissions together. A role is a label — for example, "snc_platform_user" or "itil". When you assign a role to a user, that user inherits all the permissions tied to that role. Roles can be nested, meaning one role can contain another role. If you have the "admin" role, you effectively have all permissions because the admin role includes every other role. But in a production environment, you almost never give anyone the admin role unless absolutely necessary. Instead, you create custom roles for specific job functions: a helpdesk agent gets one set of roles, a change manager gets another, and a developer gets a different set. Roles are assigned to users individually or through groups. A group is a collection of users, and assigning a role to a group gives that role to every member of the group.
Permissions are the specific rights that a role gives you. For example, the "itil" role grants permission to read and update incident records. But a permission is not a blanket grant. The permission is only effective if the ACL for that table and operation also evaluates to true. So roles and ACLs work together: the role says you are allowed to request this operation, and the ACL says the operation is allowed for your role in this context. Both must agree for access to be granted.
ServiceNow also has a concept called "application cross-scope access". This is relevant for the SNOW-CAD exam because you will build applications that need to access data from other applications. By default, an application cannot read data from another application's tables. You must explicitly configure ACLs to allow cross-scope access. This is a common exam trap: beginners assume that if a user has a role, they can see everything. They cannot. The ACL is the final gate.
Another important concept is the difference between table-level ACLs and field-level ACLs. A table-level ACL controls access to entire records. A field-level ACL controls access to individual fields within a record. For example, you might allow a helpdesk agent to read an incident record (table-level), but hide the "customer PII" field (field-level). Field-level ACLs override table-level ACLs. If a field-level ACL denies access, the field appears empty or hidden, even if the table-level ACL says the user can read the record.
There is also the "condition" script in ACLs. This is server-side code that runs to determine if access should be granted. A condition can check the current user's roles, the state of the record, the time of day, or any other system value. For the exam, you must understand that conditions are evaluated on the server, not the client, and that they can be expensive if written poorly.
Finally, remember that ACLs do not apply to users with the "security_admin" role by default. That role bypasses all ACLs. This is another exam trap: the security_admin role is not the same as the admin role. The admin role can do everything, but the security_admin role is specifically for managing security rules. Do not confuse them.
To sum up the core mechanism:
A user logs in and is authenticated.
The user tries to perform an operation (read, write, create, delete, execute) on a record.
ServiceNow checks the ACL list for the table and the operation.
It checks the user's roles against the ACL's required roles.
It evaluates the ACL condition script.
If the ACL allows it, the operation proceeds. If not, the user gets an access denied error or the record is simply not visible.
This sequence is what you need to remember for the exam.
Identify the data to protect
Before you create any ACLs, you must know which table, record, or field contains sensitive data. In the SNOW-CAD exam, this is usually given in the scenario: a table named 'customer_vip' or a field called 'credit_card_number'. Without identifying the target, you cannot configure the correct ACL type.
Choose the ACL level
Decide whether you need a table-level ACL (controls access to entire records) or a field-level ACL (controls access to a specific field). This choice is critical because field-level ACLs override table-level ones. The exam will test your ability to pick the right level based on the requirement.
Define the operation
Set the ACL operation to read, write, create, delete, or execute. Each operation is a separate ACL. If a requirement says users can view but not edit, you need a read ACL that allows and a write ACL that denies. The exam often gives mixed operation scenarios.
Set the required roles
Specify which roles are needed for the ACL to grant access. You can use the 'Requires role' field to list roles. Alternatively, you can write a condition script using gs.hasRole(). The exam will test whether you understand that roles are the primary mechanism for grouping permissions.
Write the condition script
If the requirement is more complex than just a role check — for example, 'only when the record state is in review' — you write a condition script. The script must return true or false. The exam will give you a script and ask what it does, so you must understand that current.state refers to the record's state field.
Assign roles to users or groups
Once the ACL exists, assign the required roles to users or groups. Assigning to a group propagates to all members. The exam will test that role assignment must happen separately from ACL creation. A common trap is thinking an ACL itself assigns roles — it does not.
Test with different user accounts
After configuration, test by logging in as different users with different roles to confirm the ACL behaves correctly. This step is implied in exam scenarios, but it is the real-world step that catches mistakes before they affect production.
An IT professional working in a company that uses ServiceNow for IT Service Management will configure security and access controls almost daily. Let us walk through a realistic scenario.
The company is a mid-sized bank. The ServiceNow instance has hundreds of tables: incident, change_request, cmdb_ci (configuration items), and a custom table called "customer_account_details" that stores sensitive banking data. The bank's compliance team requires that only the Customer Service Manager role can see the "account_balance" field on the customer_account_details table. No other role — not even IT support — can see that field.
Step one: The administrator creates a new role called "customer_service_manager". This is done in the Roles module under User Administration. They give it a unique name and a description.
Step two: The administrator goes to the ACLs module. They filter for the table "customer_account_details". They see that there is already a read ACL for the table that grants access to the "snc_platform_user" role. This ACL would allow any user with that role to read the entire record, including the balance field. That is a problem.
Step three: The administrator creates a new field-level ACL for the field "account_balance". They set the type to "field level" and the operation to "read". They add the condition that the user must have the "customer_service_manager" role. The condition script might look like: gs.hasRole('customer_service_manager'). They set the order to 100 so it runs before the table-level ACL. They save the ACL.
Step four: The administrator tests this by logging in as a user who has the "snc_platform_user" role but not the "customer_service_manager" role. When that user views a customer record, the account_balance field shows as empty or is not visible. When the administrator logs in as a user with the new role, the field displays the balance. The field-level ACL has overridden the table-level ACL.
Step five: The administrator then assigns the "customer_service_manager" role to the three people in the customer service department. They do this by editing the user records or adding the users to a group and assigning the role to the group. They also set up a scheduled job to audit role assignments every week, ensuring no unauthorised user has been accidentally added.
Step six: The compliance team conducts an audit. They ask the administrator to provide a list of all ACLs on the customer_account_details table. The administrator runs an ACL report from the ACLs module. The report shows the table-level ACL, the field-level ACL, the order, the condition scripts, and the roles required. The audit passes because the field-level ACL is correctly configured and tested.
In this scenario, the IT professional used these specific actions:
Created a custom role.
Navigated to the ACL module.
Created a field-level ACL.
Wrote a condition script using gs.hasRole().
Assigned roles to users and groups.
Tested the ACL with different user accounts.
Generated a report for compliance.
All of these actions are things you need to know how to do for the SNOW-CAD exam. The exam will present you with scenarios like this and ask you to choose the correct combination of ACL type, condition, and role assignment.
The SNOW-CAD exam tests Security and Access Controls heavily. Expect at least 10-15% of your questions to come from this area. Here is exactly what you need to know.
First, the exam loves to test the difference between table-level and field-level ACLs. A typical question describes a scenario where a user can see a record but cannot see one specific field. They ask: what should the administrator create? The correct answer is a field-level ACL. The trap answer is a table-level ACL because the question mentions the user can already see the record. The exam expects you to know that field-level ACLs override table-level ACLs.
Second, the exam tests the order of ACL evaluation. They will give you a list of ACLs with different orders and ask which one applies. The rule is: the system evaluates ACLs in ascending order of the "Order" field. If two ACLs have the same order, the one that was created first wins. If a deny ACL matches, it stops processing. The exam often includes a distractor where an ACL with a higher order number denies access, but a lower-order ACL has already allowed it. In that case, the lower-order ACL wins unless it explicitly says "deny".
Third, the exam tests condition scripts. You will see questions that present a condition script and ask what it does. For example: if (current.state == 3) { answer = true; } else { answer = false; }. The correct answer is that this ACL grants access only when the record's state is 3. The trap is that beginners confuse current with the GlideRecord object. Remember: "current" is the record being evaluated.
Fourth, the exam tests role inheritance. They ask: if role A contains role B, and a user has only role A, does the user have the permissions of role B? Yes. Role containment means the user automatically gets the permissions of all contained roles. However, the exam also tests that role inheritance does not apply to restrictions. If an ACL requires role B explicitly, and the user has role A which contains role B, the ACL still matches because the user effectively has role B.
Fifth, the exam tests application scoping. They ask: when you create a new table in your application, who can access it by default? The answer is: only users who have the role that grants access to your application scope, or users with the admin role. The default ACL for a new table in a scoped application is restricted to the application's own scope. Beginners often think it is open to everyone.
Specific concepts the exam loves:
The gs.hasRole() function: used in ACL conditions to check if the user has a particular role.
The gs.getUser() function: returns the current user object.
The concept of "requires role" in ACLs: this is a checkbox you can set to require a specific role.
The difference between "read" and "write" ACLs: they are separate. A user might be able to read a record but not edit it.
The "execute" operation: this is for scripts and business rules, not just data access.
The default ACL for the sys_user table: users can read their own record but not others' unless they have a specific role.
Traps the exam sets:
Giving you a scenario where a field appears empty. They ask why. The correct answer is often a field-level ACL, not a table-level ACL.
Confusing "admin" role with "security_admin" role. The admin role bypasses all security, but security_admin only has access to security modules.
Asking about cross-scope access without mentioning the ACL module. The correct answer is always to create an ACL in the target application that grants access to the calling application's scope.
Giving you an ACL condition with a syntax error. They expect you to recognise that a condition must return a boolean. If it returns nothing, access is denied.
Memorise these key definitions:
ACL: A rule that controls access to tables, records, or fields.
Role: A label that bundles permissions.
Permission: The right to perform a specific operation.
Condition: A server-side script that evaluates whether access is granted.
Scope: The context of an application; data is isolated by default.
Principle of least privilege: Give users only the minimum access needed.
For the exam, practise writing simple condition scripts in your head. Understand how to navigate the ACL module. Know that you can also use the "high security settings" plugin to enforce more restrictive defaults. But the core of the exam is ACLs, roles, and the relationship between them.
ACLs are evaluated in ascending order of the 'Order' field, and the first matching deny ACL stops all further processing.
Field-level ACLs override table-level ACLs, so a user might see a record but not a specific field within that record.
The admin role bypasses all ACLs, but the security_admin role only grants access to security administration modules.
Roles can be nested; giving a user a parent role gives them all permissions of child roles.
By default, new tables in a scoped application are only accessible to users with roles within that application scope.
The gs.hasRole() function is the primary way to check a user's role in an ACL condition script.
A user must be authenticated before ACLs are evaluated; unauthenticated users are blocked at the authentication gate.
Cross-scope access requires an explicit ACL in the target application that grants access to the calling application.
These come up on the exam all the time. Here's how to tell them apart.
Table-level ACL
Controls access to entire records.
Evaluated before field-level ACLs for the same operation.
If it denies access, the entire record is hidden.
Field-level ACL
Controls access to individual fields within a record.
Overrides table-level ACLs for the specific field.
Can hide a field or make it read-only depending on the operation.
Admin role
Bypasses all ACLs entirely.
Full access to all tables, records, and fields.
Should be reserved for system administrators only.
Security_admin role
Does not bypass ACLs; can only manage security modules.
Access to ACL modules, role management, and security settings.
Used by security administrators who need to configure, not bypass, rules.
Read ACL
Controls whether a user can view a record or field.
If denied, the record or field is invisible.
Evaluated separately from write ACLs.
Write ACL
Controls whether a user can edit a record or field.
If denied, the record or field is visible but not editable.
Does not grant read access; read access must be configured separately.
Role assigned to user
Directly grants permissions to that one user.
Must be updated individually for each user.
Often used for exceptions or temporary access.
Role assigned to group
Grants the role to all members of the group.
Easier to manage for large teams.
Role is automatically available when a user joins the group.
Mistake
If a user has the admin role, they still need ACLs to be configured for every table they access.
Correct
The admin role bypasses all ACLs entirely. An admin user can see and do everything, regardless of what ACLs say.
Beginners think of ACLs as a universal gate, but admin is a special role that completely skips the gate. This is a core feature of ServiceNow.
Mistake
An ACL that grants 'write' access also automatically grants 'read' access to the same record.
Correct
Read and write are separate operations. A user can have write access without read access, though that is unusual. ACLs for read and write must be configured independently.
People assume write implies read because in many other systems it does. ServiceNow treats each operation as an independent permission.
Mistake
If I assign a role to a group, each user in that group must also individually be assigned the role for it to work.
Correct
Assigning a role to a group automatically grants that role to every member of the group. No individual assignment is needed.
Beginners think group membership and role assignment are separate, but they are linked. The group acts as a container for role inheritance.
Mistake
A field-level ACL will make the field completely invisible, no matter what.
Correct
A field-level ACL can either hide the field or make it read-only. It depends on the ACL operation. A 'read' ACL for the field hides it, but a 'write' ACL makes it read-only while still visible.
People do not realise there are two different behaviours. The exam tests this distinction by giving scenarios where the field is visible but greyed out versus completely absent.
Mistake
You can create an ACL that denies access to a specific user by username.
Correct
ACLs evaluate roles, not individual usernames, unless you write a custom condition using gs.getUserName(). The standard ACL interface does not target individual users by default.
It seems logical to block a specific person, but the system is designed around roles for scalability. Beginners try to build user-specific rules, which is not the intended pattern.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A role is a label that bundles permissions, like 'itil' or 'incident_manager'. An ACL is a rule that checks if a user has the right role and meets other conditions to perform an operation on a table or field. Roles are assigned to users; ACLs are configured on data.
Create a field-level ACL for that field with the operation set to 'read'. In the ACL, set the condition or required role so that only the intended users match. Users who do not meet the condition will not see the field.
Technically yes, by writing a condition script using gs.getUserName() == 'john.doe' and returning false. But this is bad practice. ServiceNow is designed to use roles for scalability, not individual usernames.
If no ACL exists for a table and the table is in the global scope, access is denied by default for non-admin users. For scoped applications, the default ACL restricts access to the application's own scope.
You must create an ACL in the target application that explicitly grants access to the calling application's scope. This is called cross-scope access. You cannot rely on user roles alone.
The 'execute' operation controls whether a user can run a script, a business rule, or a scheduled job. It is not for data access but for running code. It is less common but appears in exam questions about security.
You've finished Security and Access Controls. Continue through the SNOW-CAD study guide to build a complete picture of the exam.
Done with this chapter?