--- sourceDocument: Australia Build or modify applications sourceDocumentLink: https://www.servicenow.com/docs/r/australia/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 --- # Guidelines and use cases # General guidelines and use cases for Developer Sandboxes {#ariaid-title1} Release version: Australia Updated October 26, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 General guidelines and use cases for Developer Sandboxes Developer Sandboxes in ServiceNow provide temporary, isolated environments for individual developers to work on parallel development tasks without impacting the base instance or others' work. They are designed to support agile development practices by enabling short-lived, purpose-specific development and testing environments. Show full answer Show less ## Key Guidelines * **Single User per Sandbox:** Each sandbox is intended for use by one developer to maximize the benefits of parallel development. * **Entitlements and Capacity:** Up to 30 sandboxes can be supported per instance without affecting instance performance. * **Authentication:** Developers use the same login credentials as the base instance, with Single Sign-On (SSO) supported for seamless authentication. * **Short-lived Environments:** Sandboxes should be used as transient environments aligned with short development cycles such as sprints, stories, or testing rounds to maintain closeness to the base instance configuration. ## Use Cases * **Sprint-based Branches:** Create a new sandbox and branch at the start of each sprint to isolate work. For mid-sprint bug fixes, create a separate sandbox and branch to implement and test fixes before merging into the release branch. * **Feature or Story Testing:** Use sandboxes to pull changes for testing specific features or stories, and retire the sandbox after completion. ## Developer Sandboxes vs. Non-Production Instances Developer Sandboxes complement but do not replace non-production instances. Sandboxes are temporary and ideal for short-term, isolated development work, while non-production instances are durable environments for long-term use and team or project-based partitioning. | Non-production instances | Developer Sandboxes | |-|-| | Partition work by team or project | Isolate developer metadata changes within a project | | Groups start from different configurations | All developers start from the same baseline instance | | Support durable, long-term environment | Support temporary, short-term development aligned with version control | ## Integration with ServiceNow Tools * **ServiceNow Fluent and IDE:** Developer Sandboxes work best with ServiceNow Fluent, a domain-specific language for defining application metadata in source code, improving version control and merging compared to XML-based low-code changes. * **Version Control and Deployment:** Using sandboxes with ServiceNow IDE and deployment tools like App Engine Management Center provides a streamlined deployment workflow. * **System Update Sets:** While compatible, System Update Sets are less forward-looking compared to integration with ServiceNow IDE and Fluent. ## Next Steps For detailed setup and configuration, customers should reference the Developer Sandboxes installation and configuration documentation. Additionally, reviewing the ServiceNow Community's Developer Sandboxes FAQ and Getting Started Guide can provide practical insights and answer common questions. Follow some general guidelines to ensure you're optimizing your use of sandboxes. ## Number of Developer Sandboxes users {#dev-sbx-general-guidelines__section_iy3_yzd_hgc} 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), enabling it on the base instance also authenticates Developer Sandboxes using the same credentials. For information on enabling SSO, see [Single sign-on for Developer Sandboxes](https://www.servicenow.com/docs/1AMU7_VdIIoM6sK3CO6AEw "Sandboxes use the same login credentials as the base instance, including single sign-on (SSO) when it's enabled there. Set the required properties on the base instance so developers can use SSO to access sandboxes."). Note: Instances with vanity URLs support SSO. ## Timing for Developer Sandboxes {#dev-sbx-general-guidelines__section_x5h_qdz_fgc} 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 {#dev-sbx-general-guidelines__ol_hxp_tnz_fgc} ## Examples of sandbox allocation {#dev-sbx-general-guidelines__section_ah4_wmc_hgc} 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. {#dev-sbx-general-guidelines__ul_jsm_zmc_hgc} ## Developer Sandboxes vs. non-production instances {#dev-sbx-general-guidelines__section_slg_3hk_hgc} 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.{#dev-sbx-general-guidelines__table_g5c_53k_hgc__entry__2} | 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. | [Table 1. Comparing suggested non-production instances and Developer Sandboxes] {#dev-sbx-general-guidelines__table_g5c_53k_hgc}For more information on setting up sandboxes on instances, see [Developer Sandboxes installation and configuration](https://www.servicenow.com/docs/afqu_r8W_DwCSfNg_kj7vQ "Developer Sandboxes installation and configuration covers Developer Sandboxes on your instance. Review entitlements, install the plugins, and look up the roles, tables, and properties that control how sandboxes work."). ## Developer Sandboxes and ServiceNow Fluent {#dev-sbx-general-guidelines__section_vjv_2wk_hgc} 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](https://www.servicenow.com/docs/HcU~6LR5CHZuUX~roJ7chw "Define application metadata in source code using the ServiceNow Fluent domain-specific programming language."). 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](https://www.servicenow.com/docs/eMYyriIe_g3dvPLBokdLyg "Create and develop applications in source code in an integrated development environment (IDE) on the ServiceNow AI Platform to improve collaboration across development teams and accelerate application development."). ## Developer Sandboxes FAQs {#dev-sbx-general-guidelines__section_pv3_mrl_khc} See the ServiceNow Community article on [Developer Sandboxes: FAQ and Getting Started Guide](https://www.servicenow.com/community/app-engine-blog/developer-sandboxes-faq-and-getting-started-guide/ba-p/3433961).