Salesforce Platform & Environments Explained: Production, Sandboxes, Scratch Orgs and More

One of the most important things a Salesforce developer or admin can understand early is not a feature, a tool, or a programming concept. It is the environment they are working in. Salesforce provides multiple distinct environments for different stages of development — and understanding what each one is, what it is for, and what happens when you use the wrong one for the wrong task is foundational knowledge that everything else builds on.

What the Salesforce Platform Is

Salesforce Platform — previously known as Force.com — is a Platform-as-a-Service product designed to simplify the development and deployment of cloud-based applications. Developers build and configure apps through a browser-based interface or an IDE, deploy them to Salesforce's multi-tenant infrastructure, and benefit from automatic scaling, security, backup, and maintenance without managing any underlying servers or software. Because the platform is multi-tenant, every organization shares the same underlying infrastructure while remaining completely isolated from one another. This architecture is what makes Salesforce's governor limits necessary — and understanding that context helps explain why those limits exist and why they must be respected in code and automation design.

‍

What a Salesforce Environment Is

A Salesforce environment — also called an org — is a separate, isolated instance of the Salesforce platform. Each org has its own data, configuration, users, and metadata. Changes made in one org have no effect on any other org unless explicitly deployed between them. This isolation is what makes Salesforce's multi-environment model safe and practical. Developers can build, break, reconfigure, and experiment in development environments without any risk to the live system their organization depends on. Admins can test configuration changes against realistic data before applying them where business operations actually run. Teams can work in parallel without blocking each other. The alternative — everyone working directly in the single live system — is how avoidable disasters happen.

Production Environment

Production is the live Salesforce instance where the business runs. It contains real customer data, active user accounts, live integrations with external systems, running automations, and all the configuration that actual business operations depend on. Every active user in the organization — across Sales, Service, Marketing, Finance, and any other function using Salesforce — is interacting with production every day. This makes production simultaneously the most important and the most sensitive environment in the Salesforce ecosystem. A misconfigured validation rule, a flow with an unhandled error path, or a field update that was not fully tested can disrupt business processes immediately and affect every user in the org. There is no undo button for configuration changes made directly in production. There is no staging buffer between your change and its impact on real operations. Salesforce does allow certain configuration changes — custom objects, fields, validation rules — to be made directly in production without going through a development environment. This is technically possible. It is not recommended. For Apex code specifically, production deployment is not possible without first creating and testing in a development environment — Salesforce enforces this at the platform level. The standard is clear: build and test elsewhere, deploy to production only when the work is validated.

‍

Development Environments

Development environments are where all building, testing, and experimentation should happen. They are completely separate from production, contain non-business-critical test data, and are designed to absorb the inevitable mistakes and iterations that are part of any development process. There are three primary types.

Developer Edition

A Developer Edition org is a free, full-featured Salesforce environment available to anyone who creates a developer account. It provides access to the complete Salesforce platform — standard objects, Lightning components, Apex, APIs, Flow Builder, and all core development tools — without requiring a paid license or a production org. Developer Edition orgs are ideal for individual learning, feature prototyping, building managed packages, and standalone development work that does not need to replicate a specific production configuration. They can also function as a Dev Hub — the parent org that authorizes and manages Scratch Org creation. The limitations are worth understanding. Storage, API call volume, and email sends are restricted compared to paid editions. Developer Edition orgs do not come with sandbox access, so they cannot replicate a production org's data or configuration. And newer platform features that require specific license types cannot be provisioned to an existing Developer Edition — accessing those features requires creating a new org with the appropriate edition.

‍

Sandboxes

Sandboxes are development and testing environments created as copies of your production org. Because they replicate production's configuration and optionally its data, sandboxes are the right environment for testing changes that need to be validated against a realistic representation of your actual system before deployment. Salesforce provides four sandbox types that differ in their data copy scope and how frequently they can be refreshed.

A Developer Sandbox provides a metadata-only copy of production — configuration and customizations without production data. It refreshes every day and is suited for individual development tasks where production data is not needed for testing.

A Developer Pro Sandbox extends the Developer Sandbox with more storage capacity, making it suitable for more data-intensive development work. It also refreshes daily.

A Partial Copy Sandbox includes a subset of production data alongside the full metadata copy. The data sample is configurable through a sandbox template. It refreshes every five days and is appropriate for testing that requires realistic data without replicating the full production dataset.

A Full Sandbox is a complete copy of production — all metadata and all data. It is the most accurate testing environment available and is used for performance testing, final UAT, and staging deployments where a complete production mirror is required. Full sandboxes refresh every 29 days due to the significant resource cost of the full data copy.

The right sandbox type depends on what the work requires. Individual development tasks rarely need more than a Developer Sandbox. UAT and pre-production validation typically require a Full or Partial Copy Sandbox to ensure the test environment accurately reflects what production will encounter.

‍

Scratch Orgs

Scratch orgs are temporary, fully configurable development environments designed specifically for source-driven development and CI/CD integration. Unlike sandboxes, which are created by copying production, scratch orgs are created fresh from a JSON definition file that specifies the org edition, features, and settings. A scratch org can be created in minutes, has a configurable lifespan of one to thirty days, and is intended to be disposable — created for a specific development task and deleted when that task is complete. They start with no data, requiring developers to seed test data programmatically or through data import as part of the setup process. The disposable model is the point. Because scratch orgs are created and destroyed regularly, development environments stay clean and consistent. Configuration drift — the gradual accumulation of untested changes that makes long-lived sandboxes increasingly unreliable as testing environments — does not occur. Every scratch org starts from a known, version-controlled state. Scratch orgs integrate natively with CI/CD pipelines. In a source-driven development workflow, code and metadata live in version control, scratch orgs are spun up automatically to run tests, and only validated changes are promoted through the pipeline. This workflow produces more reliable deployments and makes automated testing genuinely practical at scale. To use scratch orgs, Dev Hub must be enabled in a production or Developer Edition org. Scratch org creation and management is handled through the Salesforce CLI.

‍

Trailhead Playground

Trailhead Playgrounds are special-purpose orgs created automatically when completing Salesforce Trailhead modules. They are designed for hands-on learning exercises and come pre-configured with the data and settings each module requires. They are not development environments in the production sense — they are learning environments, appropriate for completing Trailhead challenges and exploring platform features in a guided context.

‍

Choosing the Right Environment

The right environment depends entirely on the nature of the work. Learning and individual exploration belong in a Developer Edition or Trailhead Playground. Feature development and unit testing belong in a Developer Sandbox or Scratch Org. Integration testing and UAT belong in a Partial Copy or Full Sandbox. Production receives only validated, tested, approved changes — deployed through a structured release process, never built in place. Understanding this model is not administrative overhead. It is the foundation of every reliable Salesforce implementation. The developers and admins who internalize it early make fewer costly mistakes, deploy more confidently, and build systems that hold up under the pressure of real business operations.