Nobody Is Allowed To Change Production | Zoho CRM Sandbox And Change Control

Here's a question that sounds like IT and is really business. Who is allowed to change the system your revenue runs on?

In most mid-market Zoho estates the honest answer is: anyone with an Administrator profile, at any time, with no review and no way back. Not because someone decided that — because nobody decided anything.

Everything on screen is a mock demo of Zoho CRM with sample data.

Setup, Data Administration, Sandbox. A sandbox is a copy of your configuration you can break safely — build the change there, test it, then push it to production deliberately. Read what the screen says: a test environment to evaluate changes without affecting your production data.

And then look at the list. It's empty. There's one button, Create New Sandbox, and it has never been pressed.

Now, two different problems live on this screen, and which one you have depends on what you pay.

Sandbox is Enterprise and Ultimate only. Enterprise gets three configuration sandboxes and two that carry data. Ultimate gets seven and three, plus one full-data copy. Standard and Professional get none at all. Trials get two — which is exactly why a demo org makes this look ungated.

So on Professional the honest answer isn't "you should be using this." It's that the safe place to make a change doesn't exist in your account — a purchasing decision somebody should make deliberately rather than discover during an incident.

And if you are on Enterprise or Ultimate — look at the list. It's empty. There's one button, Create New Sandbox, and it has never been pressed.

Sit with what an empty list tells you. Every field ever added. Every workflow rule. Every layout change, every picklist value, every automation firing on your live pipeline right now — all built directly in production, on a working day, while people were using it.

Most of the time that's fine. The problem is that you find out which times weren't from a salesperson, on a Monday, after it already happened.

And the reasons stack up well beyond compliance. Security, because an untested change can quietly open something. Availability, because the change that takes the system down takes revenue with it. Quality — the bugs your customers find before you do. Scalability, because a change that works on ten records isn't always the one that works on a hundred thousand. Compliance sits alongside those and arrives with an auditor attached, so it gets the attention. It is rarely the biggest.

And it compounds in a way that matters. A change made directly in production leaves no record of what it replaced. The audit log will tell you that a rule was edited, and by whom — and for some objects it will show you the change itself. What it won't give you is the whole previous configuration, and it only holds three years. So when something breaks, the recovery path is often somebody's memory of how it worked last week, which is why these incidents take days to unpick rather than minutes.

A sandbox gives you a second copy to compare against — but be precise about what it is. It's a point-in-time snapshot. It does not track production; changes made in live after the copy arrive in the sandbox only when you rebuild it, and a full-data rebuild is once every thirty days, up to ten gigabytes. So a sandbox is a place to test the next change, not an archive of the last one.

Next to it, Copy Customization. This is the other half of the mechanism.

It moves configuration from one org to another deliberately, as a package, rather than by somebody rebuilding the same change twice by hand and getting it slightly different the second time.

Together these two screens are the whole apparatus: somewhere to build safely, and a controlled way to move what you built. Zoho shipped both. Almost nobody has wired them into how they actually work.

When a change does go wrong, this is where you find out what happened. Who did what, and when. It's genuinely useful and it is the wrong place to be living, because the audit log is how you investigate a change after it has already affected your business. It's a record, not a control.

A sandbox is the control. The audit log is what you use when you didn't have one.

Three rules, and they cost nothing to adopt.

One. Configuration changes get built in a sandbox, not production — and that applies to whoever is doing it, including us.

Two. Somebody named is accountable for what reaches production. Not a committee — one person who can say no.

Three. If a change did go straight to live, write it down the same day, while anyone remembers why.

Start with the population, because the risk is a headcount before it's a process. Open the Administrator profile — View Users, on the row menu — and look at who holds it. Every one of those people can change the configuration of your live system, right now, with no review step, and most of them were given it to unblock something unrelated.

That's not a criticism of anyone on that list. It's that a decision with permanent consequences is available to a group nobody deliberately chose.

And unlike a data mistake, a configuration mistake doesn't announce itself. Delete a record and somebody notices. Change a validation rule and things quietly stop being caught.

So what does a release actually look like when this is wired up properly. Somebody asks for a change. It gets built in the sandbox, where breaking it costs nothing. It gets tested against data shaped like yours. One named person looks at what's about to move and says yes or no. Then it's pushed, at a time somebody chose.

And a sandbox is only worth what it resembles. Mirror production as closely as you can afford — same configuration, same shapes of data. Where you can't, that's a tradeoff you make deliberately and write down, not one you discover afterwards when a change behaves differently in the real thing. A sandbox that looks nothing like production will happily pass a change production rejects.

One thing to be exact about, because it catches people out. What deploys is configuration. Records do not. Anything you type into a sandbox stays in the sandbox — you cannot push sandbox data to production. That is the correct design, and it means the sandbox is for testing how a change behaves, never for staging real data on its way in.

Four steps, none of them heavy, total cost measured in hours. Compare it to what most estates do: build it in production on a Thursday afternoon and find out on Monday.

None of this is really Zoho-specific. It's what we call tech ops — the operational discipline underneath a system rather than the features sitting on top of it. Change control is one piece. Security, availability, quality, scalability: the same discipline decides all of them, and compliance is the one that shows up with a deadline attached.

We run it as Managed Technical Operations, and this is what we mean by accountability rather than ownership — not taking your system off your hands, but committing to an outcome and absorbing the consequences of being wrong about it. For retainer clients that includes a project plan before a release, so you see the cost of a change before you approve it.

CodeStringers. Zoho authorized consulting partner, Santa Cruz.