Sandbox orgs
A sandbox is a second Zoho org attached to your billing account, so you can build and test an import somewhere that is not production without paying for a second subscription.
Available on Enterprise, and managed from the Billing tab of org settings. See Plans and limits.
What it inherits, and what it does not
Section titled “What it inherits, and what it does not”| Plan and features | Inherited from the production org. |
| Subscription and billing | The production org’s. A sandbox has none of its own. |
| AI credits | Spends the production org’s balance. |
| Row allowance | Metered on the sandbox’s own ledger. |
| Configuration, projects, history | Entirely its own. |
The split is deliberate. Features follow the plan you pay for, so a sandbox behaves like production. Rows are metered separately, so testing does not quietly consume the allowance you need for real work.
Attaching one
Section titled “Attaching one”Two people, two steps, in this order:
1. An administrator of the production org mints a link code. One-time, valid for 24 hours.
2. An administrator of the org that is to become the sandbox redeems it. They sign in to that org and enter the code.
The two-step handshake means neither org can be attached to a billing account without somebody with authority on both sides acting.
Which orgs are eligible
Section titled “Which orgs are eligible”Only an org that pays nothing of its own — Free or trialing.
An org with a live subscription keeps it; attempting to attach it is refused with
HAS_SUBSCRIPTION. That is the right behaviour: silently absorbing a paying org into somebody
else’s account would be a surprise about money.
A sandbox cannot have sandboxes of its own.
What a sandbox cannot do
Section titled “What a sandbox cannot do”Billing lives with the production org, so on a sandbox these are refused with SANDBOX_ORG:
- Start a checkout or open the Stripe portal
- Start a trial
- Buy credits or change automatic top-up
- Toggle row overage
A sandbox’s Billing tab names its production org instead of offering these — so an admin looking at the wrong org finds out immediately rather than wondering why nothing can be bought.
How many
Section titled “How many”The production org’s plan sets the allowance. Exceeding it is refused with LIMIT_SANDBOX, and the
message says how many the plan allows and how many are used.
The allowance is checked twice — when the code is minted and again when it is redeemed — because the second one could otherwise be minutes or hours later.
Detaching
Section titled “Detaching”An administrator of the production org detaches a sandbox.
The org survives. It simply pays for itself again, as Free, with its configuration, projects and history intact. Nothing is deleted.
Using one well
Section titled “Using one well”The point is a place where a mistake costs nothing:
- Build the mappings for an unfamiliar file against the sandbox first.
- Rehearse a large migration and read the run report before doing it for real.
- Try a match rule on real-shaped data without risking production records.
Since configuration is per-org, a project built in the sandbox does not automatically appear in production. Configuration as code is how you move a configuration between them deliberately — which is the right shape anyway, because it means the promotion is reviewed rather than remembered.