Exploring Developer Sandboxes

  • Release version: Australia
  • Updated March 12, 2026
  • 4 minutes to read
  • Summarize
    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 provide isolated, on-demand development environments that enable multiple developers to build and test in parallel on a shared base instance without interfering with each other’s work. These sandboxes contain the full metadata of the base instance and help reduce code conflicts, accelerate delivery, and support safe testing of configurations, workflows, and integrations. They are designed to improve development agility by allowing concurrent workstreams, which is especially valuable when handling urgent defects and critical feature enhancements simultaneously.

    Show full answer Show less

    Key Features

    • Isolation: Each developer works in an independent sandbox, ensuring no impact on others’ work.
    • Faster Delivery: Parallel development reduces cycle times and accelerates fix and feature rollout.
    • Safe Testing: Sandboxes allow thorough testing without risking system stability.
    • On-Demand Provisioning: Sandboxes can be quickly created and assigned to specific stories, developers, or test plans.
    • Integration with Source Control: Supports Git integration to manage merges and reduce conflicts during parallel development.
    • Sandbox Management Dashboard: Provides visibility into sandbox status, usage, ownership, and allocation.
    • Sandbox Lifecycle Roles: Supports roles like delegated developers, admins, and sandbox managers with tailored permissions for requesting, allocating, and managing sandboxes.
    • Reuse of Sandbox Templates: Enables creating and applying configuration templates to streamline sandbox creation.

    Important Considerations

    • Developer Sandboxes are retired automatically after upgrades or clones; ensure work is preserved by using remote update sets or manual export/import before these operations.
    • Build Agent is not yet supported within Developer Sandboxes.
    • Single Sign-On (SSO) is supported and uses the same authentication as the base instance, including for instances with vanity URLs.
    • While Personal Development Instances (PDIs) remain available, they lack the controlled baseline that Developer Sandboxes provide.

    Recommended Workflow

    1. An admin or delegated developer allocates a sandbox for story work.
    2. The developer performs changes and tests them fully isolated in the sandbox.
    3. Once ready, changes are promoted to a shared test or QA instance, preferably through source control integration with Git, or alternatively via update sets.
    4. The sandbox admin then clones changes from the shared instance to update the baseline for future sandboxes.

    Benefits for ServiceNow Customers

    • Enables parallel development: Multiple developers can safely work on different features or fixes simultaneously.
    • Reduces merge conflicts: Source control integration helps streamline co-development and merging.
    • Improves sandbox management: Role-based access and templates simplify sandbox allocation and reuse.
    • Keeps non-production baseline clean: Maintains a stable, controlled environment for ongoing development.

    Next Steps

    To implement Developer Sandboxes effectively, review entitlement access and explore installation and configuration guidance. Ensure your team understands sandbox lifecycle management, source control integration, and upgrade/cloning best practices to maximize productivity and minimize risks.

    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 architecture and workflow. For the text description, refer to the following sections.
    • 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.

    Developer Sandboxes 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.
    Note:
    Personal Development Instances (PDIs) are still available, but they don't have a controlled baseline configuration like Developer Sandboxes do.

    Sandbox Management home dashboard.

    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.

    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.

    Note:
    Build Agent it not yet supported in Developer Sandboxes.

    Integrate sandboxes with source control

    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.

    Developer Sandboxes users

    Table 1. Users
    User Description
    Delegated developers Delegated developers can request, allocate, or retire sandboxes.
    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.
    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.
    Note:
    Instances with vanity URLs support SSO.

    Developer Sandboxes 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 Developer Sandboxes user (either admin or dev) 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)
    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.

    Developer Sandboxes benefits

    Table 2. Developer Sandboxes benefits
    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
    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. 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.
    • Admins
    • Delegated developers
    Sandbox alias Enables you to easily reference the sandbox you want to allocate.
    • Admins
    • Delegated developers
    Allocate to Enables you to allocate a sandbox to yourself, or for an admin to allocate a sandbox to someone else.
    • Admins
    • Delegated developers