Exam domain 2.0 (Application Development Fundamentals) pivots on a single, critical concept: Application Scope and Modules. If you cannot clearly define which application owns what code and data, your work will break other applications and fail your certification. This chapter strips away the complexity and shows you exactly how scopes keep your customisations safe and tidy.
Jump to a section
A simple way to picture Application Scope and Modules
Meet Priya, the chief zoning officer for a large city. Her job is to organise the city into distinct zones: residential, commercial, industrial, and mixed-use. Each zone has its own set of rules about what can be built there, what materials can be used, and who has permission to enter. Priya does not design the buildings herself; she just ensures that every new development is assigned to the correct zone and follows its specific regulations.
Now consider a massive apartment complex called Cloud Tower. Each floor of Cloud Tower is a separate 'application scope' managed by a different team. The leasing office on floor 5 cannot enter the maintenance workshop on floor 8, and the rooftop garden has its own access rules. Priya is responsible for defining which floor gets which purpose, setting up the elevators (modules) that connect floors, and making sure that nobody accidentally renovates a library into a nightclub without her approval. If a plumber wants to work on floor 10, Priya gives them a badge that only unlocks floor 10. The beauty of this system is that a broken pipe on floor 3 does not flood floor 4, because each floor has its own independent plumbing. This maps precisely to how ServiceNow application scopes isolate data, security rules, and customisations. The 'application scope' is the floor, and 'modules' are the rooms within that floor that house specific business functions like incident tracking or HR case management.
In ServiceNow, an 'application scope' is a virtual container that creates a private universe for your application’s assets. Think of it as a sealed, soundproof room. Everything you build inside that scope — tables, business rules, scripts, UI policies — can only see and modify data that belongs to that same scope, unless you explicitly grant cross-scope access. This prevents one developer’s clumsy code from accidentally deleting or corrupting data used by another team.
Before scopes existed, all customisations lived in the 'global' scope. Global is like the town square: everyone can see everything, change anything, and accidentally break someone else’s stall. The global scope still exists, but best practice (and the SNOW-CAD exam) expects you to create a dedicated scope for each solution you build.
Every application scope has a unique name, often written in reverse-URL format (e.g., com.example.hr_tool). Inside that scope, you define 'modules'. A module is a specific entry point or function within your application — like a tab or a menu item that lets users perform a single task. For example, if you build an HR application, your modules might be 'New Hire Request', 'Employee Grievance', and 'Onboarding Checklist'. Modules live inside the application navigator (the left-hand menu in ServiceNow) and give users a way to launch your application’s features.
Why does this matter? Without scopes, two applications could accidentally define a table with the same name, causing a 'collision' where ServiceNow does not know which table to use. Scopes eliminate that collision because each application’s table name is automatically prefixed with its scope name (e.g., u_hr_table vs. u_it_table). The 'u_' prefix stands for 'user-defined' and marks the table as belonging to an application scope rather than to the core system.
The scope also controls 'access controls' (ACLs). If you write an ACL rule inside scope A, it only applies to data from tables within scope A. This means you can safely delegate development work to several teams, each working in their own scope, without fear of cross-contamination.
Here are the key characteristics of application scopes:
Every application must have exactly one primary scope, which is set when you create the application.
A scope cannot be changed after the application is published or has dependencies.
Global scope applications can access all data; scoped applications can only access data within their own scope plus explicit cross-scope references.
When you install an application from the ServiceNow Store, it always comes in its own scope.
Modules, on the other hand, are not scoped individually — they are children of the application. A module can point to a specific table, a report, a dashboard, or even a custom URL. You configure modules in the 'Application Menus' module under System Applications. Each module has a label (what the user sees), a link type (e.g., 'direct link to a page'), and can have a role restriction so only certain users see it.
To create a new application scope and a module inside it, you: navigate to System Applications > My Company Applications > New, fill in the application name and scope, then once the application is created, go to Application Menus > New to add a module. The module’s 'Application' field must be set to your new application. If you forget to set that field, the module will appear in the wrong scope — a classic exam trap.
In summary, scopes are isolation boundaries, and modules are the clickable features that make your application usable. You cannot have one without the other in a well-structured application.
Create a New Application Scope
Navigate to System Applications > My Company Applications and click 'New'. Enter a name (e.g., 'Travel Expense Tracker') and set the scope to a unique reverse domain (e.g., com.acme.travelexpense). This step defines the container where all your future customisations will live. Without this, you are working in the global scope — which is not recommended for SNOW-CAD.
Create a Table in the New Scope
Inside your application scope, go to Tables > Create New Table. The system will automatically prefix the table name with 'u_'. For example, 'u_expense_report'. This table now belongs exclusively to your scope, and its data cannot be seen by other scoped apps without explicit permission.
Define an Application Menu
Go to Application Menus > New. Create a menu called 'Travel Expenses' and set its 'Application' field to your scope. This menu will act as the folder in the left navigation bar that holds your modules. If you skip this step, modules have no logical parent to nest under.
Add a Module to the Application Menu
Navigate to Modules > New. Choose the application menu you just created. Set the 'Link Type' to 'Link to a List' and select 'u_expense_report' as the target table. Set the 'Roles' field to 'snc_platform_user' so regular users can see it. The module now appears in the navigator under the 'Travel Expenses' menu.
Test Cross-Scope Access (if needed)
If another scoped application needs to read your 'u_expense_report' table (for instance, an HR app that needs expense data), go to System Applications > Cross-Scope Access and add a new policy. Grant the HR scope read-only access to your table. Without this step, the HR app’s scripts will fail with a permission error when they try to query the table.
Wrap Everything into an Update Set
When your application is ready to publish or move to a test instance, go to System Updates > Local Update Sets and create a new update set. Assign it to your application scope. Then, capture all changes (tables, modules, menus) into this update set. This ensures the entire application moves as a single unit, preserving scope integrity.
Lena works for a mid-sized retail company that just purchased ServiceNow. Her organisation has three internal teams: IT Support, HR, and Facilities Management. Each team wants to build their own application on the platform.
Lena starts by creating three application scopes: one called 'com.retail.itsupport', another called 'com.retail.hr', and a third called 'com.retail.facilities'. She then gives each team's lead developer the 'Application Developer' role, which allows them to see and edit only their own scope. This is critical: without a dedicated scope, the HR team could accidentally overwrite a table that IT Support relies on for tracking laptops.
Now Lena needs to build the IT Support application. She opens the scope 'com.retail.itsupport' and creates a table called 'u_hardware_asset' to track monitors, keyboards, and cables. Because it is inside this scope, the table name is fully qualified as 'com.retail.itsupport.u_hardware_asset' in the database, even though developers just call it 'u_hardware_asset' in scripts.
Next, she creates modules for the IT Support application:
'Asset Register' — a link to a list view of the u_hardware_asset table.
'Report a Fault' — a link to a new record form for hardware faults.
'Asset Dashboard' — a link to a performance analytics dashboard.
She assigns the 'Asset Register' module to the role 'it_asset_user' so that only IT staff see it. The 'Report a Fault' module is assigned to the 'it_end_user' role so regular employees can see it.
Three months later, the Facilities team wants to reuse the hardware asset table for tracking building access cards. Because the table is scoped, Lena must create a 'cross-scope reference' — a formal bridge that lets the Facilities application read (but not write) the IT Support table. She does this in the System Applications > Cross-Scope Access settings. The exam loves to test this: you cannot simply reference another scope’s table by name; you must define the access explicitly.
Lena also learns that modules are not the same as 'application menus'. An application menu is the top-level folder in the left navigation; modules are the individual items inside that folder. For example, the application menu might be called 'IT Support' and contain the modules 'Asset Register' and 'Report a Fault'. This hierarchy is configurable in the 'Application Menus' table.
The biggest lesson Lena learned: when a developer tells her 'the module is not showing up', nine times out of ten the module’s 'Application' field points to the wrong scope, or the role restrictions are too tight. By checking those two fields, she solves the issue in seconds.
The SNOW-CAD exam tests Application Scope and Modules heavily in the 'Application Development Fundamentals' domain (objective 2.1). Expect roughly 4–6 questions that directly ask about scope isolation, module creation, and cross-scope access.
Here are the specific concepts the exam loves:
The 'u_' prefix rule: any table created in a scoped application must start with 'u_'. The exam will show you a list of table names and ask which one is valid for a scoped app. The answer will always include 'u_' as the first two characters.
Cross-scope access: you will be asked whether a scoped application can read data from the global scope (yes, always) and whether a scoped application can read data from another scoped application without configuration (no — you must set up cross-scope access).
Module link types: you need to know the difference between 'Link to a page' (for a URL or report), 'Link to a list' (for a specific table), and 'Link to a UI16 page' (legacy). The exam often gives a scenario and asks which link type to choose.
Application scope update set: a common trap is asking whether an update set can contain records from multiple scopes. The answer is no — each update set is linked to exactly one application scope. If you try to combine changes from two scopes, you must create two update sets.
Module ordering: modules appear in the application navigator order based on the 'Order' field. The exam may present a module that is not appearing and ask you to debug why. The answer is often 'the Order field is blank or set to 0', which pushes it to the bottom or hides it entirely.
Key definitions to memorise: - 'Application scope': an isolation boundary that keeps an application’s code, tables, and security separate from other applications. - 'Module': a navigational entry (menu item) within an application that links to a specific table, report, or page. - 'Global scope': the default scope that contains all core ServiceNow tables and application. Scoped apps cannot modify global tables but can read them. - 'Cross-scope access policy': a record that defines which tables and fields from one scope can be accessed by another scope.
Common traps:
The exam gives a scenario where a module works in one environment but not another. The root cause is often that the target table exists only in the development environment and was not included in the update set.
They ask 'what happens if you delete a module?' The answer is that the module is removed from the navigator, but the underlying table and records are unaffected. Modules are just pointers, not data containers.
They test that 'Application Menus' are the parent folders and 'Modules' are the children. You cannot create a module without assigning it to an application menu.
Lastly, expect at least one question about 'scope name format'. The correct format is reverse domain notation (e.g., com.acme.payroll). Any answer that uses spaces, underscores in the wrong place, or a single-level name (e.g., 'payroll' alone) is wrong.
An application scope is a sealed container that isolates your tables, business rules, and security rules from those in other scopes.
Every table you create in a scoped application must start with the 'u_' prefix to mark it as user-defined.
A module is simply a navigation link pointing to a table, report, or page; it does not store data itself.
To allow one scoped application to read data from another scoped application, you must create an explicit cross-scope access policy.
Modules will not appear for non-admin users unless you assign roles to them in the 'Roles' field of the module record.
You cannot move a module between scopes by editing its 'Application' field; you must delete and recreate it in the target scope.
Application scopes use reverse domain notation (e.g., com.company.appname) as their unique identifier.
The global scope can access all scoped data, but a scoped application cannot access another scoped application's data by default.
These come up on the exam all the time. Here's how to tell them apart.
Application Scope
Isolates data and code from other applications
Has a unique identifier using reverse domain notation
Cannot be changed after creation and population
Application Menu
Organises modules into a folder structure in the navigator
Uses a simple alphanumeric name with no format restrictions
Can be renamed and reordered at any time
Module
A navigation entry that points to a table, report, or URL
Does not store any data; it is just a link
Can be hidden or made visible based on user roles
Table
A database structure that stores rows of data
Requires a 'u_' prefix in scoped applications
Persists data even if all modules pointing to it are deleted
Global Scope
Contains all core ServiceNow tables (incident, change_request, etc.)
Any code in global scope can read and write all tables on the instance
Use of global scope for new custom applications is discouraged
Scoped Application
Contains only custom tables and code created by developers
Code in a scoped app can only access its own tables and global tables (read-only)
Required for all new applications built on the platform
Cross-Scope Access Policy
Controls whether one scope can read/write tables in another scope
Configured under System Applications > Cross-Scope Access
Grants access at the table or field level between scopes
ACL (Access Control List) Rule
Controls whether a user or role can read/write a specific record
Configured under Security > ACLs
Grants or denies access to individual data rows regardless of scope
Mistake
I can create a module inside one scope and then move it to another scope just by editing the 'Application' field.
Correct
Once a module is associated with a scope via the 'Application' field, changing that field does not move the module; it breaks the module's link to its original application and causes unpredictable behaviour. You must delete and recreate the module in the new scope.
Beginners think fields are just labels, but the 'Application' field is a referential constraint that locks the module to its parent scope for security reasons.
Mistake
If I mark a module as 'visible only in this application scope', it will automatically appear for all users with any role.
Correct
A module's visibility is governed by both its scope and the 'Roles' field on the module record. If no roles are assigned, only users with the 'admin' role see it. You must explicitly add roles (e.g., snc_platform_user) to make it visible to non-admins.
The word 'visible' in the UI implies a binary on/off, but it is actually a filter that defaults to admin-only. Beginners confuse 'visible in scope' with 'visible to all users'.
Mistake
A table created in a scoped application can be accessed by any other scoped application because all scopes exist on the same ServiceNow instance.
Correct
Tables are strictly isolated within their own scope. To allow another scope to read or write to a table, you must create a 'Cross-Scope Access' record. Without it, the other scope cannot even see the table exists.
People familiar with databases assume that because all tables live in the same database instance, they are visible to all. ServiceNow deliberately hides them to prevent accidental data corruption.
Mistake
The 'u_' prefix is optional; I can name my scoped table anything I want as long as it is unique within the instance.
Correct
ServiceNow enforces the 'u_' prefix for all scoped application tables. If you try to create a table without this prefix, the system either rejects it or automatically prepends 'u_'. This is a non-negotiable rule.
Many new developers come from platforms like MySQL where naming conventions are suggestions. ServiceNow rigidly enforces this to distinguish scoped tables from core system tables.
Mistake
Modules and applications are the same thing; I can create an application by just adding a module to the navigator.
Correct
An application is a structured package that includes tables, business logic, and a scope. A module is just a navigation link. You cannot create an application solely by adding a module. The module must belong to an existing application scope.
Beginners see modules as the most visible part of an application (the menu) and assume building the menu is equivalent to building the app. This is like thinking putting up a sign for a restaurant creates the kitchen.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An application scope is a security and data isolation boundary that contains tables, scripts, and business logic. An application menu is just a folder in the left navigation that groups modules together. Think of the scope as the house and the menu as the front door sign.
No. Once an application scope is created and you have started adding tables or code to it, the scope is locked. You cannot change it. You would have to create a new application and manually migrate all your work there.
The module likely has no roles assigned, or it is assigned only to the 'admin' role. To make it visible to regular users, add the role 'snc_platform_user' (or a custom role you have defined) to the 'Roles' field on the module record.
Yes — good practice and the SNOW-CAD exam expect that every custom application has its own dedicated scope. The only exception is minor modifications to the global scope, but that is not recommended for applications you intend to distribute.
ServiceNow will automatically add the 'u_' prefix for you when the table is created inside a scoped application. However, if you try to manually create a table without it, the system rejects the creation with an error.
Yes. Scoped applications can read from global scope tables (like 'incident' or 'task') without any special configuration. However, you cannot write to global tables from a scoped app unless you use a workaround like a scripted REST API that runs in global scope.
You've finished Application Scope and Modules. Continue through the SNOW-CAD study guide to build a complete picture of the exam.
Done with this chapter?