---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/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


---

# Metadata, tables, and records

# Developer Sandboxes and metadata {#ariaid-title1}

Release version: Australia  
Updated June 9, 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 Developer Sandboxes and metadata

Developer Sandboxes provide isolated environments within a ServiceNow instance, enabling developers to build and test in parallel without impacting the base instance or other sandboxes.
Each sandbox is initialized with the full metadata of the base instance, including scripts and business rules, but changes remain isolated until merged back into the base instance.
This isolation extends to user credentials and roles, ensuring sandbox-specific configurations do not affect others.
Show full answer Show less  

## Metadata Configuration

Each sandbox starts with a complete copy of the base instance's metadata. Changes such as activating plugins or modifying scripts in a sandbox do not affect the base instance until those changes are committed and merged by the Developer Sandboxes administrator. Once merged, changes become available for new sandboxes but do not retroactively apply to existing ones.

## Table Data Behavior

Table data in sandboxes is controlled by specific modes configured per table, affecting how data is shared or isolated:

* **Shared:** Default mode where table data is shared across the base instance and all sandboxes, with all record changes visible everywhere.
* **Full Copy:** Table data is fully copied to each sandbox at creation, with subsequent changes isolated to that sandbox.
* **Zero Copy:** No data is copied; sandboxes start empty and records remain isolated.
* **Partial Copy:** A filtered subset of data is copied; limited by cross-table references.

Schema changes to a table also isolate it, and records added afterward remain sandbox-specific. To change configurations on critical tables like Task or CMDB, customers must contact Now Support. Current configurations can be reviewed in `sysdsbtableconfig`. For generating synthetic test data within sandboxes, ServiceNow recommends using AI Data Kit.

## Business Rules

Business rules are part of the metadata copied from the base instance to sandboxes. They are visible and editable within sandboxes but remain isolated until merged. Users can access business rules under **All \> Administration \> Business rules** in their sandbox environment.  
Each sandbox provisioned with Developer Sandboxes is an isolated environment within an instance. Developers can build and test in parallel without affecting other work.
Sandboxes can be allocated to specific stories, developers, test plans, or any custom criteria.

## Developer Sandboxes and metadata configuration {#dev-sbx-metadata__section_mxq_zxd_hgc}

Each sandbox is initialized with the full metadata of the base instance. For example, the metadata includes scripts and business rules.

Any changes made to metadata configuration in the sandbox don't affect the base instance until changes are merged. For example, you can activate a plugin on a sandbox, and it isn't activated on the base instance. Sandboxes isolate
risky changes from the base instance and other sandboxes.

User credentials and roles are isolated to each sandbox. Changing a user's role in a sandbox doesn't affect other sandboxes or the base instance.

Any changes to metadata configuration must first be committed from the sandbox into the base instance. The Developer Sandboxes administrator must then merge the changes back into the base instance. The changes are then available for the next provisioned sandbox, but not for existing sandboxes.

## Developer Sandboxes and table data {#dev-sbx-metadata__section_vwv_dyd_hgc}

Table data behavior in sandboxes depends on how each table is configured. By default, tables use the Shared configuration. Tables that extend sys_metadata are configured as Full Copy.  
Each table in a sandbox instance can be configured with one of the following data modes:

Shared
:   The default configuration (introduced in the Zurich release). Table data is shared across the base instance and all sandboxes. All changes, additions, and deletions to records are visible across all sandboxes.

Full Copy
:   Table data is copied in full from the base instance to each sandbox at the time the sandbox is created. Sandboxes receive a snapshot of the data. All subsequent record changes are isolated to the sandbox.

Zero Copy
:   The table is isolated, but no data is copied from the base instance. Sandboxes start with no records in that table. All record changes are isolated to the sandbox.

Partial Copy
: Data is copied from the base instance based on a filter condition. This option has limited usability due to cross-table references.  
Note:  
To change the Task or CMDB tables, contact Now Support.

To view the current table configurations, view sys_dsb_table_config. Table configuration is set at the base or parent table for all inherited tables.

Records created in a sandbox on a Shared table are immediately available on the base instance and any other sandbox that shares that table. For isolated tables (Full Copy, Zero Copy, or Partial Copy), record changes remain isolated to that sandbox. Making a schema change also isolates the table, and any records added after that point are isolated.

To generate synthetic test data, use AI Data Kit. For more information, see [AI Data Kit](https://www.servicenow.com/docs/access?context=now-assist-data-kit-landing&version=australia&pubname=australia-intelligent-experiences&ft:locale=en-US).

## Developer Sandboxes and business rules {#dev-sbx-metadata__section_fy3_zyq_jgc}

Business rules are metadata inherited from the base instance. You can see business rules on a sandbox by navigating to AllAdministrationBusiness rules.

Business rules are copied, but isolated. For more information on Business rules, see [Classic Business rules](https://www.servicenow.com/docs/access?context=c_BusinessRules&version=australia&pubname=australia-api-reference&ft:locale=en-US).

*[\>]: and then