Salesforce Sandbox
Term 149 of 175 · Technology
In one sentence
A Salesforce sandbox is an isolated copy of your production org where you can develop, configure and test changes without affecting real users or live data, before promoting those changes to production in a controlled way.
Reviewed by Juan Manuel Garrido
Co-founder of VantegrateLinkedIn
Salesforce Sandbox definition
A Salesforce sandbox is an environment separate from your production org, used to develop, configure and test changes without touching the system your teams use every day. It is a replica of your org (its metadata and, depending on the type, its data too) that lives on a different instance, with its own URL and its own users, so any mistake or experiment stays contained and isolated from the real environment.
The underlying idea is simple: you never work directly in production. You test first in a sandbox, confirm everything works, and only then promote those changes to production. That is why the sandbox is the centerpiece of the implementation cycle and of the work of any team doing development on Salesforce.
Each sandbox is created from production and can be refreshed (the current state of production is copied over it again) when it falls out of date with the real environment.
Why it matters
In Salesforce there is no such thing as "I'll just test it quickly in production". Production is the system where your sales team logs opportunities, your service team answers cases and your integrations move real data. Changing that environment blindly is a recipe for breaking processes, losing information or leaving people unable to work. The sandbox gives you an identical place to make mistakes without consequences, iterate as many times as you need and validate calmly before affecting anyone.
How it works
A sandbox is provisioned from Setup, inside your production org, and Salesforce generates a copy on a separate instance. Depending on the type, that copy includes only the metadata (the configuration: objects, fields, flows, code, profiles) or a portion of the real data as well. Each sandbox has its own login domain, different from production's, and user credentials are copied with the sandbox name appended to the end of the username. When you want to move the changes to production, you use deployment tools such as change sets, packages or Salesforce DX to promote that metadata in a controlled way.
Sandbox types
Not all sandboxes are the same: they differ in how much data they copy, how much storage they have and how often they can be refreshed. Choosing the right type is key to not overpaying or ending up short of data to test with.
| Type | What it copies | Refresh | Typical use |
|---|---|---|---|
| Developer | Metadata only | Every 1 day | Individual development, quick tests |
| Developer Pro | Metadata only (more storage) | Every 1 day | Development with a larger volume of test data |
| Partial Copy | Metadata + a sample of data | Every 5 days | QA and testing with representative data |
| Full | Metadata + all data | Every 29 days | UAT, staging and realistic performance testing |
A Full sandbox is the most faithful replica (it copies the entire database), so it is reserved for user acceptance testing and performance validation; Developer sandboxes are light and fast, ideal for a developer's day-to-day work.
A concrete example (Latin America)
Picture a consumer goods distributor in Argentina that needs to change the logic of its sales forecast and add a new validation rule on opportunities. The team builds everything in a Developer sandbox, tests it against dummy data, moves it to a Partial Copy so the sales team can validate it with data close to the real thing, and only once everyone signs off is it deployed to production. If something had failed, the problem would have stayed contained in the sandbox and nobody in sales would have noticed.
Common mistakes
- Developing directly in production because "it's just one small field": any untested change can break automations that depend on it.
- Not refreshing the sandbox for months: it ends up so out of date with production that the tests are no longer reliable.
- Forgetting that emails and integrations are disabled by default in a new sandbox: if you turn them on without thinking, you can send test emails to real customers.
- Testing performance in a Developer sandbox: since it has almost no data, it does not represent the real load. That is what a Full sandbox is for.
How it differs from a Developer Edition org
This is a classic mix-up. A sandbox is always a copy of your production org and is tied to it: it is refreshed from there and inherits its license. A Developer Edition org is a free, standalone org, unrelated to your production, used to learn or to build packages for the AppExchange. If you want to test your own real configuration, you go to a sandbox; if you want a clean environment detached from your company, you go to a Developer Edition.
In short, the sandbox is the safety net for all technical work in Salesforce: the place where changes mature before they touch the business.
A bank changing its approval flow
A mid-sized bank in Bogotá wants to change its loan approval flow. Instead of touching production late at night and nervously, the team clones the configuration into a Full sandbox, tests the flow with realistic data, runs the tests and trains three users. When everything works, it deploys to production with confidence, and the cost of any mistake stays contained in the sandbox.
An integration tested in Partial Copy
A logistics company needs to connect Salesforce to its billing system. It uses a Partial Copy, which brings in a realistic subset of accounts and orders, to verify that the integration maps the data correctly without exposing the full database. It adjusts the fields, validates the edge cases and only then moves the connection to production.
FAQs about Salesforce Sandbox
What is a sandbox in Salesforce?
What is a sandbox in Salesforce?
A sandbox in Salesforce is an isolated environment, separate from your production org, used to develop, configure and test changes without affecting real users or data. It is a copy of your org (its configuration and, depending on the type, its data too) that lives on a different instance with its own URL. It lets you make mistakes, iterate and validate in a controlled way before promoting the changes to production.
How many types of Salesforce sandbox are there and how do they differ?
How many types of Salesforce sandbox are there and how do they differ?
There are four types. Developer and Developer Pro copy only the metadata, or configuration, and can be refreshed daily, which makes them ideal for development. Partial Copy includes the metadata plus a sample of data and can be refreshed every five days, designed for QA and testing. Full copies the metadata plus all the real data and can be refreshed every twenty-nine days, reserved for user acceptance testing, staging and performance. They differ in how much data they copy, how much storage they offer and how often they can be refreshed.
What is a sandbox for, and why not work directly in production?
What is a sandbox for, and why not work directly in production?
It is for developing and testing every change in a safe environment before it affects the live system. Production is where your team works with real data every day, so a mistake there can break processes, lose information or leave people unable to operate. The sandbox gives you an identical place to experiment without consequences and only then promote what has been validated, avoiding incidents in the business.
What does refreshing a sandbox mean?
What does refreshing a sandbox mean?
Refreshing a sandbox means copying the current state of your production org over it again, so the configuration and data are back in line with the real environment. Over time a sandbox falls out of date because production keeps changing, and working on an old copy makes the tests unreliable. Each sandbox type has its own minimum refresh interval, from one day to twenty-nine days.
What is the difference between a sandbox and a Developer Edition org?
What is the difference between a sandbox and a Developer Edition org?
A sandbox is always a copy of your production org and is tied to it: it is refreshed from production and inherits its context. A Developer Edition org is a free, standalone org, unrelated to your production, used to learn, experiment or build packages for distribution. If you want to test your real configuration and data, you use a sandbox; if you want a clean environment detached from your company, you use a Developer Edition.
We bring this to your Salesforce
Salesforce implementation, integration and support for LatAm companies, focused on the team actually using it instead of going back to spreadsheets. Tell us where your org stands.
Related terms
- Salesforce OrgA Salesforce org (organization) is the isolated, unique instance where everything a company has in Salesforce lives: its data, users, configuration, code and customizations. It is the logical container, identified by its own Org ID, within the multi-tenant cloud.
- Validation RuleA validation rule is a Salesforce condition that checks a record's data when it is saved and blocks the save with an error message if the data does not meet a criterion, ensuring data quality and consistency.
- Salesforce ObjectA Salesforce object is a database table that stores one type of record (accounts, contacts, opportunities). It defines the fields, relationships and rules of a set of business data inside the platform.
- ApexApex is Salesforce's proprietary, object-oriented programming language, similar to Java, that runs on Salesforce's servers. It lets you add custom business logic (triggers, classes and integrations) when declarative tools such as Flow are not enough.
- System IntegrationAn integration is the technical connection that lets two or more systems (CRM, ERP, e-commerce, etc.) exchange data automatically, without manual entry, so information flows in sync between them in real time or in batches.
- WebhookA webhook is an automatic HTTP notification that one system sends to another system's URL the moment an event happens, in real time. It lets applications integrate without one having to ask the other for updates every so often.
Related questions
Salesforce
Salesforce implementation, integration and support for LatAm companies, focused on real team adoption.
How Salesforce solves itFive AI products that work on top of the CRM you already use. They don't replace your system: they add the layer you do by hand today.
