Exploring Developer Sandboxes
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.
[Omitted image "dev-sbx-infographic1-updated.png"] Alt text: 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.
[Omitted image "sandboxes-management-home.png"] Alt text: 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.
Build Agent is supported in Developer Sandboxes. For more information, see Build Agent.
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
| User | Description |
|---|---|
| Sandbox license admins | Sandbox license admins can assign purchased sandbox packs to non-production instances from App Engine Management Center (AEMC). |
| 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. |
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.
Note: Instances with vanity URLs support SSO.
Developer Sandboxes workflow
The delegated developer or admin of a sandbox procures a sandbox, makes changes or experiments with development, tests their changes, pushes their changes, and waits for an admin to clone the instance.
-
A sandbox manager or admin allocates a sandbox to start story work.
-
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.
-
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/QAinstance. There are two ways to promote changes:- Using source control (preferable) or exports through Git
- Using update sets and imports. Update set sources between the sandbox and the base instance are automatically created when the sandbox is ready. For more information, see Update sets transfer between sandboxes and base instance.
-
Further testing can be done on the shared instance.
-
The admin of a sandbox instance clones changes from the
test/QAinstance to make those changes the default for all future allocated sandboxes.
Developer Sandboxes benefits
|
Benefit |
Feature |
Users |
|---|---|---|
|
Enable parallel development |
Enable multiple developers 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. |
|
|
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, sandbox managers |
|
Self-serve license assignment |
Assign purchased sandbox packs to non-production instances directly from App Engine Management Center (AEMC), without opening a support case. For more information, see License assignment. |
Sandbox license admins |
|
Pooling for faster allocation |
When allocating a sandbox, a sandbox is claimed from a pre-created pool rather than waiting for a new instance to be provisioned. The pre-created pool helps users start working in sandboxes faster. |
|
|
Sandbox alias |
Reference name for the sandbox you want to allocate. |
|
|
Allocate to |
Enables you to allocate a sandbox to yourself, or for an admin to allocate a sandbox to someone else. |
|
To learn more about installing and configuring Developer Sandboxes, refer to Developer Sandboxes installation and configuration.
- Supported ServiceNow AI Platform features in Developer Sandboxes
Developer Sandboxes supports almost all development-related ServiceNow AI Platform features. - Source control and Developer Sandboxes
Use source control with Developer Sandboxes to enable parallel development and help avoid merge conflicts. - Update sets transfer between sandboxes and base instance
When a sandbox is ready, update set sources are automatically created on both the sandbox and the base instance, enabling transfers in either direction without manual configuration. - Developer Sandboxes and metadata
Each sandbox provisioned with Developer Sandboxes is an isolated environment within an instance. Developers can build and test in parallel without affecting other work. - General guidelines and use cases for Developer Sandboxes
Follow some general guidelines to ensure you're optimizing your use of sandboxes. - Get help with Developer Sandboxes
To get help with Developer Sandboxes, your ServiceNow instance, plugins, permissions, and more, watch a short video to contact the ServiceNow admin who works in your company. You can also check some helpful resources.
Parent Topic:Developer Sandboxes
---
title: Exploring Developer Sandboxes
description: 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.
locale: en-US
canonical_url: https://www.servicenow.com/docs/r/australia/application-development/developer-sandboxes/exploring-sandboxes.html
release: australia
product: Developer Sandboxes
classification: developer-sandboxes
topic_type: concept
last_updated: "2026-10-26"
reading_time_minutes: 7
keywords: [developer sandbox, sandbox developer, servicenow sandbox enabled, development sandbox, dev sandbox, sandbox management, sandbox enabled servicenow, sandbox crm]
breadcrumb: [Developer Sandboxes, Build, AI Workflow Factory Prime, Agentic app development, Building applications]
---
# Exploring Developer Sandboxes
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.
\[Omitted image "dev-sbx-infographic1-updated.png"\] Alt text: 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.
\[Omitted image "sandboxes-management-home.png"\] Alt text: 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sbx-entitlements.md).
**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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sbx-clone-upgrade-info.md).
Build Agent is supported in Developer Sandboxes. For more information, see [Build Agent](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/build-agent.md).
## 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sandboxes-source-control.md).
## Developer Sandboxes users
|User|Description|
|----|-----------|
|Sandbox license admins|Sandbox license admins can assign purchased sandbox packs to non-production instances from App Engine Management Center \(AEMC\).|
|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.|
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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sbx-sso.md).
**Note:** Instances with vanity URLs support SSO.
## Developer Sandboxes workflow
The delegated developer or admin of a sandbox procures a sandbox, makes changes or experiments with development, tests their changes, pushes their changes, and waits 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. Update set sources between the sandbox and the base instance are automatically created when the sandbox is ready. For more information, see [Update sets transfer between sandboxes and base instance](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dsb-update-sets.md).
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 id="table_fw5_sqm_bcc"><thead><tr><th>
Benefit
</th><th>
Feature
</th><th>
Users
</th></tr></thead><tbody><tr><td>
Enable parallel development
</td><td>
Enable multiple developers 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.
</td><td>
- Admins
- Delegated developers
- Sandbox managers
</td></tr><tr><td>
Reduce merge conflicts with source control
</td><td>
Enables integration with source control for more successful co-development. For more information, see [Source control and Developer Sandboxes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sandboxes-source-control.md).
</td><td>
Delegated developers, sandbox managers
</td></tr><tr><td>
Self-serve license assignment
</td><td>
Assign purchased sandbox packs to non-production instances directly from App Engine Management Center \(AEMC\), without opening a support case. For more information, see [License assignment](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dsb-license-allocation-about.md).
</td><td>
Sandbox license admins
</td></tr><tr><td>
Pooling for faster allocation
</td><td>
When allocating a sandbox, a sandbox is claimed from a pre-created pool rather than waiting for a new instance to be provisioned. The pre-created pool helps users start working in sandboxes faster.
</td><td>
- Admins
- Delegated developers
- Sandbox managers
</td></tr><tr><td>
Sandbox alias
</td><td>
Reference name for the sandbox you want to allocate.
</td><td>
- Admins
- Delegated developers
- Sandbox managers
</td></tr><tr><td>
Allocate to
</td><td>
Enables you to allocate a sandbox to yourself, or for an admin to allocate a sandbox to someone else.
</td><td>
- Admins
- Delegated developers
- Sandbox managers
</td></tr></tbody>
</table>## What to explore next
To learn more about installing and configuring Developer Sandboxes, refer to [Developer Sandboxes installation and configuration](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dsb-configuring-landing.md).
- **[Supported ServiceNow AI Platform features in Developer Sandboxes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sbx-supported-features.md)**
Developer Sandboxes supports almost all development-related ServiceNow AI Platform features.
- **[Source control and Developer Sandboxes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sandboxes-source-control.md)**
Use source control with Developer Sandboxes to enable parallel development and help avoid merge conflicts.
- **[Update sets transfer between sandboxes and base instance](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dsb-update-sets.md)**
When a sandbox is ready, update set sources are automatically created on both the sandbox and the base instance, enabling transfers in either direction without manual configuration.
- **[Developer Sandboxes and metadata](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sbx-metadata.md)**
Each sandbox provisioned with Developer Sandboxes is an isolated environment within an instance. Developers can build and test in parallel without affecting other work.
- **[General guidelines and use cases for Developer Sandboxes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sbx-general-guidelines.md)**
Follow some general guidelines to ensure you're optimizing your use of sandboxes.
- **[Get help with Developer Sandboxes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/dev-sbx-get-help.md)**
To get help with Developer Sandboxes, your ServiceNow instance, plugins, permissions, and more, watch a short video to contact the ServiceNow admin who works in your company. You can also check some helpful resources.
**Parent Topic:**[Developer Sandboxes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-development/developer-sandboxes/sandboxes-landing.md)
| title | Exploring Developer Sandboxes |
| description | 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. |
| locale | en-US |
| canonical_url | https://www.servicenow.com/docs/r/australia/application-development/developer-sandboxes/exploring-sandboxes.html |
| release | australia |
| product | Developer Sandboxes |
| classification | developer-sandboxes |
| topic_type | concept |
| last_updated | 2026-10-26 |
| reading_time_minutes | 7 |
| keywords | developer sandboxsandbox developerservicenow sandbox enableddevelopment sandboxdev sandboxsandbox managementsandbox enabled servicenowsandbox crm |
| breadcrumb | Developer SandboxesBuildAI Workflow Factory PrimeAgentic app developmentBuilding applications |