General guidelines and use cases for Developer Sandboxes

  • Release version: Zurich
  • Updated August 7, 2025
  • 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 a temporary environment for development activities in ServiceNow. They are designed for individual use to maximize parallel development and can be stacked up to 30 sandboxes per instance without affecting performance. Users access sandboxes with the same credentials as the base instance, supporting Single Sign-On (SSO) except for instances with vanity URLs.

    Show full answer Show less

    Key Features

    • Single User Access: Each sandbox should be used by one user to maintain development efficiency.
    • Short-Lived Environments: Sandboxes should be transient, ideally lasting only as long as a sprint, story, or testing phase.
    • Branching Capabilities: Create new branches for bug fixes or feature testing, allowing for better version control and deployment.
    • Comparison with Non-Production Instances: Developer Sandboxes are temporary and not a substitute for more permanent non-production instances, which have long-term use cases.
    • Integration with ServiceNow Tools: Sandboxes work best with ServiceNow Fluent and IDE, with emphasis on using version control for managing changes.

    Key Outcomes

    By using Developer Sandboxes effectively, ServiceNow customers can enhance their development process through isolated and manageable environments, facilitating better code management and deployment strategies. They allow for a streamlined development workflow while ensuring that changes are documented and retrievable through version control systems.

    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 allow 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:
    SSO for sandboxes doesn't work on instances with vanity URLs.

    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.