Security and Restricting Access · Topic 1 of 4
Restricting Access to Applications and Modules
ServiceNow CAD: restrict application menus and modules with roles, build user and admin roles for an app, and why hiding navigation is not data security.
- 5 min
- Application menus and modules each have a Roles field; a user needs one of the listed roles to see the item.
- Hiding the menu hides all its modules; a visible menu still checks each module.
- An empty Roles field means visible to everyone who can see the parent.
What it is
An application appears in the navigator as an application menu with modules under it. Each menu and each module has a Roles setting. A user who holds none of the listed roles does not see that menu or module.
This controls what people see, not what they can reach. The data behind a module is protected only by access controls (ACLs), which are covered on the next page.
How it works
Application roles
A scoped application normally defines its own roles. Their names begin with the scope namespace, for example x_acme_travel.user and x_acme_travel.admin, so they cannot clash with roles from other applications.
A common design is a user role for everyday work and an admin role for configuration. The admin role contains the user role, so anyone with the admin role also gets everything the user role allows.
| Role design | Purpose |
|---|---|
| Application user role | Open the menu, work with the app's records |
| Application admin role | Configuration modules such as properties; contains the user role |
Platform admin | Passes role checks everywhere, including app menus |
Give these roles to groups, not to individuals, so that a person's access follows their team membership.
Where the role settings live
You set roles on the Application Menu record and on each Module record. In Studio you open them from the application's Navigation files; in the classic interface the same records are under System Definition.
The rule has two levels. If a user cannot see the menu, they see none of its modules. If they can see the menu, each module is still checked against its own Roles setting.
A module with an empty Roles field is visible to anyone who can see the menu. A menu with an empty Roles field is visible to every user who can sign in.
Roles created while building
When you create a table in an application, the Controls section offers Create access controls with a User role field. You can type a new role name or pick an existing role. The platform then creates the role if needed and the table's basic ACLs, so only users with that role can work with the records.
App Engine Studio and Studio both let you create roles as application files. A role created inside the application is packaged with it and moves with each published version.
Why navigation is not security
Hiding a module removes a link. It does not remove the table. A user who knows the URL of a list or form, a report on the table, a related list on another form or a REST call can still reach the records unless an ACL blocks them.
| Requirement | Right tool |
|---|---|
| Keep the app out of the navigator for most staff | Roles on the application menu |
| Show a configuration module only to app admins | Roles on that module |
| Stop users from reading the records at all | ACL on the table |
| Stop users from changing one field | ACL on that field |
How the exam asks about this
- "Only managers should see the Approvals module, but all app users see the rest." Put the manager role on that module, not on the menu.
- "Users with no app role still open the list by typing its URL." Hiding the module was not enough; add table ACLs that require the app role.
- "Grant a team access to the whole application in one step." Add the application user role to the team's group.
What to remember for the exam
- Application menus and modules each have a Roles field; a user needs one of the listed roles to see the item.
- Hiding the menu hides all its modules; a visible menu still checks each module.
- An empty Roles field means visible to everyone who can see the parent.
- Scoped role names begin with the scope namespace.
- An app admin role usually contains the app user role.
- Roles on navigation are cosmetic; ACLs protect the data.
If an answer option says "remove the role from the module" to protect data, it is wrong. The table stays reachable by URL, list, report and API until an ACL denies the access.
Common mistakes
Treating a hidden module as secured data. The module only links to a list or form. Without ACLs the records are open to anyone who reaches the table another way.
Putting a narrow role on the menu. If the menu requires the admin role, normal users lose every module, including the ones they need. Put narrow roles on individual modules instead.
Assigning application roles to each user. It works but is hard to maintain. Grant the role to a group and manage membership.
Check yourself
A module has an empty Roles field and its menu requires the app user role. Who sees the module?
Every user who holds the app user role, because the menu check passes and the module adds no extra role.
Why should the app admin role contain the app user role?
So an admin automatically has all user access as well, without being granted two roles.
Does removing a module stop users from reading the table's records?
No. Records stay reachable through URLs, reports and APIs until an ACL denies the access.
Topic 1 of 4 in Security and Restricting Access
Test yourself on Security and Restricting Access
The full ServiceNow CAD question bank has 600 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ServiceNow. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.