General guidelines and use cases for Developer Sandboxes

  • Release version: Australia
  • Updated March 12, 2026
  • 3 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 General guidelines and use cases for Developer Sandboxes

    Developer Sandboxes provide temporary, isolated environments designed to support parallel development activities without impacting the base instance performance. Each sandbox is intended for use by a single developer and can be used concurrently with the base instance or other sandboxes using the same login credentials, including Single Sign-On (SSO) where supported. These sandboxes are best suited for short-term development cycles aligned with Agile practices, such as sprints, stories, or testing rounds.

    Show full answer Show less

    Key Guidelines

    • Single user per sandbox: Ensures effective parallel development and prevents conflicts.
    • Multiple sandboxes per instance: Up to 30 sandboxes can be stacked per instance without affecting performance.
    • Temporary usage: Sandboxes should be short-lived to maintain alignment with the base instance and avoid drift.
    • SSO integration: Sandboxes support SSO, leveraging the same authentication mechanisms as the base instance, including instances with vanity URLs.

    Use Cases

    • Create new branches for each sprint to isolate development work.
    • Use additional sandboxes to address urgent bug fixes during a sprint without disturbing ongoing work.
    • Test features or stories in dedicated sandboxes that can be retired after completion.

    Developer Sandboxes vs. Non-Production Instances

    Developer Sandboxes are designed for temporary, iterative development and testing, whereas non-production instances provide durable, long-term environments. Non-production instances are ideal for team or project-based partitioning and support long-term changes, while Developer Sandboxes focus on isolating developer metadata changes and supporting consistent development cadences in a temporary setting.

    Integration with ServiceNow Tools

    • Developer Sandboxes work best with ServiceNow Fluent and ServiceNow IDE to manage metadata changes as source code, improving version control and deployment processes.
    • Low-code changes saved as XML can cause merge conflicts; using ServiceNow Fluent’s domain-specific language offers a cleaner, more manageable approach.
    • Using Developer Sandboxes with ServiceNow IDE, version control systems like Git, and deployment tools such as App Engine Management Center facilitates streamlined development and deployment workflows.

    Additional Resources

    For practical implementation and troubleshooting, ServiceNow customers can refer to the official Developer Sandboxes installation guide and the ServiceNow Community article featuring FAQs and a Getting Started Guide.

    Follow some general guidelines to ensure you're optimizing your use of sandboxes.

    Number of Developer Sandboxes users

    Each sandbox should have only one person working in it. Multiple users per sandbox would negate the benefits of parallel development.

    Entitlements can be stacked, supporting up to 30 sandboxes per instance.
    Note:
    The number of sandboxes does not impact the instance performance.
    Users can be signed into the base instance and multiple sandboxes at the same time. 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.

    Timing for Developer Sandboxes

    Use Developer Sandboxes to create intentionally transient environments. The longer they last, the farther they get from the original base instance. Thus, Developer Sandboxes should be as short-lived as possible.

    Sandboxes are temporary and can be aligned to short development periods. For example, in Agile development, sandboxes can last as long as the following:
    1. A sprint
    2. A story
    3. A round of testing

    Examples of sandbox allocation

    The following are examples of how sandboxes can be used:
    • Create branches at the start of a sprint.
    • A new branch should be created for each sandbox.
    • If you need to fix a bug in the middle a sprint, instead of stashing changes, create a second sandbox with a new branch and fix the bug there. Then merge those changes into the release branch and deploy the bug fix to production.
    • Create a sandbox to test a story or feature by pulling in the changes to a new sandbox, which you will retire when the testing is complete.

    Developer Sandboxes vs. non-production instances

    Developer Sandboxes are not a replacement for non-production instances. Developer Sandboxes are intended to be temporary, while non-production instances are more permanent and intended for use long-term.

    The following table compares how non-production instances and Developer Sandboxes are most effectively used.
    Table 1. Comparing suggested non-production instances and Developer Sandboxes
    Non-production instances Developer Sandboxes
    Partition your company's work by team or project Isolate developer metadata changes within a project.
    Groups start from significantly different configurations All developers begin with the same baseline instance configuration.
    Concurrent workstreams are isolated or minimally aligned Development activities follow a consistent cadence.
    Durable environment for long-term changes Work can be completed in a temporary environment and committed to version control.
    For more information on setting up sandboxes on instances, see Installing Developer Sandboxes.

    Developer Sandboxes and ServiceNow Fluent

    Developer Sandboxes work best with ServiceNow Fluent and ServiceNow IDE.

    Low-code changes represented in XML markup sometimes cause merging issues, because the generated file structure can make it challenging to align changes. When using low-code builders on the ServiceNow AI Platform, the best long-term strategy is to save changes in ServiceNow Fluent instead of XML.

    ServiceNow Fluent is a domain-specific programming language that you can use to define application metadata in source code. Developers and admins can easily look up changes in version control, such as Git. For details, see ServiceNow Fluent.

    You can use Developer Sandboxes with System Update Sets, but a more forward-looking solution is to use ServiceNow IDE. Pairing your sandboxes and ServiceNow IDE with version control and deployment apps (such as App Engine Management Center) enables a cleaner, more streamlined deployment ecosystem. For more information, see ServiceNow IDE.

    Developer Sandboxes FAQs

    See the ServiceNow Community article on Developer Sandboxes: FAQ and Getting Started Guide.