Understanding Salesforce Environments: Org Types Explained

Before we explore the different types of sandboxes, let’s define the primary Salesforce environments you will work with.

What is a Production Org?

A Production Org is the live Salesforce environment where your real business operates. It holds your real-time customer data, runs your active business processes, and is the instance that your end-users log into every day.

What is a Sandbox Org?

A Sandbox Org is a copy of your production org, created for development, testing, and training purposes. It provides a safe, isolated environment where you can build and test new features without any risk of impacting your live data or users. Sandboxes are connected to a specific production org and are the cornerstone of a healthy development lifecycle.

What is a Developer Edition Org?

A Developer Edition Org is a free, full-featured Salesforce environment designed for individuals to learn, build, and test on the platform.These are standalone environments, commonly used for completing Trailhead badges or developing packages for the AppExchange.

What is a Demo Org?

A Demo Org is typically a Developer Edition org that has been pre-configured with sample data and metadata to showcase a specific product, feature, or proof-of-concept. Consultants and partners often use demo orgs to demonstrate a solution to a potential client in a clean, curated environment.

Here is list of Get a FREE org based on Requiements

Why are Sandboxes Essential for Salesforce?

Now that we understand what is a sandbox , it’s critical to understand why they are non-negotiable for any Salesforce implementation.

• Risk Mitigation: The primary benefit is safety. Sandboxes isolate development and testing from your production data and users. A bug in a new Apex trigger or a faulty flow in a sandbox will have zero impact on your business operations.
• Development & Customization: Sandboxes provide the perfect environment for developers and admins to build new features, whether it’s crafting new Lightning Web Components, configuring complex flows, or customizing page layouts.
• Quality Assurance: They are indispensable for Salesforce testing. Before a new feature is deployed to production, it must be thoroughly vetted in a sandbox to ensure it works as expected and doesn’t introduce any regressions or conflicts with existing functionality.
• User Training: A sandbox is an ideal training ground. You can let new employees explore Salesforce, practice data entry, and learn business processes on a realistic copy of the org without the risk of them modifying or deleting live customer data.
• Structured Release Management: Sandboxes are the cornerstone of a healthy Application Lifecycle Management (ALM) process. A typical release path, which is key to a good Salesforce deployment strategy, involves developing in a Developer sandbox, integrating and testing in a Partial or Full Sandbox, and finally deploying the polished, tested changes to production.

The Four Types of Salesforce Sandboxes

Salesforce offers 4 distinct types of sandboxes, each with different storage limits, refresh intervals, and purposes.

1. Developer Sandbox

The Developer Sandbox is the most basic and common type. It is designed for isolated development and initial testing. It copies all of your production org’s metadata (like Apex classes, triggers, Visualforce pages, custom objects, and fields) but none of your production data.

Key Characteristics:

• Data Storage: 200 MB
• File Storage: 200 MB
• Refresh Interval: Can be refreshed once per day.
• Includes Metadata Only: No real data production is copied.

Best Use Cases:

• Coding and developing new Apex triggers, classes, and Lightning Components.
• Building and unit testing new automations like flows and process builders.
• Trying out new configurations or experimenting with custom settings.
• As a personal development environment for each member of your technical team.

2. Developer Pro Sandbox

The Developer Pro Sandbox is a step up from the Developer Sandbox, offering significantly more data and file storage. Like the Developer Sandbox, it copies all metadata from your production org but does not copy any production data.

Key Characteristics:

• Data Storage: 1 GB
• File Storage: 1 GB
• Refresh Interval: Can be refreshed once per day.
• Includes Metadata Only: No production data is copied.

Best Use Cases:

• Handling more complex development tasks that require a larger volume of test data to be loaded manually.
• Serving as an integration testing environment where code from multiple developers is combined.
• Quality assurance (QA) testing for specific features that need a controlled set of test data.
• Performance testing on a small, controlled data set.

3. Partial Copy Sandbox

The Partial Copy Sandbox is where data begins to play a significant role. It is a hybrid environment that copies all of your production org’s metadata and a sample of your production data. You define this sample using a “Sandbox Template.”

Key Characteristics:

