Sandbox refresh strategy is important considering there could development work that could be in the Sandboxes and be lost. Also refreshing sandboxes could also result production data be available in Sandboxes which you may want to mask before it being available.
Org Structure and Naming Convention:
We should know how identify each org and how many Sandboxes should we typically require.
- Production
- UAT<Followed By Some Identifier (optional)> Full-Copy Sandbox if not available then go for Partial Copy Sandbox
- Stage<Followed By Some Identifier (optional)> Full-Copy Sandbox if not available then go for Partial Copy Sandbox and if that too is consumed then go for a Developer Sandbox
- Test / QA Environment Partial Copy Sandbox and if that is consumed for UAT then go for a Developer Sandbox
- Developer Sandboxes <Each developer gets a Sandbox | a shared sandbox for development> Developer Sandbox
Refresh Lifecycle:
- Planning
- Notification
- Confirmation
- Execution
- Preparation
- Use
Planning:
During the planning stage we intend to strategize the initiation of the refresh of the Sandbox. This would require internal talks with stakeholders to prepare any ToGoLive items in the concerned Sandbox.
| Task | Outcome (Sample) | Owner | Due Date | Completed? | Completed on |
| Identify the person that would be owning the Activity | Mike to Lead the Activity | Chris | 10/10/21 10:00 AM PST | No | |
| Identify the Sandboxes to refresh | UAT, Stage, AekotDev | Matt | 10/10/21 10:00 AM PST | No | |
| Backup of Metadata via full package retrieve into a branch on git repository. | Committed UAT to backup/uat-10-21-21 | Deb | 10/10/21 10:00 AM PST | No | |
| Get a confirmation List of the Objects/Records to be copied to the sandbox? (applicable to Partial-Sandbox) | 44 Object-Records to be copied from Production to Sandbox | Roger | 10/10/21 10:00 AM PST | No | |
| Document Integration Endpoints to configure in Different sandboxes post refresh | Document with Post refresh metadata changes is made available | Sam | 10/10/21 10:00 AM PST | No |
Other Configurations to consider early on for Post-Deployment readiness
Outline each for every sandbox
- Integration Endpoints (if applicable)
- SSO Configurations (if applicable)
- Email Deliverability (turn off immediately after refresh) – (turn on after things are setup)
- Users to be enabled (list of users whose email needs to updated)
- Users to be added (list of new members which are required to be added to the sandbox)
- Apex Jobs to be scheduled
- Reports to be scheduled
- Data to be masked
- Named Credentials Sign-on (if applicable)
- Data to be migrated/reconfigured (e.g Custom Settings, Custom meta-data)
- Remote Site Settings
- Managed Package Configuration (If Applicable)
Notification:
Notify the plan with a detailed date time and plan for the activity to the stakeholders.
This should be a time based email sent after regular intervals(One month before to every week and in the last few days daily). Also notify them about the tentative downtime.
Confirmation:
Receive a confirmation from all stakeholders in over an email or over a short survey before initiating the refresh for the final time. Based on the survey response, decide the go/no-go with the refresh of the Sandbox.
Execute:
Data-model changes happen often in the Production environment which could be due any reason like:
- Package Installation
- Continuous Development
So it is a good idea to update your Object Template before a refresh. Can be considered as a must for Partial Copy Sandbox and Optional for Full-Copy Sandbox refresh. This helps to bring in the relevant data into the refreshed sandboxes. Also consider that Full-Copy Sandboxes are paid Sandboxes and have a refresh interval of 29 days. So a mistake could end up impacting things and how the setup is done for the sandbox.
Post-Refresh Preparation ():
It is recommended to have a checklist of items/activities that need to be accomplished post the refresh of the sandboxes. This helps to ensure that all configurations are in accordance with the environment. Also, a lot of these could be automated based on the devOps practices or via apex-script. In either case
| Task | Details | Applicable Org | Assignee | Status |
| Disable Email Deliverability | Navigate to Setup>Email>Deliverability>”None” | Stage, UAT, QA | ||
| Configure Remote Site Setting | Remote-Site-Settings-Mapping | Stage, UAT, QA, Developer | ||
| Import / Configure Custom Settings | Custom Setting Values | Stage, UAT, Developer | ||
| Configure Custom Metadata | Custom-Metadata-Settings | Stage, UAT, Developer | ||
| Mask- Critical Data | Execute the following-Steps | Stage, UAT | ||
| Re-configure Auth Providers | Execute the following-Steps | UAT, QA | ||
| Re-configure Named Credentials | Execute the following-Steps | UAT, QA | ||
| Schedule following jobs | Execute the following-Steps | UAT, QA | ||
| Update any Org Specific Document | Execute the following-Steps | UAT, QA | ||
| Update Connected Apps to facilitate inbound integrations | Execute the following-Steps | UAT, QA | ||
| Enable Email Deliverability | Navigate to Setup>Email>Deliverability>”All Emails” | UAT, QA | ||
| Add Org Specific Users | Create / Import following Users | UAT, QA | ||
| Correct applicable Existing user email | Update / Import following Users | UAT, QA | ||
Notify:
Send an official confirmation to the users. Which would provide a green signal for them to log into the respective sandboxes and start to use them in the desired manner.