Build / Sandbox
Change software with confidence.
Build and test changes in a separate Sandbox organization, review exactly what will change, and apply only the approved operations to your live workspace.
Experiment separately. Apply deliberately.
Sandbox separates application work from production while keeping every proposed change reviewable. You can explore an idea, use prompts to shape the result, and decide exactly what should move back to the parent organization.
The Sandbox model
A separate organization connected to your live workspace.
A Sandbox is a separate organization with a parent organization relationship. Its configuration is provisioned from the parent so you can work with the same structural foundation while keeping proposed changes outside the live environment.
Configuration, not a live-data clone.
Sandbox provisioning copies table definitions, fields, and relations from the parent organization. Use the Sandbox to develop and review configuration changes; do not treat it as automatic live-data synchronization.
What is available in Sandbox
Start with the same structural foundation.
The Sandbox gives your team the platform structure required to build and test application changes.
Table definitions
Work with the application tables and their configuration in a separate organization.
Fields
Add, update, organize, and review the fields that shape the data model.
Relations
Test how business records connect before the relationship changes reach the parent organization.
Prompt-driven changes
Use prompts and application tools to build changes, then prepare them for review as a patch.
The safe change loop
Prepare, review, approve, apply.
Every change follows a deliberate path from the Sandbox to the parent organization.
1. Build in Sandbox
Create or modify the application without immediately changing the live organization.
2. Prepare the diff
Compare the Sandbox configuration with the parent organization and generate a patch.
3. Review operations
Inspect the proposed creates, updates, deletes, and field-level differences.
4. Apply the decision
Approve the selected operations, then apply the approved patch asynchronously.
Operation-level review
A patch is not one opaque change.
Sandbox breaks a proposed change into individual operations so your team can decide what should move forward.
Create
Review resources that exist in the Sandbox but not yet in the parent organization.
Update
Compare the previous and proposed values for an existing resource.
Delete
Identify resources that would be removed or deactivated in the parent organization.
Field-level diff
Inspect the old and new values, review each operation, and approve or reject it independently.
Patch lifecycle
Know where every change stands.
Patches move through explicit states so your team can understand what is happening and what action is available next.
Preparing
The system is comparing the Sandbox and parent organization.
Ready for review
The diff is available and operations can be inspected.
Approved or applying
The selected operations have been approved and the apply job is running.
Completed, failed, or conflicted
Review the final status, applied count, and any error details before trying again.
Patch history can also include obsolete or cancelled patches as part of the change record.
Permissions and control
Not everyone can publish a change.
Collaborators can work in the Sandbox, but approval and application are controlled at the parent organization. Active owners, admins, and super admins can approve patches and apply approved changes.
Approval requires context.
Before approval, provide a patch name, commit message, and optional approval notes. This creates a useful record of what the change is intended to do and why it was accepted.
Example
Move a prompt-built CRM improvement safely.
“Add a lead priority field, update the CRM form, and notify the owner.”
Build the change in Sandbox, compare it with the parent organization, and select only the operations that are ready to move into the live workspace.
Build
Use prompts and application tools to create the field, form change, and notification behavior in Sandbox.
Inspect
Review the generated operations and compare the old and new configuration.
Select
Approve the safe changes and reject anything that needs more work.
Apply
Apply the approved patch to the parent organization and monitor completion.
Patch history
Keep the reasoning behind every release.
Patch history records names, commit messages, approval notes, approved users, timestamps, operation counts, applied counts, errors, and completion details. Previous patches remain available so your team can understand how the workspace changed over time.