In Salesforce Dx, sandbox environments are meant to do coding and testing by the developers. The advantage is that multiple users can simultaneously log into single Developer sandbox and share, and the primary objective of a Sandbox is to create a productive environment in which the changes during active development can be isolated until those are ready to share. The typical developer sandboxes copy all the metadata and setup data. This data includes all the custom settings, Apex classes, custom object definitions, triggers, dashboards, reports, pricing, Visualforce pages, etc.
Sandboxes also behave the same as that of the Salesforce Dx Production Orgs, but the major differences are in who the developers configure and test the Sandbox Orgs. User permission is needed to view the Sandbox setup and configuration. Permission is also needed to create, activate, refresh, and delete Sandbox. Next are a few things to consider before creating a sandbox.
Considerations to make while creating Sandbox
- The servers and IDs
As we can see, Sandbox Orgs and Production Orgs will always have unique IDs. The copy engine will create an org against each request for creation and refresh. So, org ID of a sandbox will keep on changing each time when you refresh your sandbox. Salesforce Dx will insert a new value every time in all the places where the org ID is used as the text values or metadata.
To identify the org ID of the org which you logged in to, go to set up Setup and enter the Company Info at the Quick Find tab and select the corresponding Company Information. Any of the process or scripts like Web-to-Lead or the test scripts which depends on “hard-coded” org ID should use the updated ID for Sandbox. Also, when you deploy changes to the Production Org, the scripts and processes needed to be updated with the Production Org ID.
As Flosum.com points out, Salesforce may crate Sandbox Orgs at many instances. Whenever a new Sandbox is created, or an existing one gets refreshed, Salesforce chooses an instance for the sandbox, so these may appear with different URLs at different instances.
- Users and contacts
For all Sandbox types, user information gets included in sandbox copy or refreshed. As there is a need for all Salesforce usernames to be unique and refer to a single org, the copies usernames get modified to ensure this uniqueness. For every username, this copy process applies modifications to come up with a fresh username.
At the first step, the default Sandbox name gets appended to the username. Say, for example, a username like firstname.lastname@example.org for a typical Sandbox named ‘Test’ may further become email@example.com. However, if the resultant username isn’t unique, then a second modification is also performed by adding some more characters or digits to the modified name. This will result in a unique username creation, for example, 01x7Vquser@flosum.com or so.
Even though these features have many benefits, it also comes with some specific drawbacks too which the developers and admin face while dealing with Salesforce Dx Sandbox and Production Org creation. However, these also would be taken care of them in the upcoming releases of Salesforce Dx by making it a more reliable and flexible platform.
Bio Trudy is a Business Tech Analyst. He is very responsible for his job. He loves to share his knowledge and experience with his friends and colleagues.
Hope you like this post. Comment below for any query, help, and suggestion.