CRMown Docs
Docs › Enterprise

Sandbox Environments — Test Changes Before Production

Sandboxes are isolated copies of your org you can use to safely test workflow tweaks, new approval processes, CPQ price rules, email template rewrites, and configuration changes without touching production. Each sandbox clones all of your configuration plus a bounded sample of recent data (last 90 days of contacts capped at 500, pipeline items capped at 200) with PII redacted. When you're happy with your changes you select what to promote and CRMown applies just those changes to the parent org. Plan-gated to Max (1 sandbox) and Own license (3 sandboxes).

Open in CRMown →

Steps

  1. Go to Enterprise > Sandbox (the 🧪 Sandbox tab under the Enterprise suite). Only OWNER and ADMIN see this tab — TEAM/EXECUTIVE/VIEWER don't have sandbox permissions.
  2. Click "Create sandbox", name it something descriptive ("Q4 workflow testing", "approval-process-rewrite"), and click Create. The clone job runs in the background — typically 30-120 seconds for a typical org. Status flips from "creating" to "ready" when done.
  3. Click "Enter sandbox" on a ready sandbox. The whole dashboard takes on an amber tint, the favicon swaps to 🧪, the browser tab title gets a [SANDBOX] prefix, and a banner across the top reads "🧪 SANDBOX — <name> · Changes here will not affect production until promoted." This is unmissable on purpose — path-based routing means the URL doesn't change much.
  4. Make whatever changes you want inside the sandbox: edit workflows, tweak approval processes, modify CPQ price rules, adjust email templates, etc. Every change happens against the sandbox's cloned data, not your real production data.
  5. When ready, exit the sandbox (click "Exit sandbox" in the banner) and go back to Enterprise > Sandbox > <your sandbox> > Changes tab. CRMown computes a diff between your sandbox and production and shows every modified, added, or deleted entity with its before/after state.
  6. Uncheck anything you don't want to promote (e.g., "this workflow change was just for testing"), then click "Promote selected". A promotion job runs server-side and applies just the selected changes back to production. Promotion status streams live; partial failures are tolerated and surfaced.
  7. Use the "Intercepted emails" tab to see every email your sandbox tried to send — outgoing email is hard-disabled in sandboxes (nothing reaches Resend, customers won't see test emails) and instead captured to this log so you can verify your workflows generated the right content.

Good to know

  • Sandboxes auto-expire after 30 days. Click "Extend +30d" to push the expiration out another month, capped at 180 days total lifetime from creation. Past 180 days the sandbox hard-deletes — a 7-day warning email goes to the creator before that happens.
  • Sandbox AI calls (e.g., AI Bar, AI Draft, agents) count against your PRODUCTION org's AI quota — not the sandbox's. This prevents people from spinning up sandboxes to bypass the AI cap.
  • PII redaction: in cloned data, contact emails become "ab***@sandbox.local" and phone numbers get x'd out except the last 4 digits. First/last names are kept (they're useful for testing UX, low-sensitivity). Conversations, activity logs, and full message history are NOT cloned — only the bounded contact + pipeline-item sample.
  • Owner of the sandbox session matters: you must be ADMIN/OWNER on the parent org to enter a sandbox. The auth middleware verifies this every request — there's no "borrow access" path. (Internally we use a token-swap pattern: req.currentUser.orgId stays your home org while req.effectiveOrgId points at the sandbox for data scoping.)
  • The diff workflow covers seven entity types: Workflows, Pipelines (+ stages + custom fields), Approval Processes (+ steps), CPQ Products, CPQ Price Rules, Email Templates, and Custom Roles. Other entity types (contacts, deals, conversations) intentionally don't flow back — sandboxes are for testing CONFIGURATION, not bulk-editing real data.
  • Cloned files (recordings, documents) reference the parent's R2 storage directly with a read-only flag — no deep copy. New files uploaded inside the sandbox land in a separate "sandbox-<sandboxOrgId>/" namespace and are cleaned up on sandbox delete. Your parent's file storage is never modified.
  • Path-based routing in v1: sandbox sessions don't use a separate subdomain. The X-Sandbox-Id header (set by the frontend when you click "Enter sandbox") tells the API which sandbox you're in. Subdomain-based routing (q4-test.sandbox.app.crmown.io) is a v1.5 feature if customers ask.
