Administration

Sandbox · testing changes in a copy of your organization

A sandbox is a complete, non-billable copy of an organization, created so you can experiment with objects, fields and automations without risk. When you are done, a change set lets you publish only what you choose to production. Creating and publishing are done by the SellioCRM team, not from the Settings screen.

Changing configuration straight in production is behind most of the scares: a deleted field an automation was using, an object created with the wrong name and already filled in by ten people. The sandbox exists so those experiments happen in a copy, and so only what worked comes back.

What a sandbox is

A new, separate organization, marked with the Sandbox badge, created from a production organization.
The copy includes the metadata, meaning objects, fields, automations and every other setting, plus the existing records.
It is born isolated. Thanks to per organization isolation, the sandbox never sees another organization data, and production never sees the sandbox data.
Sandboxes are not metered and are not billed.
The audit trail and the usage history of production are not copied: the copy starts with that history clean.

How a sandbox is created

Creating, deleting and publishing changes happen in the SellioCRM operations console, on the Sandbox tab of the organization. There is no button for it inside Settings: whoever administers your organization cannot create a sandbox on their own. Ask SellioCRM support when you need one.

The SellioCRM team opens the production organization in the console and goes to the Sandbox tab.
They click Create sandbox and wait for the copy. The screen reports how many rows were cloned.
A new organization appears with the Sandbox badge, carrying the same objects, fields, automations and records as the source.

Publishing changes to production

With the sandbox open in the console, the Sandbox tab shows the change set compared with the source production.
Each item shows up as an object, a field or an automation, with the status new, changed or removed.
Check the items you want and apply. Objects are applied before fields, because fields depend on them.
Items that could not be applied are listed with the reason, instead of failing silently.

Example: A manufacturer wants to reorganize its product catalog: three new fields, one rename and a stock alert automation. Everything is built and tested in the sandbox over two weeks. At publish time they choose to take the three new fields and the automation, and leave out the renamed field, which still raised doubts. Production receives exactly those four items.

What publishing moves and what it does not

It moves configuration: objects, fields and automations.
It does not move records. Contacts, deals and any other data created in the sandbox stay in the sandbox.
Nothing is deleted automatically in production. An item that exists only in production shows up as removed in the comparison, but keeps existing until someone deletes it by hand.
Applying is idempotent by name: publishing the same field twice updates it instead of duplicating it.

💡 Deleting a sandbox wipes all of its data and affects neither production nor your users. Because a sandbox holds a real copy of your data, treat access to it with the same care you give production.

Common questions

Can I create a sandbox myself from the Settings menu? No. The operation lives in the SellioCRM console.
Does the sandbox show up on my invoice? No. Sandboxes are neither metered nor billed.
Can I test integrations and email sending in the sandbox? It is a real organization; configure test credentials first, so you do not fire off messages to real customers from copied data.

Open this article inside the system →