[object Object]

A freshly refreshed Full sandbox is more dangerous than production. It has every customer record, every email address, every webhook URL. And by default, it can call any of them.

The post-refresh checklist below is the runbook we hand to every client. Skip none of it.

Phase 1: lockdown (before any user logs in)

The clone completes with email deliverability set per Salesforce default (“System email only”). Verify this is still the case. If anyone changed it pre-refresh, the new sandbox might send.

sf data query --query "
  SELECT Id, DeliveryStatus
  FROM EmailDeliverability
" --target-org sandbox-after-refresh

Hard rule: if DeliveryStatus = 'AllEmail' immediately after refresh, halt and reset to SystemEmailOnly. Investigate who changed it.

Disable inbound and outbound integration users:

sf data query --query "
  SELECT Id, Username, Profile.Name
  FROM User
  WHERE UserType = 'IntegrationUser'
  AND IsActive = true
" --target-org sandbox-after-refresh

For each, decide: needed in sandbox (with mocked endpoint), or disabled. Default to disabled.

Phase 2: named credentials and connected apps

Named Credentials carry over with the prod URLs. The sandbox will happily call your production webhooks if you let it.

sf data query --query "
  SELECT DeveloperName, Endpoint, AuthProvider.DeveloperName
  FROM NamedCredential
" --target-org sandbox-after-refresh

For every named credential pointing at a production endpoint, either:

  • Update the endpoint to the corresponding sandbox/staging URL of the external system, or
  • Set IsCalloutEnabled = false on the credential (recommended default; opt-in per credential as needed).

Connected Apps similarly carry over. If your prod orgs trust connected apps that have ANY scope you wouldn’t grant to a sandbox, revoke them post-refresh.

Phase 3: scheduled jobs

The clone preserves scheduled Apex. They will start firing on the sandbox’s schedule unless you abort them.

// Run as one-off Anonymous Apex
List<CronTrigger> jobs = [
  SELECT Id, CronJobDetail.Name, NextFireTime, State
  FROM CronTrigger
  WHERE State IN ('WAITING', 'ACQUIRED')
];
for (CronTrigger ct : jobs) {
  System.abortJob(ct.Id);
}

Then re-schedule only what you actually want running in the sandbox. Most jobs (data exports, ETL syncs to downstream warehouses) should NOT run in sandbox.

Phase 4: data mask and PII handling

If you’re masking, fire Data Mask now. See the Data Mask strategy piece for config details.

If you’re not masking and the sandbox has prod data:

  • Restrict login to a named approval list during the validation window.
  • Disable all login from outside corporate VPN.
  • Set up login flow that logs every sandbox login to a tracking object.

Phase 5: outbound mocks

If your org uses Mulesoft, Postman mocks, or a self-hosted mock service for sandbox testing, point the sandbox at them now. Verify with a probe call from Apex:

public static void probeMocks() {
  for (NamedCredential nc : [
    SELECT DeveloperName, Endpoint FROM NamedCredential
  ]) {
    try {
      HttpRequest req = new HttpRequest();
      req.setEndpoint('callout:' + nc.DeveloperName + '/probe');
      req.setMethod('GET');
      req.setTimeout(5000);
      HttpResponse res = new Http().send(req);
      System.debug(nc.DeveloperName + ': ' + res.getStatusCode());
    } catch (Exception e) {
      System.debug(nc.DeveloperName + ' UNREACHABLE: ' + e.getMessage());
    }
  }
}

A 2xx from a known mock endpoint is good. A 2xx from a production endpoint is a 911.

Phase 6: feature flags and custom metadata

Production has feature flags configured for prod state. Sandbox should typically have everything enabled for testing.

sf data query --query "
  SELECT DeveloperName, MasterLabel, Enabled__c
  FROM FeatureFlag__mdt
" --target-org sandbox-after-refresh

For each flag where the sandbox should differ from prod, deploy a sandbox-specific value via metadata.

Custom Settings hierarchy values that were prod-specific (org-wide URLs, env identifiers) need rewriting. Maintain a SandboxOverlay deployment package and apply it as part of the refresh runbook. See custom metadata vs custom settings for the broader pattern.

Phase 7: users, permission sets, and licenses

Refresh preserves users from production. The sandbox will have every active prod user as an active sandbox user. Decide:

  • Inactivate all non-developer users at refresh. Re-activate selectively.
  • Or: leave active but enforce SSO + IP restriction so only intended users can log in.

The danger pattern is leaving active users with no SSO restriction. A user with their prod password might log in to sandbox without realizing it’s a sandbox and update real-looking-but-fake records.

Phase 8: third-party app reconfiguration

Many managed packages (CPQ, Marketing Cloud Account Engagement, third-party AppExchange tools) have post-refresh setup procedures. Maintain a list of installed packages and the post-refresh action required for each:

  • Pardot/Account Engagement: disconnect prod connector, connect sandbox connector or none.
  • CPQ: re-link quote document templates if storage uses external service.
  • Conga/DocuSign: rotate API tokens; the prod tokens will fail in sandbox anyway.

Phase 9: data exports and backup

The sandbox is a known-good state right after refresh + mask. Export the seed data NOW.

sf data export tree \
  --query "SELECT Id, Name, AnnualRevenue FROM Account LIMIT 100" \
  --output-dir sandbox-seed-snapshot \
  --target-org sandbox-after-refresh

When developers pollute the sandbox with test data, this snapshot is your restore point.

Phase 10: sign-off and notification

The final step: an admin signs off in a dedicated SandboxRefreshLog__c record with checkboxes for every phase above. The sandbox is not “open for business” until that record is complete. Notify the team in the dedicated channel.

UX note

Render a persistent banner across every page: SANDBOX [name] - refreshed {date}. Use a Lightning App Builder component on every record page. Cost: tiny. Saves: “I sent that email from sandbox, didn’t I?” incidents.

Bottom line

  • Lock email deliverability first; verify, don’t trust.
  • Repoint or disable every named credential before any user touches the sandbox.
  • Abort all scheduled jobs; re-schedule only what you intend to run.
  • Maintain a sandbox-overlay deployment package for env-specific config.
  • Sign off the refresh in a tracked record; the sandbox is closed until phase 10 completes.
[object Object]
Share