A Salesforce sandbox is a copy of your production org where you can build and test changes without touching live users or live data. The sandbox practices that pay off most are short: pick the type that fits the job, build and test in a sandbox before anything reaches production, plan each refresh, run a checklist after every refresh, and validate before you deploy.
This guide walks through each of those steps for admins who manage an org alone or with a small team. It covers the four sandbox types and what each one is for, how refreshes behave, the surprises that follow a refresh, a way to test changes the way users will meet them, and how to move a change to production. The Cirra AI page for Salesforce admins describes how Cirra AI fits into the same routine when you want an AI client to do some of the building.
What a sandbox copies and what it leaves behind
Every sandbox starts with a copy of your production metadata: objects, fields, page layouts, flows, validation rules, Apex and permission sets. Data is another matter, because how much arrives depends on the sandbox type. Salesforce's Help documentation also notes that customizations and data changes you make in production afterward are not reflected in your sandboxes, so a sandbox drifts from production the day you create it.
User records come along too. Salesforce's sandbox setup considerations state that user information is included in a sandbox copy or refresh for all sandbox types. Every refresh also gives the sandbox a new org ID, which matters for anything that identifies the sandbox by that ID.
Choose the right sandbox type
Salesforce offers four sandbox types. The table below summarizes the figures from Salesforce's sandbox licenses and storage limits page as of October 2026. Check that page before you plan around a number, because Salesforce can change limits.
| Sandbox type | Data copied | Storage | Refresh interval | Best used for |
|---|---|---|---|---|
| Developer | Metadata only | 200 MB data, 200 MB files | 1 day | Building and unit testing a change |
| Developer Pro | Metadata only | 1 GB data, 1 GB files | 1 day | QA and integration checks that need more records |
| Partial Copy | Metadata plus a sample of data chosen by a required sandbox template | 5 GB data, files match production | 5 days | User acceptance testing and training |
| Full | Metadata and all data | Matches production | 29 days | Staging, performance testing and load testing |
Which sandboxes you can create depends on your edition. According to the same Salesforce page, Enterprise Edition includes 25 Developer sandboxes and 1 Partial Copy sandbox, while Unlimited and Performance Editions include 100 Developer, 5 Developer Pro, 1 Partial Copy and 1 Full sandbox. Salesforce sells additional Developer Pro sandboxes for any edition, and additional Partial Copy and Full sandboxes for Enterprise, Unlimited and Performance. Metadata does not count against sandbox storage. When a sandbox reaches its data limit, Salesforce does not email you. You simply cannot save new data in it, so check Storage Usage in Setup before a big test load.
Give each sandbox one job
A sandbox with a single purpose stays predictable. A workable split for a small team looks like this: Developer sandboxes for building, a Developer Pro sandbox for QA and integration checks that need more records, a Partial Copy sandbox for user acceptance testing, and a Full sandbox when you need a staging area or a realistic data volume. Salesforce's own documentation says that only Full sandboxes support performance testing, load testing and staging, and that the long Full refresh interval makes them a poor place to develop.
A small team can run on one or two Developer sandboxes if it treats each as disposable: build one change set of work, deploy it, then refresh the sandbox so it matches production again. Give each sandbox a name that signals its job. Salesforce limits sandbox names to 10 characters and appends the name to usernames at login, so a short, consistent pattern such as DEV1, QA or UAT pays off. The same discipline applies to everything inside the sandbox, which is why a written naming standard belongs in your sandbox routine too.
Plan the refresh before you request it
A refresh brings the sandbox back in line with production. Per Salesforce's refresh documentation, refreshing updates the sandbox's metadata from the source org, so anything you built only in the sandbox and never deployed can be overwritten. Deploy or retrieve in-progress work first, and tell everyone who uses the sandbox before you click the button.
A few facts shape the schedule:
- The refresh interval is calculated from when you request the refresh, not when it finishes: 1 day for Developer and Developer Pro, 5 days for Partial Copy and 29 days for Full.
- Salesforce notes that copying less data significantly speeds up the copy, so use a sandbox template for Partial Copy and Full sandboxes and include only the objects you need.
- A refresh can move the sandbox to a different Salesforce instance.
- If you do not select Auto Activate, Salesforce emails you when the sandbox is ready to activate. It deletes new sandboxes that were not activated within 30 days.
Pick a refresh window that avoids user acceptance testing and release deadlines. Write the window down where the whole team can see it.
Run a post-refresh checklist
A refreshed sandbox is a copy of production with production's settings, and some of those settings are unsafe in a test environment. Work through the same list after every refresh, in this order:
- Confirm email behavior. Salesforce sets new and refreshed sandboxes to the System email only access level by default, which blocks routine email to your real users while still allowing system messages such as password resets. In Setup, search Quick Find for Deliverability to see or change it. Leave it restrictive unless a test needs outbound email.
- Fix user email addresses you need. Salesforce appends .invalid to user email addresses in a refreshed or cloned sandbox so that testers cannot trigger email to production addresses. Remove the suffix only for the users who need to receive test email.
- Repoint integrations. Replace production endpoints, named credentials and API keys with test values so that a sandbox flow or Apex job cannot write to a live external system.
- Check scheduled flows and scheduled Apex. Look in Setup for scheduled jobs and confirm that none points at a live external system or sends email you did not intend.
- Reload the test data and configuration records your tests depend on, since Developer and Developer Pro sandboxes carry metadata only.
- Protect any production data that did arrive. Partial Copy and Full sandboxes can hold real customer records, and Salesforce recommends multi-factor authentication for sandboxes with sensitive data. Salesforce also documents data masking products for this purpose.
- Record the refresh date and who refreshed it, so the next person knows how old the sandbox is.
Automate the checklist with SandboxPostCopy
Salesforce lets you run an Apex class automatically after every sandbox create or refresh. You write a class that implements the SandboxPostCopy interface and name it in the sandbox creation wizard. The interface has one method, runApexClass, which receives a SandboxContext with the organization ID, sandbox ID and sandbox name. The skeleton below follows the example in Salesforce's Apex reference. Put your own preparation logic where the comment sits.
global class PrepareMySandbox implements SandboxPostCopy {
global void runApexClass(SandboxContext context) {
System.debug('Org ID: ' + context.organizationId());
System.debug('Sandbox ID: ' + context.sandboxId());
System.debug('Sandbox Name: ' + context.sandboxName());
// Insert logic here to prepare the sandbox for use,
// for example resetting integration endpoints.
}
}Salesforce documents a test method for this interface, so the class can carry its own Apex test. Developers on your team or a partner can fill in the body. If you build it with an AI client, treat the code like any other Apex: review it and run its tests in a sandbox first.
Clone a prepared sandbox
If you need several sandboxes, finish the checklist once and then clone that sandbox. Per Salesforce's clone documentation, a cloned sandbox copies the source sandbox's data and metadata, uses the same license type as its source and needs the Manage Sandboxes permission, or Manage Dev Sandboxes for Developer and Developer Pro. Avoid making changes in the source sandbox while the clone runs.
Test changes the way users will meet them
Passing in the sandbox only means something if the test resembled real use. Four habits make it resemble real use.
Test as the user, not as yourself. A System Administrator can do almost anything, so a change that works for you tells you little. Log in as a user who holds the same profile and permission sets as the people who will use the change. Field-level security, page layouts and record types can differ from one profile or permission set to the next.
Test the edges of validation rules. Insert and update a record that should pass, one that should fail, and one that leaves the checked field blank. Run a data load and an integration update through the rule too, since a rule that blocks your integration user will fail quietly in production.
Test flows with more than one record. A record-triggered flow that works on a single edit can fail when a data load or an integration fires it on many records at once. Run the flow with a batch of records in the sandbox. The comparison of Apex and Flow covers the governor limits that shape that decision.
Test permission changes by comparing access. After you change a permission set, check what a sample user can and cannot see or edit before and after the change, and confirm that nothing was granted that you did not intend.
Write the tests down as a short list attached to the change request. A written list gives your reviewer and your future self something to repeat.
Move the change to production
SF Ben's 2026 Salesforce Admin Survey found that over 41% of respondents use Change Sets as their deployment method, so the following notes come from Salesforce's change set best practices. They apply in spirit to other deployment tools as well.
- Include every dependency that does not already exist in production. If a dependency is missing, the deployment fails. To move a custom object with its fields, add the object and each field.
- Add the profiles or permission sets that give users access to the new component. A new field that no profile or permission set exposes stays invisible to users.
- Validate the inbound change set in production before you deploy. Validation shows you the success or failure messages a real deployment would produce without deploying anything. Run it outside peak hours, because validation locks the components being deployed and the target org is locked for metadata changes during the deployment itself.
- Deploy, then repeat your test list in production with a real user's access.
- Refresh or update the sandbox so it matches production again.
Two limits catch people by surprise. Change sets cannot delete or rename components, so you do those by hand in the target org. And an uploaded change set cannot be edited: if you forget a dependency, clone the change set, add the component and upload it again.
If your change includes Apex, production adds requirements. Salesforce states that you need at least 75% of your Apex covered by unit tests to deploy to production, and its change set guidance says all local Apex tests run by default when you deploy Apex classes or triggers to production. Tests do not run automatically when the target is a sandbox, so a green sandbox deployment does not prove the coverage. The coverage rule applies to Apex. Flows and validation rules still need the testing described above.
Keep a record of what you changed. Setup Audit Trail shows recent setup changes and lets you download the setup history for the past 180 days, after which Salesforce deletes the records. A change request that lists the components, the test results and the deployment date covers the time before and after that window.
Where AI-assisted changes fit in a sandbox routine
The sandbox routine does not change when an AI client does some of the building. It matters more. Cirra AI runs as the Salesforce user who connected the org and can only do what that user is allowed to do. Even so, a change built from a plain-language request deserves the same review as one you clicked together yourself.
The practical approach is to connect a sandbox first, ask for the change there, and review the result with your test list. After that, deploy through your usual process. Cirra AI does not promote changes to production for you, so the validation and deployment steps above stay in your hands. Cirra AI also documents every change, which gives you the starting point for the change record described earlier.
Access settings apply per org as well. On the Salesforce Admin MCP Server product page, Cirra AI describes four data categories (Metadata, User Data, Personal Setup Data and Business Data) that you can set independently to None, Read Only, or Read and Write. For example, you can allow metadata changes in a sandbox connection while a production connection stays read-only for metadata. Cirra AI supports Salesforce Enterprise Edition and up, and the Free plan includes 100 credits so you can try this on a sandbox. The checklist for letting AI change your org lists five checks to run before you give any AI tool write access.
The code and the settings steps in this article follow Salesforce's documented syntax and Help pages. They were not run in a live org for this article, so test them in a sandbox before you rely on them. Ready to try it on a sandbox? Start Free Trial, or Learn More about how admins use Cirra AI.
Frequently asked questions
What are the four types of Salesforce sandboxes?
The four types are Developer, Developer Pro, Partial Copy and Full. Developer and Developer Pro copy metadata only, with Developer Pro offering more storage. Partial Copy adds a sample of production data chosen by a sandbox template. Full is a replica of production, including all data.
How often can I refresh a Salesforce sandbox?
Per Salesforce's documentation, you can refresh a Developer or Developer Pro sandbox once a day, a Partial Copy sandbox every 5 days and a Full sandbox every 29 days. The interval is calculated from when you request the refresh.
Does refreshing a sandbox delete my work?
A refresh updates the sandbox's metadata from the source org, so changes that exist only in the sandbox and were never deployed can be overwritten. Deploy or retrieve any work in progress before you request a refresh.
Why do my sandbox users have .invalid at the end of their email addresses?
Salesforce appends .invalid to user email addresses in a refreshed or cloned sandbox so that sandbox activity cannot send email to production addresses. Log in to the sandbox and correct the addresses of the users who need to receive test email.
How do I deploy changes from a sandbox to production?
Many admins use change sets. Build an outbound change set in the sandbox with every dependency and the permission sets that grant access, upload it to production, validate it, and then deploy it. Salesforce CLI and DevOps Center are other deployment options.
Can AI make Salesforce changes in a sandbox?
Yes. Cirra AI connects an AI client such as Claude, ChatGPT or Cursor to your Salesforce org through OAuth and makes changes as the connected user, within that user's permissions. Connect a sandbox first, review the result, and deploy to production through your usual process.
