Managing Applications
This domain covers the application lifecycle: Update Sets, source control, testing, deployment, and application publishing. It tests your ability to manage and deploy applications across instances.
Update Sets (Developer Perspective)
Update Sets track configuration changes made in a development instance and allow those changes to be migrated to other instances. For developers, understanding what is and isn't captured is critical.
Update Set Workflow
- Set your current Update Set (picker in the header or System Update Sets > Local Update Sets).
- Make configuration changes — they are automatically captured in the active update set.
- Complete the update set when work is done.
- Export as XML from source instance.
- Import XML into target instance.
- Preview — identifies conflicts and issues before committing.
- Commit — applies changes to the target instance.
Captured vs. Not Captured
| Captured | NOT Captured |
|---|---|
| Business Rules, Client Scripts, Script Includes | Data records (incidents, users, etc.) |
| UI Policies, Data Policies, ACLs | User preferences |
| Table definitions, dictionary entries | Scheduled job run history |
| Form layouts, list layouts | Homepage configurations |
| Notifications, events | Attachments (by default) |
| System properties | Report sharing/ownership |
Update Sets capture CUSTOMIZATIONS only, not DATA. If you need to move data between instances, use Import Sets or Data Preservers. Preview ALWAYS before committing — it reveals conflicts that could break things in the target instance.
Source Control Integration
ServiceNow Studio integrates with Git repositories for version control. This allows teams to track changes, collaborate, and manage branches.
Source Control in Studio
- Link Application — Connect a scoped application to a Git repository.
- Commit Changes — Push application artifacts to the repository.
- Apply Remote Changes — Pull changes from the repository into the instance.
- Branching — Create and switch between branches for feature development.
- Stashing — Temporarily store uncommitted changes.
- Supported providers: GitHub, GitLab, Bitbucket, Azure DevOps.
Source control in Studio is the recommended approach for team-based development. It replaces update sets for scoped applications. Each developer works on their own instance and commits changes to a shared repository. Changes are pulled into test/production instances from the repository.
Testing & Debugging
Testing is essential before deploying applications. ServiceNow provides several tools for testing and debugging.
Testing Tools
- Automated Test Framework (ATF) — Create and run automated test suites.
- ATF tests simulate user interactions: form submissions, role-based testing, workflow testing.
- Test Suites — Group related tests for batch execution.
- Script Debugger — Step through server-side script execution.
- System Diagnostics — Session Debug for real-time logging.
- Impersonation — Test as different users to verify ACLs and role-based behavior.
Debugging Techniques
- gs.log() / gs.info() — Write to system logs for server-side debugging.
- jslog() — Write to browser console for client-side debugging.
- Session Debug modules — Enable verbose logging for specific areas (security, BR, etc.).
- Script Debugger — Breakpoints and step-through execution in Studio.
- System Logs > Script Log Statements — View gs.log output.
ATF (Automated Test Framework) is the recommended testing tool. It supports testing Business Rules, ACLs, workflows, and user interactions. Tests can be part of CI/CD pipelines. gs.log() output goes to System Logs > Script Log Statements. jslog() outputs to the browser console.
Application Deployment & Publishing
Applications can be deployed across instances through several methods: Update Sets, source control, or the ServiceNow App Repository.
Deployment Methods
| Method | Best For | Mechanism |
|---|---|---|
| Update Sets | Simple customizations, global scope changes | XML export/import |
| Source Control | Scoped app development in teams | Git repository push/pull |
| App Repository | Distributing to multiple instances | Publish to company's app repo |
| ServiceNow Store | Commercial or public distribution | Submit for review and listing |
Application Publishing
- Applications can be published to the company's App Repository.
- Versioning — Each published version gets a version number.
- Dependencies — Declare dependencies on plugins or other applications.
- Installation — Target instances install apps from the repository.
- Upgrades — New versions can be pushed as upgrades.
For scoped applications, source control is preferred over update sets. For global customizations, update sets are still necessary. The app repository allows centralized distribution across multiple instances. Know the difference between these deployment methods.
Instance Strategy & Best Practices
Organizations use multiple ServiceNow instances for development, testing, and production. Understanding the instance strategy is important for the exam.
Standard Instance Strategy
- Development (Dev) — Where developers build and configure. One or more dev instances.
- Test/QA — Where changes are tested before production. Mirrors production data/config.
- Staging/UAT — User Acceptance Testing. Business users validate functionality.
- Production (Prod) — Live instance used by the organization.
Promotion Path
Dev → Test → Staging → Production
- Never develop directly in production.
- Always preview update sets before committing.
- Test with production-like data and configurations.
- Use clone to refresh sub-production instances from production.
The promotion path is Dev → Test → Prod (or Dev → Test → Staging → Prod). Never skip environments. Always test thoroughly before promoting to production. Instance cloning refreshes sub-production instances with production data, but remember to preserve development work (update sets, custom apps) during cloning.
Key Takeaways
- Update Sets capture customizations only, not data. Always preview before committing.
- Source Control (Git) is preferred over Update Sets for scoped application development.
- ATF (Automated Test Framework) is the recommended tool for automated testing.
- Deployment path: Dev → Test → Staging → Production. Never develop in production.
- gs.log() for server-side debugging. jslog() for client-side debugging.
- Application Repository allows centralized distribution of scoped applications.
- Instance cloning refreshes sub-production with production data. Preserve dev work before cloning.
Community-created study aids. Not official ServiceNow exam content.