--- sourceDocument: Australia Build or modify applications sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/application-development Release : - australia ft:locale : - en-US ft:publication_title : - Australia Build or modify applications ft:clusterId : - cadev bundleId : - cadev workflow : - Development, Data, and Analytics --- # Explore # Exploring Developer Sandboxes {#ariaid-title1} Release version: Australia Updated August 17, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Exploring Developer Sandboxes Developer Sandboxes in ServiceNow provide isolated, on-demand development environments that enable multiple developers to build and test in parallel on top of a shared base instance. Each sandbox contains the full metadata of the base instance and is fully isolated from others, reducing code conflicts and enabling faster, safer development and testing without impacting other team members' work. Show full answer Show less This approach addresses common challenges in managing urgent fixes and feature enhancements simultaneously by eliminating risks like code conflicts and configuration overlaps that arise with traditional shared development environments. ## Key Features * **Isolation:** Independent sandboxes ensure developers' changes do not affect each other. * **Faster Delivery:** Parallel workstreams reduce development cycle times and accelerate turnaround for fixes and enhancements. * **Safe Testing:** Developers can safely test configurations, workflows, and integrations within their sandbox without risking system stability. * **On-demand Provisioning:** Sandboxes can be quickly provisioned for specific tasks or experiments by admins or developers. * **Integration with Source Control:** Developer Sandboxes integrate with tools like Git, enabling merge conflict resolution and streamlined parallel development. * **Sandbox Management Dashboard:** Provides visibility into total, allocated, and available sandboxes along with status, data usage, ownership, and activity. * **Support for Build Agent:** Build automation is supported within Developer Sandboxes. * **Sandbox Templates and Aliases:** Facilitate reusing configurations and easily allocating sandboxes to users or specific tasks. * **Single Sign-On (SSO):** Sandboxes support SSO consistent with the base instance for seamless authentication. ## User Roles and Workflow * **Delegated Developers:** Can request sandboxes and perform development work. * **Admins:** Allocate and retire sandboxes, and clone changes to shared instances. * **Sandbox Managers:** Manage sandbox lifecycle without full admin privileges. * **Sandbox Users:** Access sandboxes using the same credentials as the base instance. The typical workflow involves allocating a sandbox, making and testing changes in isolation, then promoting changes to shared test or QA instances via source control (recommended) or update sets. Admins clone changes from test/QA instances back to the base instance to update the baseline for future sandboxes. ## Important Considerations * Sandboxes are automatically retired after upgrades or clones; preserve work before these actions. * Restore work from remote update sets after upgrades; manual save/restore is required after clones. * Custom table configurations or fixes must be reapplied post-upgrade. * Check entitlements to verify access to Developer Sandboxes. ## Benefits for ServiceNow Customers * Enables parallel development with multiple team members working on different features simultaneously while maintaining a clean baseline. * Reduces merge conflicts and improves co-development efficiency via integration with source control. * Speeds up delivery cycles and improves agility by allowing safe and independent testing. * Simplifies sandbox management through templates, aliases, and role-based allocation. ## Next Steps For customers looking to implement Developer Sandboxes, reviewing installation and configuration guidance is recommended to maximize benefits and ensure smooth adoption within your ServiceNow environment. Developer Sandboxes provide isolated development environments that enable parallel building and testing on top of a shared development instance. Use sandboxes to reduce code conflicts, accelerate delivery, and safely test configurations without affecting other team members' work. Figure 1. How Developer Sandboxes work * Developer Sandboxes are isolated environments for parallel building and testing. * Each sandbox is provisioned on demand and fully isolated from others. * Every sandbox contains the full metadata of the base instance. * Sandboxes can be assigned to specific stories, developers, test plans, or custom criteria. {#exploring-sandboxes__ul_zw4_r3m_13c} ## Developer Sandboxes overview {#exploring-sandboxes__cf-exploring-parent-overview} Developer Sandboxes aim to provide lower-cost developer isolation and parallelism for customer development environments and instances. Developer Sandboxes are workflow-agnostic and are broadly applicable across workflows for both smaller and larger companies. Organizations can face challenges when addressing urgent defects and critical feature enhancements simultaneously in applications. Traditional shared development environments introduce risks such as code conflicts, configuration overlaps, and deployment delays, making it difficult to manage parallel workstreams efficiently. Development teams struggle to deliver urgent fixes and new features concurrently without disrupting each others' progress. The absence of isolated, independent development environments slows down delivery, increases rework, and hampers overall agility. Developer Sandboxes enables better development in the following ways: * Isolation: Each developer works in an independent sandbox, ensuring changes do not affect other team members' work. * Faster delivery: Teams can work concurrently, reducing development cycle time and enabling faster turnaround for urgent fixes and enhancements. * Safe testing: Developers can test configurations, workflows, and integrations within their sandbox without risking system stability. * On-demand provisioning: Admins and developers can quickly provision sandboxes for specific tasks or experiments without waiting for shared resources. {#exploring-sandboxes__ul_hc5_q4c_hgc} Note: Personal Development Instances (PDIs) are still available, but they don't have a controlled baseline configuration like Developer Sandboxes do. The Sandbox Management home dashboard displays the total, available, and allocated sandboxes in your instance. The dashboard also displays information relevant to each sandbox, including, the status, data utilization, owner, last accessed date, and when the sandbox was allocated. Check your entitlements to determine whether you have access to Developer Sandboxes. For more information, see [Developer Sandboxes entitlements](https://servicenow-prod.fluidtopics.net/YZOONAc9YFBLi_mDhQOr1Q "Your company's entitlements determine whether you have access to Developer Sandboxes."). Warning: Because sandboxes are retired automatically after an upgrade or clone, ensure any work that you want to keep is preserved before upgrading or cloning. * For upgrades, you can restore work from the remote update sets that Developer Sandboxes automatically created from prior sandboxes. * For clones, you must manually save and restore all work in sandboxes. * Any custom table configuration changes or fixes must be reapplied after an upgrade. Contact Now Support to open a case. For details, see [Cloning and upgrading considerations for Developer Sandboxes](https://servicenow-prod.fluidtopics.net/RgastIyV7MfytBs4ckus5g "You should understand how plugins and sandboxes work before you clone or upgrade an instance with Developer Sandboxes. Always back up your work in a sandbox before any clone or upgrade, either by exporting the update sets or committing to source control."). Build Agent is supported in Developer Sandboxes. For more information, see [Build Agent](https://servicenow-prod.fluidtopics.net/uPGWJkjDyp1tG_cmu3eF3Q "Use Build Agent, an autonomous AI agent, for creating and updating ServiceNow applications. You can also ask Build Agent general ServiceNow development questions."). ## Integrate sandboxes with source control {#exploring-sandboxes__section_lcq_5hg_ggc} Developer Sandboxes provide an isolated environment that integrates with source control, such as Git. Using merge tools helps eliminate conflicts and enables parallel development. For more information, see [Source control and Developer Sandboxes](https://servicenow-prod.fluidtopics.net/y~WASxZ1VxWQrZAIauSFKQ "Use source control with Developer Sandboxes to enable parallel development and prevent merge conflicts."). ## Developer Sandboxes users {#exploring-sandboxes__cf-exploring-parent-users} {#exploring-sandboxes__table_cw5_sqm_bcc__entry__2} | User | Description | |-|-| | Delegated developers | Delegated developers can request sandboxes from an admin or sandbox manager. | | Admins | Admins can allocate or retire sandboxes. | | Sandbox managers | Sandbox managers can administer the lifecycle of all sandboxes without full admin privileges. | | Sandbox users | Sandbox users can request and view Developer Sandboxes. | [Table 1. Users] {#exploring-sandboxes__table_cw5_sqm_bcc} Sandbox users use the same login credentials for their sandbox as the base instance. If you use Single Sign-On (SSO) for login, when you enable it to connect to your account on the base instance, Developer Sandboxes authenticates using the same mechanism and credentials as the base instance. For information on enabling SSO, see [Installing Developer Sandboxes](https://servicenow-prod.fluidtopics.net/s3m6zeKoFa29eyxCeSKi5g "Developer Sandboxes is installed on your instance with assistance from your ServiceNow account team."). Note: Instances with vanity URLs support SSO. ## Developer Sandboxes workflow {#exploring-sandboxes__cf-exploring-parent-workflow} The delegated developer or admin of a sandbox would procure a sandbox, make changes or experiment with development, test their changes, push their changes, and wait for an admin to clone the instance. 1. A sandbox manager or admin allocates a sandbox to start story work. 2. The developer makes development changes and tests them out in their fully isolated sandbox. Note: The work done in one sandbox doesn't appear in other sandboxes or other instances. 3. Once the developer is content with their work and ready to promote their changes to a shared, integrated environment, they push their changes to the desired upstream shared instance. For example, a `test`/`QA` instance. There are two ways to promote changes: 1. Using source control (preferable) or exports through Git 2. Using update sets and imports (supported, but not as easy to merge changes) {#exploring-sandboxes__ol_o44_3sf_dgc} 4. Further testing can be done on the shared instance. 5. The admin of a sandbox instance clones changes from the `test`/`QA` instance to make those changes the default for all future allocated sandboxes. {#exploring-sandboxes__cf-exploring-parent-workflow-ol} ## Developer Sandboxes benefits {#exploring-sandboxes__cf-exploring-parent-benefits} {#exploring-sandboxes__table_fw5_sqm_bcc__entry__3} | Benefit | Feature | Users | |-|-|-| | Enable parallel development | Enable multiple developers the ability to work on different stories or features at the same time using the same starting source code, all while keeping the non-production baseline instance clean. | * Admins * Delegated developers {#exploring-sandboxes__ul_gqt_sjc_hgc} | | Reduce merge conflicts with source control | Enables integration with source control for more successful co-development. For more information, see [Source control and Developer Sandboxes](https://servicenow-prod.fluidtopics.net/y~WASxZ1VxWQrZAIauSFKQ "Use source control with Developer Sandboxes to enable parallel development and prevent merge conflicts."). | Delegated developers | | Reuse sandbox templates | Enables the optional setup of a repository configuration. You can create a template once, and reuse any existing templates when creating sandboxes. For more information, see [Using sandbox templates](https://servicenow-prod.fluidtopics.net/b~0CJ8CSuX68EkB024fE9A "Developer Sandboxes templates are being deprecated, and should no longer be used."). | * Admins * Delegated developers {#exploring-sandboxes__ul_n5h_zgc_hgc} | | Sandbox alias | Enables you to easily reference the sandbox you want to allocate. | * Admins * Delegated developers {#exploring-sandboxes__ul_nc3_w54_ghc} | | Allocate to | Enables you to allocate a sandbox to yourself, or for an admin to allocate a sandbox to someone else. | * Admins * Delegated developers {#exploring-sandboxes__ul_ibv_z54_ghc} | [Table 2. Developer Sandboxes benefits] {#exploring-sandboxes__table_fw5_sqm_bcc} ## What to explore next {#exploring-sandboxes__cf-exploring-parent-links} To learn more about installing and configuring Developer Sandboxes, refer to [Installing Developer Sandboxes](https://servicenow-prod.fluidtopics.net/s3m6zeKoFa29eyxCeSKi5g "Developer Sandboxes is installed on your instance with assistance from your ServiceNow account team.").