Salesforce provides two types of non-production environments, Sandboxes and Scratch Orgs. Each fulfills a specific purpose and in the context of this guide will be used in the following manner:
Sandboxes
Limited use for fixed environments ( DEV INT, QA, UAT )
Scratch Orgs
Support all development / dev+test uses
Each type of non-production environment has unique constraints which defines how these are used:
Sandboxes
Sandboxes are refreshed from the production environment, there are limitations on how frequently they can be refreshed, as well as how many can be created.
Scratch Orgs
Scratch Orgs only exist for limited time, can be easily created, but are completely empty when created, therefore any related data must be generated and scripted in.
Development > Scratch Orgs
Assuming a Scrum/Agile approach, development efforts should be short lived, and involve a team including both developers and QA staff. Scratch Orgs marry well with the needs of these teams as it allows developers to work in an isolated environment, and leverage source control as a means of sharing changes with other team members. QA staff can validate changes being made as well as develop automated testing and related test data to exercise the functionality supported in a controlled manner.
Functional Validation > Sandboxes
Once a change is ready to be promoted, confidence that it will work in a production environment is often a requirement. Having an environment that closely mirrors production (including all related data) is important.
Continue on to understand Code Promotion and how to structure these environments.
Official Salesforce Documentation
When moving data to sandboxes, and copying production data, it's important to hide / encrypt secure information of users, such as SSN, passwords, and anything else people could use maliciously.
As of now, masking data is limited with current toolsets, however, there are methods that are available and commonly used on the Salesforce marketplace, as well as 3rd party applications that can allow you more flexibility with how you want to manage secure data.
Use the SandboxPostCopyInterface and write your own apex class that implements method runApexClass(context). This can kick off a batch class to do the anonymization. allows you to run an Apex class as soon as the sandbox is refreshed. Use that class to run a batch class that makes your data encrypted.
Vendor appexchange solution like OwnBackuphttps://appexchange.salesforce.com/listingDetail?listingId=a0N30000007p6RYEAY
Informatica has a product for managing sandboxes and cleaning datahttps://blogs.informatica.com/2018/02/08/choose-informatica-cloud-test-data-management-for-your-salesforce-security-model/#fbid=YSF_UYEgXDd
Create permissions so non-admins can't see that stuff
On the standard user object, create an encrypted custom field to store the user's Social Security number. Set the field's Mask Type attribute to hide the first five digits of the social security number, and add field-level help to inform users of the required format. Then, create a validation rule that uses the REGEX() function to verify that the value of the custom field is in the correct format. Finally, create a new custom profile that allows a select group of users to the see the Social Security numbers unmasked.
For more information, visit here
Create two new fields to hold the address and phone number of these specific contacts and then in the Field Level Security of those contacts set the fields to not visible for your standard user profile.
Benefits: these users won't be able to view the field through any means, even through reports or API tools.
Using the Dataloader, you can mass update the records to remove any sensitive data. This is a manual process though, and it will need to be done each time the sandboxes are refreshed.
Encrypt Custom Fields & Restrict other Salesforce users from seeing custom text fields you want to keep private. Only users with the permission “View Encrypted Data” can see data in encrypted custom text fields.
The scratch org is a source-driven and disposable deployment of Salesforce code and metadata. They are great for temporary deployments, peer review, enhanced test coverage, and automation.
You might spin up a new scratch org when you want to:
Start a new project
Start a new feature branch
Test a new feature
Start automated testing
Perform development tasks directly in an org
Start from “scratch” with a fresh new org
conduct user acceptance testing or to test installations of packages
You can use force:source:push for scratch orgs only. If you’re synchronizing source to another org, use the Metadata API. The push command doesn’t handle merges. Projects and scratch orgs are meant to be used by one developer. Therefore, we don’t anticipate file conflicts or the need to merge.
To push changed source to a scratch org that’s not the default, you can indicate it by its username or alias: sfdx force:source:push -u "Username"
It’s likely that you have some files that you don’t want to sync between the project and scratch org. You can have the push command ignore the files you indicate in .forceignore.
Where to Put .forceignore
Be sure the paths that you specify in .forceignore are relative to the directory containing the .forceignore file. For the .forceignore file to work its magic, you must put it in the proper location, depending on which command you are running.
Add the .forceignore file to the root of your project for the source tracking commands
force:source:push, force:source:pull, force:source:status, and force:source:convert
Add the file to the Metadata retrieve directory (with package.xml)
force:mdapi:convert
Resources
A sandbox is a copy of your production organization. You can create multiple copies of your organization in separate environments for different purposes such as development, testing, and training, without compromising the data and applications in your production organization. Different types of sandboxes have different refresh intervals, meaning they cannot be replaced for a set amount of days. It is important to be mindful of which sandbox is being used for which process. This guide explores basic sandbox information, and practices.
Note From QA Strat:
Unit Tests and Apex Tests: Scratch Orgs
Feature Tests and Regression Tests: Dev-Pro Sandbox
Staging and user-acceptance testing: Partial-Full sandbox
Developer Pro Sandboxes
Have a refresh interval of 1 day
1 GB limit
Only Metadata is copied
No sandbox template
Partial Full Sandboxes
Have a refresh interval of 5 days
5 GB limit
Metadata and sample data is copied
Has a sandbox template (required)
Full Sandboxes
Have a refresh interval of 29 days
Same storage limit as production org
Metadata and all data is copied
Has a sandbox template (optional)
Give Manage Sandbox permissions to a user to allow them create, refresh, activate, or delete a sandbox
Give Setup and Configuration permissions to a user to allow them to view a sandbox
Monitor the storage of each sandbox to ensure you don't throw too much into it
Refresh a sandbox before you plan to work on or test new changes in it
Make sure you don't refresh or delete a sandbox until you're sure that you're finished the work you have to do in it. Be mindful of the refresh intervals.
Setup -> Sandboxes in Quick Find
Click 'New Sandbox'
Enter a name (Such as 'QA'. The fewer characters the better
Select the type of sandbox you want
For a Partial Copy or Full sandbox, decide the type of data you want in the sandbox a. Partial: click next, select the template b. Full: click next, select how much data to include(or choose a template)
To run scripts after each create and refresh for this sandbox, specify the Apex class you previously created from the SandboxPostCopy interface.
Setup -> Sandboxes in quick find -> sandbox templates
New Sandbox
Enter a name and description
Select checkboxes for each object you want from the available objects list
Save
Setup -> Sandboxes in quick find
Next to the name of sandboxes there should be a refresh link, click it
Review the name, values, and description
Select the type of environment you want
If you want your sandboxes activate immediately after refresh, select Auto Activate
Click Create
A sandbox can be cloned to save time. Instead of pulling source from the production org, you can replicate the data. Sandbox cloning simplifies having multiple concurrent streams of work in your application life cycle. You can set up a sandbox for each type of work, such as development, testing, and staging
Set up -> Sandboxes
Click Clone
Enter a Name
confirm that the sandbox name selected in the Create From dropdown is the sandbox you want to use as your source org. Click Next, then Create
Salesforce's Sandbox Guide & Documentation: Here