• Data Storage: 5 GB
• File Storage: 5 GB
• Refresh Interval: Can be refreshed every 5 days.
• Includes Metadata and a Sample of Data: You choose which objects to sample data from.

Best Use Cases:

• Quality Assurance (QA) Hub: This is the most common use case. Testers can work with a realistic, albeit partial, set of data to validate new features.
• User Acceptance Testing (UAT): Business users can test new functionality with familiar-looking data before it goes live.
• Training: An excellent environment for training users with a relevant subset of real-world data.

4. Full Sandbox

The Full Sandbox is the most powerful and comprehensive sandbox environment. It is an exact replica of your entire production org, including all metadata and all of your data (all records, attachments, and files).

Key Characteristics:

• Data Storage: Same as your production org.
• File Storage: Same as your production org.
• Refresh Interval: Can be refreshed only every 29 days.
• Includes All Metadata and All Data: A complete mirror of production.

Best Use Cases:

• Performance and Load Testing: The only environment where you can accurately test how a new feature will perform under the full weight of your production data.
• Staging Environment: A Full Sandbox serves as the final “staging” area before deployment. All changes are deployed here for one final round of regression testing to ensure nothing breaks.
• Debugging Complex Issues: When a data-specific bug occurs in production that you can’t replicate elsewhere, a Full Sandbox is the best place to troubleshoot it.

Comparison of Salesforce Sandbox Types

This table provides a clear comparison of the primary sandbox types to help you choose the right environment.

How to Create a Salesforce Sandbox

Creating a sandbox is a straightforward process handled from your production environment.

1. From Setup in your production org, search for “Sandboxes” in the Quick Find box.
2. Click on Sandboxes. You will see a list of your current sandboxes and the number of licenses available for each type.

.

Enter a Name for your sandbox (typically 10 characters or less).

Select the “next” button for type of sandbox you want to create (Developer, Developer Pro, etc.).

Click on “Create” after filling required details like Data Storage, Sandbox Access.

The creation process can take anywhere from a few minutes for a Developer sandbox to several hours or even days for a Full sandbox, depending on the size of your org. You will receive an email notification when your sandbox is ready to use.

Note : If you are creating a Partial Copy sandbox, you will need to select a Sandbox Template that you have pre-configured.

Understanding Sandbox Templates for Partial Copy

When you create a Partial Copy sandbox, you must use a Sandbox Template. This template is your instruction manual, telling Salesforce exactly which objects’ data you want to copy into your new sandbox.

Creating a Sandbox Template:

1. From Setup in production, search for “Sandboxes” in the Quick Find box and go to ” Sandbox Templates” tab.
2. Click New Sandbox Template.

3. Give the template a name (e.g., “Salesforcehours”). From the list of available objects, select the ones you want to include data from. For every object you select, Salesforce will copy up to 10,000 of its most recent records into the sandbox.

Click on save

Important: If you select an object that has a required lookup or master-detail relationship, make sure to also include the parent object in the template to avoid data integrity issues.

Carefully planning your sandbox template is key to creating a useful and relevant dataset for your UAT and training environments.

Frequently Asked Questions (FAQ) about Salesforce Sandboxes

What happens to my data and metadata when I refresh a sandbox?

Refreshing a sandbox is a destructive action. The existing sandbox is completely deleted and replaced with a fresh copy of the metadata (and data, depending on the type) from your production org. Any work that has not been saved or deployed out of the sandbox will be permanently lost.

Can I deploy changes from one sandbox to another?

Yes. This is a standard and highly recommended practice in Application Lifecycle Management. You can deploy changes (metadata) from a lower sandbox (like Developer) to a higher sandbox (like Partial Copy for UAT) using tools like Change Sets or more advanced DevOps tools.

Do Salesforce sandboxes expire?

No, Salesforce sandboxes do not expire. Once created, they remain available until they are manually refreshed or deleted.

Why is my Full Sandbox refresh taking so long?

A Full Sandbox refresh involves copying your entire production metadata and data, which can be a massive amount of information. The time it takes depends on the size of your org and its place in the Salesforce refresh queue. It can take anywhere from several hours to several days to complete.

If you are preparing for Salesforce interview prepration : Do check our blog