Mastering Salesforce Administration: Part 7 - Sandbox Strategy & Change Management

Updated 20/04/2026

You have now worked through the core administration toolkit: keeping the org healthy, shaping the user experience, building automation, managing approvals, sending reliable email, and separating configuration from hardcoded logic. The final part of the admin track is about how you change all of that safely once real users, real data, and real business processes depend on the org.

Sandbox strategy and change management turn good administration into a repeatable operating model. In this article, you will define the purpose and cadence for each sandbox, refresh and validate environments with discipline, compare orgs before deployment, protect production adjacent data, and connect release governance to day to day delivery without slowing teams down.

🧪 Sandbox Strategy & Change Management

🏗️ Sandbox Types & Lifecycle

Sandboxes are isolated copies of your production org where you can build, break, and test without impacting real users. They’re your primary safety net for change management, so you want a deliberate mix—not “whatever’s available”.

Salesforce offers four core sandbox types:

Type	Data Copy	Refresh Interval	Typical Use Case
Developer	Metadata only (no production data)	1 day	Individual dev, PoCs, config spikes
Developer Pro	Metadata only, higher data/file storage	1 day	Dev + small data sets, QA, training
Partial Copy	Metadata + sampled production data (template)	5 days	Integration tests, UAT with subset of data
Full	Metadata + full (or templated) production data	29 days	Pre-prod/UAT, performance, high risk changes

A practical pattern for many teams:

Developers: 1 Developer (or Dev Pro) sandbox per dev as their personal feature environment.
Integration: 1 Partial Copy as the shared “system integration” environment.
UAT: 1 Full sandbox as the pre-production environment for business testing.
Training/compliance: Optional Full or Partial with masked data for demos and audits.

🔄 Sandbox Refresh Lifecycle & Governance

Refreshing a sandbox pulls a fresh copy of metadata (and, for Partial/Full, data) from production. That’s powerful but disruptive: local changes are wiped and any handcrafted test data disappears.

Pre-refresh checklist

Communicate: Let impacted teams know at least 24-48 hours in advance and confirm no critical testing is scheduled during the window.
Capture changes: Ensure all metadata changes are committed to source control and/or deployed out of the sandbox.
Protect integrations: Pause any scheduled jobs or external integrations that call the sandbox, especially if they rely on specific data.
Agree on timing: Schedule the refresh for off hours or a quiet period in your sprint cadence.

Refresh steps

In the production org, go to Setup → Sandboxes, select the sandbox, and click Refresh.
For Partial/Full, select or update the sandbox template that defines which data to copy.
Confirm options and start the refresh; expect anywhere from minutes to hours depending on size.

Post-refresh validation

Create a small, repeatable checklist:

Enable appropriate users: In Setup → Users, update the users email addresses to remove the .invalid
Smoke test login & access: Confirm key roles/profiles can log in and see what they expect.
Core data checks: Spot check a few critical objects (Cases, Opportunities, key custom objects).
Integration links: Re-point any hardcoded endpoints or credentials if needed; run a simple end to end test for each integration.
Automation & tests: Run key Flows, Apex tests, and critical journeys to make sure nothing obvious is broken.

Document this in a wiki and treat it as the “post refresh runbook” for whoever owns that sandbox.

Refresh governance

Limit who can refresh (typically platform owners/admins).
Maintain a simple refresh calendar (e.g., dev: ad-hoc, integration: monthly, UAT: before major releases).
For sandboxes holding sensitive data, pair refreshes with data masking or obfuscation jobs.

🚚 Metadata Deployment & Org Comparison

Deploying changes from sandbox to production requires understanding Salesforce’s metadata model.

Deployment Approaches:

Change Sets
- UI driven selection of components; good for smaller, admin led changes.
- Familiar, but harder to reuse and version.
Packages
- Managed or unmanaged packages for app-style bundles and shared components.
- Useful when the same feature ships to multiple orgs or customers.
CLI / Metadata API (CI/CD)
- Use the Salesforce CLI (or tools on top of it) to deploy from source control.
- Best fit for teams with branching strategies, pipelines, and automated tests.

For org comparison, lean on:

Source control diffs (compare branches or tags representing each org).
CLI based retrieve + diff workflows or third-party tools that visualise metadata differences.

The goal is simple: know exactly what you’re changing before you press deploy.

📋 Change Management: The CI/CD Pipeline

Modern Salesforce teams manage changes as code using a Continuous Integration/Continuous Deployment (CI/CD) pipeline. Instead of passing change sets between sandboxes, the pipeline uses source control (Git) as the single source of truth and automates deployments.

For Salesforce, a Release Branching Strategy is usually the most practical approach. Because business sign-off (UAT) can take days or weeks, true continuous deployment to production (pushing directly to main for every feature) is rare.

At a high level, your CI/CD pipeline and branching strategy should flow left to right:

Feature Branch → Integration Branch → Release Branch → Main (Production)

Stage 1: Development (Dev Sandbox & Feature Branch)

Developers build and iterate in personal Developer sandboxes.
Work is tracked in a feature branch (e.g., feature/expense-approvals) pushed to source control.
Developers use the Salesforce CLI (sf project deploy start) to sync changes to their sandbox and write unit tests.