Example: A 12-person SaaS team wants to roll out a tighter approval policy: any deal over $10k needs CRO sign-off. The RevOps lead creates a sandbox "approval-tightening", enters it, builds the new ApprovalProcess with a 2-step chain (RevOps lead → CRO), tweaks a few related workflow steps so deals at risk auto-tag, and tests by submitting a few sandbox-cloned deals through the flow. Once the diff looks right (3 changes — 1 new approval process, 2 modified workflows) she clicks Promote selected. The CRO sees the new process appear in production within a minute, no surprise downtime, no broken deals.

Troubleshooting

"Sandboxes are available on Max plan / Own license" upsell
Free / Starter / Pro orgs don't include sandboxes — they're a Max-tier feature (1 active) or Own license (3 active).
Fix: Settings > Billing > upgrade to Max (or buy an Own license). The capability is on as soon as the plan flips.
"Cannot create a sandbox from within a sandbox"
You're currently inside a sandbox session and tried to create another one. Sandboxes can only be created from the parent org.
Fix: Click "Exit sandbox" in the top banner first, then create the new sandbox from your parent org's Enterprise > Sandbox tab.
Test email I sent from the sandbox actually reached the customer
This shouldn't happen — every email pathway routes through lib/ses.ts which checks org.isSandbox. If you saw a real outbound email, it likely came from a code path that wasn't passing orgId to sendEmail (a bug).
Fix: Report the workflow / route that sent the email to support@crmown.com with the sandbox id. We'll patch the missing orgId thread-through. As a defensive measure, the sandbox's cloned contacts have doNotContact=true and consent flags off — so any properly-gated workflow would refuse to send.
Promote action did nothing / "0 changes detected"
Either you didn't actually edit anything inside the sandbox, or the changes you made are in entity types not covered by promote (only the 7 cloneable types flow back).
Fix: Confirm your changes were inside Workflows, Pipelines, Approval Processes, CPQ Products, CPQ Price Rules, Email Templates, or Custom Roles — these are the types the diff service tracks. Other things (contacts, deals, etc.) intentionally don't flow back.
Promotion shows status "partial"
Some changes applied successfully and others failed (typical cause: sandbox referenced a new entity that no longer exists in parent, or a delete was attempted on a CustomRole that has users assigned to it).
Fix: Open the promotion row to see per-change errors. Fix the underlying issue in the sandbox and re-run promote selecting just the failed changes.
Cannot extend sandbox past 180 days
Hard cap on sandbox lifetime — extensions cumulate but can't push expiresAt past maxLifetimeAt.
Fix: If you still need testing capacity, delete the old sandbox and create a fresh one. The new one starts the 30-day / 180-day clocks over.
Sandbox UI looks normal — no amber tint or banner
Either you're not actually in a sandbox session (URL or store state didn't hydrate), or browser cached an older bundle without SandboxChrome.
Fix: Click "Exit sandbox" then "Enter sandbox" again. If it still doesn't tint, hard-refresh the page (Cmd+Shift+R / Ctrl+Shift+R). If still missing, raise a bug — the visual cues are critical safety UX and shouldn't fail silently.

Error messages

  • quota_exceeded — You've hit your plan's sandbox cap (Max: 1, Own: 3). Delete an existing sandbox to free a slot, or upgrade to Own.
  • sandbox_not_ready — The sandbox is still cloning, has failed, or has expired. Check the status in Enterprise > Sandbox before retrying.
  • sandbox_forbidden — The sandboxId in your X-Sandbox-Id header points at a sandbox owned by a different org. Cross-org sandbox access is blocked by design.
  • sandbox_role_denied — Only ADMIN and EXECUTIVE roles can enter sandboxes. Ask an OWNER to upgrade your role or impersonate.
  • lifetime_cap_reached — Sandbox is at its 180-day maximum lifetime. Extensions cannot push past this; create a fresh sandbox if you still need testing capacity.
  • custom_role_delete_not_supported — Promoting a CustomRole deletion is refused — would orphan users assigned that role. Reassign users to a different role first, then delete.

Plans

Max plan: 1 active sandbox. Own license: 3 active sandboxes. Free / Starter / Pro: not available — upgrade to access. Sandbox-management endpoints require sandbox:admin permission (OWNER, ADMIN). Entering a sandbox requires sandbox:read (OWNER, ADMIN, EXECUTIVE).

Related

  • Approval & Review Process — sandbox is a great place to test new approval chains before promoting them to production
  • CPQ — try out new pricing rules / product catalog tweaks against real-shaped quote data
  • Workflows — test trigger / step changes against bounded sample data without risking real customer touchpoints
  • AI Usage — sandbox AI calls count against the parent org's quota, not a separate sandbox quota
  • Settings > Billing — plan tier determines sandbox quota

View as Markdown