Overview
Security and Restricting Access covers the layers that decide what a user or another application can do. At the top, roles on application menus and modules control what appears in the navigator. Underneath, access controls (ACLs) decide whether a user can create, read, write or delete a table's records and individual fields. Scripts can check identity and roles with GlideSystem methods, and application scope adds a separate boundary that decides what other applications may do with your tables and scripts.
The four objectives move from navigation to data to code to applications. You must be able to create access controls automatically and by hand, test them by impersonation, and debug them when a user sees too much or too little. This domain depends on Domain 1's tables and scope, and it explains why the form-level hiding from Domain 2 is not protection.
How it's tested
Questions describe a user, their roles and a set of access controls or scope settings, then ask what the user can do or why something failed. Others ask for the best way to restrict access with the least effort. Read every condition on the rule and every checkbox on the table: one unchecked option usually decides the answer.
-
Predict the outcome
Given roles and access controls at table and field level, determine whether a user can read or write a record or a specific field.
-
Choose the restriction layer
Decide between module roles, access controls, GlideSystem checks in a script, or scope application access for a stated requirement.
-
Diagnose denial
A user or another application is blocked unexpectedly, and you identify the failing rule, missing role or scope setting, or the tool to debug it.
A user has the required role for a table's read access control, yet the Salary field shows empty. Field access requires the table-level rule and a field-level rule to both pass. A separate read rule on the Salary field requires a manager role the user lacks, so the record is visible and the field is not. The fix is to adjust the field-level rule or the user's roles, not the table rule.
Objectives 4
Official objectives from the ServiceNow outline, in outline order.
3.1 Restrict access to applications and application modulesRoles that control what appears in the navigator.
- What it means
- Application menus and modules have a Roles field. Users without one of the listed roles do not see the menu or module in the application navigator.
- What to understand
- This controls navigation, not data. Roles should be granted to groups and users inherit them through membership, which keeps access manageable. Data protection still requires access controls on the tables the modules point to.
- How it shows up
- A scenario asks how to show an application only to its team members, or why a user without the module can still open records by URL.
- Common confusion
- Believing a hidden module stops a user from reaching the table; it only removes the link.
3.2 Manually and automatically create, test, and debug Access ControlsBuilding, evaluating and troubleshooting ACLs.
- What it means
- Access controls define an operation (such as create, read, write or delete) on an object (a table, a field, or another resource type), and grant it when the required roles, the condition and the script all pass. Creating a table with the default options can generate a user role and create, read, write and delete rules automatically.
- What to understand
- Rules are matched from most specific to most general, for example table.field, then parent-table.field, then *.field, and if any matching rule at the first level found passes, access is granted. A user needs both table-level and field-level permission to work with a field. Editing access controls requires elevating to the security_admin role, and testing is done by impersonating users and using the security rule debugging tools.
- How it shows up
- A scenario gives roles and rules and asks whether a user can read or edit a record or field, or which tool shows why access was denied.
- Common confusion
- Thinking that a passing role check is enough; the condition and script on the same rule must also pass.
3.3 Use GlideSystem methods to script securityChecking identity and roles in server-side scripts.
- What it means
- GlideSystem methods such as gs.hasRole(), gs.getUser(), gs.getUserID() and gs.getUser().isMemberOf() let a server-side script, such as an access control script or business rule, make decisions based on who is running it.
- What to understand
- An access control script sets answer to true or false, and should be used only when roles and conditions cannot express the rule. gs.hasRole() returns true for users with the admin role regardless of the role named. Client-side g_user.hasRole() can shape the form but cannot secure data.
- How it shows up
- A rule must allow edits only by the record's assigned user or members of a specific group, and you choose the condition or GlideSystem script that expresses it.
- Common confusion
- Using g_user checks in a client script as the security control instead of a server-side access control.
3.4 Use Application Scope to protect application artifactsApplication access, script include protection and cross-scope privileges.
- What it means
- Each scoped table has application access settings that decide whether other scopes can reach it and whether they can read, create, update or delete its records, plus whether web services and configuration from other scopes are allowed. Script includes have an Accessible from setting, and cross-scope privilege records track or control runtime calls between scopes.
- What to understand
- Scope rules apply in addition to access controls: an admin running code in another scope can still be blocked if the table does not allow that operation. Runtime access tracking can be set to None, Tracking (records and allows cross-scope calls) or Enforcing (calls are blocked until an admin allows the requested privilege).
- How it shows up
- A script in another scoped application can read your records but fails to create them, and you identify the application access setting responsible.
- Common confusion
- Assuming the admin role overrides application access settings; scope protection is evaluated separately from user roles.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Three-part access control check
An access control grants access only when the user has one of the required roles, the condition evaluates true and the script returns true; empty parts count as passing.
- Remember
- All three parts of a single rule must pass, so a correct role does not help if the condition fails.
- Tested as
- Underlies most outcome-prediction questions.
- Trap
- Stopping evaluation after confirming the user has the role.
-
Rule matching order
The platform looks for rules from most specific to most general: the exact table and field, then parent tables, then wildcard rules, and evaluates the first level where matches exist.
- Remember
- If any rule at that first matching level passes, access is granted; the platform does not keep searching more general rules.
- Tested as
- Explains why a specific child-table rule overrides a parent rule.
- Trap
- Expecting a generous wildcard rule to grant access when a more specific rule exists and fails.
-
Table and field rules together
To read or write a field, a user must pass the table-level rule (table.None) and the field-level rule (table.field or its wildcard).
- Remember
- Passing the field rule alone does not grant access if the table rule fails, and the reverse is also true.
- Tested as
- Classic question: record visible, one field empty or read-only.
- Trap
- Changing the table rule to fix a field-level denial.
-
Automatically generated access controls
Creating a table with Create access controls selected generates a user role and create, read, write and delete rules that require it.
- Remember
- Users and testers need the generated role, ideally through a group, to see records.
- Tested as
- Tested as the quick, secure-by-default way to protect a new table.
- Trap
- Thinking new tables are readable by every logged-in user.
-
security_admin elevation
Creating or editing access controls requires elevating to the security_admin role during the session, even for admins.
- Remember
- Elevation is temporary and explicit, which is why admins sometimes cannot save a rule.
- Tested as
- Answers 'why can the admin not save this access control'.
- Trap
- Assuming the admin role alone allows ACL changes.
-
Admin overrides
The Admin overrides option on an access control lets users with the admin role pass the rule even when its role, condition or script would deny them.
- Remember
- With Admin overrides cleared, admins are evaluated like anyone else for that rule.
- Tested as
- Explains why an admin is unexpectedly denied.
- Trap
- Believing admins bypass every access control in all cases.
-
Impersonation and security debugging
Impersonating a test user shows exactly what that user can access, and the security rule debugging output and Access Analyzer show which rules passed or failed.
- Remember
- Test with a real role combination, not as admin, which hides problems.
- Tested as
- Questions ask the best way to test or debug a rule.
- Trap
- Testing as admin and concluding the rule works.
-
gs.hasRole()
gs.hasRole('role_name') returns true when the current user has that role, and always returns true for users with admin.
- Remember
- Use it in server-side scripts such as access control scripts, not as a client-side check.
- Tested as
- Appears in scripted security scenarios.
- Trap
- Expecting it to return false for an admin who lacks the named role.
-
Application access settings
On a scoped table, Accessible from sets whether other scopes can see it at all, and Can read, Can create, Can update and Can delete set which operations they may perform.
- Remember
- These checks apply to scripts running in other scopes regardless of the user's roles.
- Tested as
- Central to cross-scope failure scenarios.
- Trap
- Changing ACLs to fix a scope-level block.
-
Allow access via web services
A table-level option decides whether the table can be reached through web service APIs.
- Remember
- When cleared, web service requests are blocked even for users whose access controls would allow the operation.
- Tested as
- Links this domain to integration questions in Domain 5.
- Trap
- Troubleshooting REST failures only through roles.
-
Script include Accessible from
A scoped script include can be callable from this application scope only or from all application scopes.
- Remember
- Calls from another scope use the full scoped name, such as x_acme_app.Utils, and fail if access is limited to the owning scope.
- Tested as
- Appears when another application cannot call shared code.
- Trap
- Assuming public JavaScript functions are callable from any scope.
-
Runtime access tracking
An application's runtime access tracking can be None, Tracking (cross-scope calls are allowed and logged as privilege records) or Enforcing (unapproved calls are blocked until an admin allows them).
- Remember
- Under Enforcing, a new cross-scope call creates a requested privilege that must be set to allowed.
- Tested as
- Explains why cross-scope code works in development but fails after enforcement is turned on.
- Trap
- Thinking access tracking replaces application access settings.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Module roles vs. access controls vs. application access
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Module and menu roles | Hide navigator links from users without the role | Navigation only | Treating it as data security |
| Access controls | Grant create, read, write, delete and other operations by role, condition and script | Protect records and fields for users | Using them to fix cross-scope blocks |
| Application access | Table settings for what other scopes and web services may do | Protects artifacts from other applications regardless of user | Expecting admin to override it |
Table-level vs. field-level access controls
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Table-level (table.None) | Controls the record as a whole | Must pass before any field can be accessed | Thinking it alone grants every field |
| Field-level (table.field) | Controls a single field | Can deny one field on an otherwise visible record | Changing the table rule to fix it |
| Wildcard (table.*) | Applies to every field without a specific rule | Used only when no more specific field rule matches | Expecting it to override a failing specific rule |
Runtime access tracking modes
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| None | No cross-scope privilege records are tracked | Calls allowed by application access proceed untracked | Assuming it blocks everything |
| Tracking | Cross-scope calls run and are recorded as allowed privileges | Builds an inventory during development | Thinking it stops calls |
| Enforcing | Unapproved calls are blocked and recorded as requested | An admin must allow each privilege | Forgetting to approve after switching modes |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Role passes, so access passes
- What candidates pick
- The user can edit the record because they hold the role listed on the write rule.
- Why it looks right
- Roles are the most visible part of an access control.
- Why it's wrong
- The rule's condition, such as state is New, and any script must also pass; one false part denies that rule.
Clue to watch for The access control in the scenario has a condition or script in addition to a role.
-
Broader rule rescues a failed specific rule
- What candidates pick
- The user can read the field because a table.* rule they pass exists.
- Why it looks right
- Candidates expect the most permissive rule to win.
- Why it's wrong
- When a more specific table.field rule matches, the wildcard is not used; access depends on the specific rule.
Clue to watch for Both a specific field rule and a wildcard rule appear in the scenario.
-
Admin bypasses everything
- What candidates pick
- An admin's script in another scope can insert records because admins have full access.
- Why it looks right
- Admin usually overrides access controls through Admin overrides.
- Why it's wrong
- Application access settings are evaluated for the calling scope, independent of the user, so Can create unchecked blocks the insert.
Clue to watch for The failing code runs in a different scoped application from the table.
-
Client-side role check
- What candidates pick
- Use g_user.hasRole in a client script to make a field read-only for non-managers.
- Why it looks right
- It works on the form and is quick to write.
- Why it's wrong
- Client-side logic shapes the user interface only; the field can still be changed through lists, imports or APIs without a write access control.
Clue to watch for The requirement says users must not be able to change the value, not merely see it as read-only.
-
Test as admin
- What candidates pick
- Verify a new access control by opening the record while logged in as admin.
- Why it looks right
- Admins can see everything, so the record opening feels like proof.
- Why it's wrong
- Admin access hides failures; impersonate a user with the intended roles to see real behavior.
Clue to watch for The question asks for the best way to confirm what a specific user can do.
-
Script first
- What candidates pick
- Write an access control script with gs.hasRole for a simple role requirement.
- Why it looks right
- Scripts feel flexible and explicit.
- Why it's wrong
- Roles and conditions on the rule are simpler, faster and easier to audit; scripts are for logic they cannot express.
Clue to watch for The requirement can be stated purely in roles or field values.
Answer framework
When a Domain 3 question asks whether access is allowed or how to restrict it, check the layers in this order.
- Separate navigation from data: module and menu roles change what users see in the navigator, never what they can access.
- Find the most specific matching access controls at the table level and confirm role, condition and script all pass on at least one.
- Repeat the check at the field level, since both table-level and field-level rules must grant the operation.
- If code from another scope is involved, check the table's application access settings, script include accessibility and runtime access tracking.
- Prefer roles and conditions over scripts, elevate to security_admin to edit, and confirm results by impersonating a realistic test user.
Practice question
Want more like this? The ServiceNow CAD practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Learn this domain by predicting, then testing. Start with access control evaluation, because it underpins most questions. In a personal developer instance, create a scoped table with generated access controls, then add a field-level read rule that requires a second role. Create two test users with different roles and impersonate each one, writing down what you expect before you look.
Next, add a condition to the write rule, such as allowing edits only while state is New, and watch the role alone fail. Toggle Admin overrides and test as admin. Turn on security rule debugging and read which rules passed. These experiments cover the matching order and the three-part check.
Candidates most often underestimate scope protection. Build a second scoped application with a script that reads, then inserts into the first application's table. Clear Can create and see the insert fail even as admin. Switch runtime access tracking to Enforcing and approve the requested privilege.
Finish with timed questions that describe roles and rules, and for every miss, note whether you skipped the condition, the field level or the scope layer. Then review Domain 5, where web service access settings matter again.
FAQ
How much of the ServiceNow CAD exam is security?
Security and Restricting Access is 20% of the exam. As a planning estimate that is about 12 questions, though ServiceNow does not publish per-domain counts.
How are access controls evaluated?
The platform finds the most specific matching rules, starting with the exact table and field and moving to parent tables and wildcards. If any rule at the first matching level passes its role, condition and script checks, access is granted.
Why can a user see a record but not one of its fields?
Field access needs both the table-level and field-level rules to pass. A field-level rule requiring a role the user lacks will hide or lock that field while the record stays visible.
Why can an admin not save an access control?
Creating or editing access controls requires elevating to the security_admin role for the session. The admin role alone is not enough.
Does the admin role bypass application scope protection?
No. Application access settings control what code in other scopes can do with a table, independent of the user's roles.
When should an access control use a script?
Only when roles and conditions cannot express the rule, such as comparing the current user to a field value through GlideSystem. Scripts are harder to maintain and audit than configured parts.
How does this domain connect to integrations?
Web service requests are subject to access controls and to the table's web service access option, so the same security model decides what REST integrations in Domain 5 can do.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have worked through module roles, access control evaluation, GlideSystem security checks and scope protection. Check whether you can predict access outcomes accurately under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ServiceNow CAD AI tutor Get any concept explained your way