Stage 2: Pull Request to Integration

The developer opens a Pull Request (PR) to merge their feature branch into the integration branch.
CI Automation kicks in: A validation deployment runs against a CI sandbox to compile code and run all Apex tests.
Code review happens here. Once approved and merged, the CI/CD system automatically deploys the code to the Integration sandbox (Partial Copy).

Stage 3: UAT and the Release Branch

Once integration testing is complete and a release bundle is ready, a release/v1.x branch is cut from integration.
Pushing this branch automatically triggers a deployment to the UAT sandbox (Full Copy) for business sign-off.
Any bug fixes found in UAT are committed directly to the release branch (and later back promoted to integration).

Stage 4: Production Release

After UAT sign-off, the release manager opens a PR to merge the release branch into main.
Merging into main triggers the production deployment.
Because the exact same metadata bundle was already tested in UAT, the production deployment is predictable and low risk.
Post-deployment scripts and manual data steps are executed from a documented runbook.

Learn some of the basics of version control systems, Git and GitHub with the Git and GitHub Basics trailhead module.

Git and GitHub Basics Learn about version control systems and practice using Git and GitHub.

🔐 Sandbox Security, Access Control & Isolation

Some sandboxes may contain sensitive data and should be treated as production adjacent, not “throwaway”.

User provisioning & Access control

Only provision users who genuinely need access; don’t give every user a Full sandbox login by default.
Grant sandbox access on a need to know basis. Align permissions with roles (e.g., testers get the object/record types they need; developers get broader access in dev sandboxes).
Review sandbox users regularly and remove access for people who’ve moved teams or left the organisation.

Data sensitivity

Full and Partial Copy sandboxes pull production data, including PII, by default. Use Salesforce Data Mask or equivalent anonymisation tools to obfuscate sensitive fields (names, emails, IDs, financial data) as part of the refresh process where required by policy or regulation.
Prefer Developer / Developer Pro sandboxes with synthetic data when real production data isn’t required for the test scenario.

Integration hygiene & Org isolation

Use sandbox specific credentials, API keys, OAuth clients, and endpoints. Never reuse production credentials or secrets in sandboxes.
Disable or carefully constrain any outbound integrations from sandboxes to avoid impacting real downstream systems.
Monitor sandbox login and API usage for unusual patterns, especially in environments that contain masked but still business sensitive data.

📊 Governance: Sandbox Stewardship, Naming & Documentation

A bit of structure around sandboxes makes life easier for admins, developers, and auditors.

Naming and Ownership

Use a consistent naming pattern so anyone can infer the purpose and owner from the name at a glance. A good format is [Team]-[Purpose]-[Stage], resulting in names like Sales-Opportunity-Forecast-Dev or Finance-Expense-Approval-UAT. Avoid generic names like Dev1 or Test that fail to communicate intent.

Assign each sandbox to a team and a named owner (such as the platform lead for that domain). The owner is responsible for access approvals, refresh scheduling, and post refresh validation. To track this, maintain a simple register (like a wiki page or spreadsheet) listing each sandbox alongside its owner, purpose, and refresh cadence.

Access and Lifecycle Management

Manage sandbox access using a lightweight process where a user requests access, the sandbox owner approves it, and an admin provisions it. Always log these requests to maintain an audit trail of who has access to which datasets, and review this access at least quarterly to remove users who no longer need it.

When a sandbox has served its purpose and is no longer needed, communicate the decommissioning to the owning team, export any critical test data or logs, and delete the sandbox to reclaim licenses and reduce your security surface area.

Sandbox Documentation

For each active sandbox, maintain documentation covering the following details:

Purpose & Owner: What the sandbox is for (e.g., dev, integration, UAT) and who to contact about access or issues.
Data Profile: Whether it contains a full copy, partial template, or config only, and if the data is masked.
Refresh Schedule: How often it’s refreshed and from which source environment.
Integrations: Which external systems it connects to and which are currently active.
Known Quirks: Any known data gaps, masking side effects, or limitations.

Final Thoughts

In this final admin article, you brought the whole track into the delivery lifecycle. You looked at sandbox types and refresh governance, deployment options and org comparison, CI/CD branching, production release habits, sandbox security, access control, ownership, and the documentation needed to keep environments understandable.

Reliable change management is a competitive advantage. Teams that treat sandboxes, release controls, validation checks, and rollback discipline as shared operating habits can improve the org faster without turning every change into a production risk. That is the real goal of administration: not just knowing the tools, but building the habits that keep Salesforce stable, trusted, and ready for what comes next.

With the administration track complete, the journey now moves into the development articles. The admin foundations you have built here will make that next step stronger, because good Salesforce development depends on understanding the org, the users, the data, the automation, and the release discipline around every line of code.

Next steps

The admin track is now complete. Next, the Salesforce Development Fundamentals series shifts you from clicks to code. Start with Part 1 — The Developer Mindset & Toolkit, where you’ll set up a local development environment, learn when code is the right tool, and step into the workflow professional Salesforce developers use every day.

Resources

Git and GitHub Basics Learn about version control systems and practice using Git and GitHub.