Salesforce Environments Explained: Dev, QA, UAT, and Production (Simple Guide)

When you start working with Salesforce — whether as an Admin, Developer, or Tester — you will frequently hear terms like Production, Developer Sandbox, QA Sandbox, and UAT Sandbox.
These are simply different environments where you build, test, and finally release features safely.

Let’s understand each one clearly.

Production & Sandboxes in Salesforce

What is Production in Salesforce?

Production is the main live Salesforce org where your company’s real business runs.

Everything happening here is real and important:

• Real customers
• Real sales deals
• Real revenue
• Real dashboards used by management
• Live automations
• Daily business operations

Production = “Live Store”

You cannot make mistakes here. Even a small change can:

• Break user workflows
• Stop an integration
• Mess up customer data
• Affect company revenue

That’s why Salesforce NEVER recommends developing directly in Production.

So what do we use?
Sandboxes.

What is a Salesforce Sandbox?

A Sandbox is a copy of your Production org used for:

• Development
• Testing
• Training
• Experimenting safely

Nothing you do in a Sandbox affects real users.
It’s like having a practice version of your Salesforce environment.

Think of it like:

• Production → Real shop
• Sandbox → Practice shop

If things break in Sandbox → No problem!
If things break in Production → Big problem!

Types of Salesforce Environments (With Real-Life Flow)

Most companies follow this simple environment pipeline:

Developer Sandbox → QA Sandbox → UAT Sandbox → Production

Each environment has a purpose, just like different stages in a movie production.

1️⃣ Developer Sandbox (DEV)

Used by developers to create new features.

Contains:

• Metadata only (schema + code)
• No production data
• Fast refresh time

Developers use it to build:

• Apex classes
• Triggers
• LWC
• Flows
• Validation rules
• REST integrations

✔ Example:

You need to build a Trigger that automatically updates the Contact Phone when Account Phone changes.

Steps:

1. Write code in Developer Sandbox
2. Write test class
3. Test with sample records
4. Deploy to next environment

If something breaks → only Sandbox is affected.

2️⃣ Developer Pro Sandbox

Same as Developer Sandbox but with more storage.

Useful for:

• Large projects
• Multiple developers working together
• Heavy metadata or test records

✔ Example:

If your LWC needs 5,000+ dummy records to test pagination, you use Dev Pro.

3️⃣ Partial Copy Sandbox (QA / TEST Sandbox)

Contains:

• All metadata
• A subset of real production data
• Data is selected via Sandbox Templates

Best for:

• Functional testing
• Testing Flows with actual data
• Testing Reports
• Testing small integrations

✔ Example:

Your QA team wants to test a Validation Rule:

“Email must end with @company.com for all Leads.”

Partial Sandbox contains real-like Leads → so QA can test properly.

💡 Why Partial?

Because it brings a sample of real data — not the full production org.

4️⃣ Full Copy Sandbox (UAT / Pre-Prod)

This is the closest copy of Production.

Get Mr. Akash’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Contains:

• Metadata
• ALL records
• Attachments/files
• All configurations

Best for:

• User Acceptance Testing (UAT)
• Performance testing
• Integration testing
• Final approval before Production

✔ Example:

You completed a big project:

• New Lead Conversion automation
• Email-to-Case customization
• LWC for Vehicle Booking
• Apex REST service

Before going live:

• Business users test with actual data
• Managers review reports
• QA checks performance
• Integration team tests real callouts

If everything works → you’re ready for Production.

Why So Many Environments?

Simple:

This flow ensures:

✔ No bugs reach Production
✔ No business disruption
✔ Safe deployment
✔ Better quality features
✔ Stable releases

🎯 Real-World Example (Very Simple)

Let’s assume your company wants a new feature:

“Automatically send WhatsApp message when Lead Status = Confirmed.”

Step-by-step flow:

Developer Sandbox

• Developer writes Apex class to call Gupshup API
• Creates Flow
• Adds WhatsApp templates
• Tests with dummy Leads

QA Sandbox (Partial Copy)

QA team tests:

• What if Status = Pending?
• What if phone number is invalid?
• Are messages sent for the right Leads?

UAT Sandbox (Full Copy)

UAT checks with real production Leads:

• Real Indian numbers
• Real statuses
• Real business scenarios

Managers approve the functionality.

🚀 Production

Finally deployed → Real customers start getting messages.

This ensures zero mistakes in Production.

🏁 Conclusion

Sandboxes are one of the most important features in Salesforce.
They help you build, test, and validate changes safely without affecting your live business.

Environment flow:

DEV → QA → UAT → PRODUCTION

Using this process ensures:

• Smooth releases
• High-quality features
• No impact on customers
• No business downtime

Sandboxes = Safe practice.
Production = Real business.

Let’s Connect!👋

Thanks for reading! I love sharing Salesforce best practices, and I’d be happy to connect with fellow developers, admins, or anyone curious about Salesforce.

📱 Scan the QR Code below to connect with me directly (Gravatar):

Gravatar Profile (Scan to Connect)

Or just drop me a message — always happy to talk Salesforce, automation, and tech 🚀.