Application scopes let you package customizations into portable, version-controlled applications that can be published to the ServiceNow Store. This guide walks you through creating a scope and understanding the access restrictions that come with it.
Why scoped applications exist
Before scoped applications, all customizations lived in the global scope — tables, scripts, and business rules from different projects mixed together with no boundaries. When you needed to move customizations between instances, you'd export update sets that often contained unrelated records, and versioning was a nightmare. Platform architects and developers had no way to isolate their work or prevent one team's changes from breaking another's. The people maintaining these systems couldn't tell which customizations belonged to which project, and rolling back changes meant picking through interdependent records.
How scoped applications work
A scoped application creates a namespace (like 'x_myco_project') that isolates all its records — tables, scripts, UI pages, and configurations. ServiceNow treats each scope as a separate container with its own access rules. When you create records inside a scope, they can only directly access other records in the same scope or explicitly granted global records. Cross-scope access requires specific APIs or access controls. The progression is: create the scope, build your customizations inside it, then optionally publish it as an installable application. Most developers start with a basic scope for a single project and evolve toward reusable applications with proper APIs.
Building production-quality scoped applications
After your scope works, the improvements that matter are: defining a clean API for other scopes to interact with your application, setting up proper application properties for configuration, and creating comprehensive update sets or store applications for deployment. Production-quality scoped apps have minimal cross-scope dependencies, well-defined interfaces through Script Includes with public access, and clear documentation about what other scopes can safely use. The best scoped applications are self-contained enough that they can be installed on any instance without breaking existing functionality.
Before you start
- •admin role or application_admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Studio
Go to System Applications > Studio. This opens the application development environment where you'll create and manage your scoped application. Studio is the primary interface for all scoped application development — you can't create scopes from other modules.
Studio automatically switches your session context to whatever scope you're working in, so any records you create will belong to that scope.
Create a new application
Click the "Create Application" button on the Studio homepage. This launches the application creation wizard that will set up your scope and initial structure. Don't use "Import from Source Control" unless you're connecting to an existing repository.
Configure application details
Fill in the Name field with your application's display name — this is what users see in lists and menus. The Scope field auto-generates based on your name but you should customize it. Use format 'x_company_project' where company is your organization identifier and project describes the application purpose. Set Version to '1.0.0' and leave User role blank unless you need end-user access controls.
Set the scope prefix
Verify your Scope field starts with 'x_' — this is required for custom applications. Keep the scope name short but descriptive because it prefixes every table and script you create. Avoid generic names like 'x_custom_app' because they become meaningless when you have multiple applications. Click "Create" to generate the application structure.
You can't change the scope name after creation, so spend time getting this right.
Verify scope creation
Studio automatically opens your new application and shows the application dashboard. You'll see your scope name in the top navigation and an empty file tree on the left. The application record is created in the sys_app table, and your scope is now active for development.
Test scope isolation
Create a test table by clicking "Create Application File" > "Table" to verify your scope is working. Name it something like 'Test Data' and notice the table name gets the scope prefix automatically (like 'x_myco_project_test_data'). This confirms your scope is properly isolating new records.
Configure cross-scope access
Go to System Applications > Application Cross-Scope Access if you need your application to read global tables or call global Script Includes. Add specific records your scope needs to access — don't grant broad access. Most applications need access to common tables like sys_user, but avoid granting access to sensitive tables unless absolutely necessary.
Best practices
Keep scope names concise but specific — you'll type that prefix constantly, and long scope names make code harder to read.
Never create tables or major customizations in global scope after you have scoped applications — it creates dependencies that break application portability.
Grant cross-scope access to specific records, not entire applications — blanket access defeats the isolation benefits of scoping.
Use Application Properties for configuration values instead of hardcoding — it makes your application configurable without code changes.
Create a dedicated Script Include with public methods for any functionality other scopes might need — private scope internals should stay private.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue