Sandbox Refresh: Common problems

Question

We are planning to refresh our DEV Sandbox (Used for Integration Testing) from Prod.

I am trying to identify impacted areas and how I can address those post refresh

One of the identified areas - User Management

There are many developers who don't have PROD access. They exist only on Sandbox. Post refresh these users will be deleted. So

1. How can I identify all users who exist on sandbox and not in Prod?
2. Once identified is there a way to automate user creation of identified users not existing on Sandbox? (Post Refresh)

---

Thank you for your reply... I am still evaluating what will be the best approach for us to overcome these challenges...Other challenges I am facing are as below

• The sandboxes we are targeting to refresh are DEV Sandboxes, hence all the data came through integrations as well as manually seeded data for testing will be wiped out. Data available through integration (for Account and contact) can be brought again but manually seeded data (for other objects) has to be restored using data loader (possibly through CLI)

• Consumer key for connected system also gets updated, hence the integrations will be impacted. The new consumer key for the connected systems has to be declared again on their side. For example we have connected APP for CPQ

• we have SSO implemented , there is an impact on it as well

• SandboxPostCopy interface seems redundant for my use case as data in any case has to be imported using dataloader

• So email anonymisation/invalidation can be handled by modifying CSVs directly

Please let me know if I am thinking on the right lines, any suggestion is more than welcome

Answer 1

I believe the easy way to archive it is creating a Script After Sandbox Creation and Refresh. You can use this script to create the users

Here is the documentation: https://releasenotes.docs.salesforce.com/en-us/spring16/release-notes/rn_deployment_sandbox_postcopy_script.htm

Another approach that I already have done is creating a Profile in Prod called Developer. This profile does not have any access. So, I use the Script after Sandbox Creation and Refresh to update the Profile of these users to Admin.

Answer 2

Once the sandbox refresh starts, you'll have no automated way to know which Users are being wiped out as the SandboxPostCopy interface runs after the sandbox is created

So, as with @mpeixoto answer, you'll need to recreate those users in the sandbox by implementing an apex class that supports the SandboxPostCopy interface. This class can read a static resource (Csv, json, ...) of Users you need to rebuild. Said static resource is maintained in PROD (as it will be copied to the sandbox on sandbox creation).

I'd go with the json approach as you can create the JSON by using the REST API to build a JSON array of User sobjects that can be readily deserialized into insertable sobjects by the sandboxPostCopy class.

Answer 3

• No to a file of actual users, this is very limiting to support and to them.
• Fake Test Users on the other hand should be a file ready for processing when the testers are ready for it.
• Yes to inactive users sitting in prod.
• A user field on prod to determine those to be activated in sandbox.
• Yes to inactive users with federation ids.
• Yes to SSO for easy access for those devs
• Yes to an IDP managing your users and creating them as inactive in prod.
• That said I recommend letting each new dev user setup a Password etc before inactivating them. so that when they are activated in Sandbox they can immediately use their password if not SSO, they can then log and change their email to remove .invalid
• Yes to a script after sandbox refresh, but I have never tried scripting a pure activation process
• doing all of this means they can be pre setup with the correct profiles and roles etc
• all you should need to do in the new sandbox is define your Keys and Domains and any custom settings etc.
• scripting in new data is straight forward as long as you use externalIds to link your referenced records.