Developing, testing, and configuring features in a sandbox is not only a long-standing best practice in the ecosystem, but also one of the tasks that Salesforce professionals dedicate a great amount of time to.
How much time have you spent removing the “.invalid” from users’ emails in order to grant them access to a sandbox? Lots, I expect! Selective Sandbox Access is a new out-of-the-box feature available now that will speed up Salesforce sandbox user provisioning and save time – especially when dealing with a large number of users.
In this post, we’ll explore this new feature, how exactly it enhances the admin experience, and how fast it can actually be used.
What Are Salesforce Sandboxes?
As many people in the ecosystem suggest, sandboxes are where Salesforce Admins and Developers should live, while the production environment is a place they occasionally visit.
As the name suggests, sandboxes are a place where Salesforce professionals can explore, make changes, test new features, and more – all without impacting users until the changes are moved to production. These orgs are a copy of the production environment, and depending on the type of sandbox chosen, they may contain both metadata and data from the source org.
If you are a new or aspiring Salesforce Admin, take the time to familiarize yourself with what sandboxes are, including their types, refresh intervals, and how they can be used when building on the platform. If you’re already well into your Salesforce journey, make sure to check out the article below for a deeper dive into more advanced concepts.
Sandbox Access: Before and After
Can you quantify how much time you spent activating users who need access to one or more sandboxes? It’s probably a considerable amount, especially when multiple users need to test or when a Full Copy Sandbox used by multiple teams is refreshed.
This brings us to the process being improved: the tedious task of monitoring when a sandbox is created or refreshed, only to jump in and start removing the “.invalid” from users’ emails, waiting for them to confirm their email address, and eventually resetting their password if needed. Additionally, all active users from the production org have access to the sandbox, even if they don’t need it or if their email still contains “.invalid”, which is less than ideal.
With the new Selective Sandbox Access functionality, this process has just become a breeze for existing production users who need sandbox access, as well as for enhancing the sandbox security. Instead of manually modifying user emails, Salesforce will do this automatically with the help of a predefined public group. Users outside of the group will be frozen to ensure that access will be fully deliberate whenever warranted. On top of this, sandboxes should be created and refreshed much faster, too!
Get Started with Selective Sandbox Access
As mentioned above, Selective Sandbox Access relies on public groups to determine who, except from the sandbox creator, will get access to the sandbox. This means that the first step is to ensure you have the public groups ready, with the users assigned to them.
Note: You can have multiple public groups based on your needs, as whenever refreshing or creating a sandbox, you will have the option to choose the right one.
Except for the public group creation, there is no other step involved other than actually creating or refreshing a sandbox. Following the Winter ’25 release, using a public group to determine access to Developer and Developer Pro Sandboxes through the user interface is required, as you can notice if you try skipping this step.
The Sandbox Access dropdown remains optional for Partial and Full Copy Sandboxes as of now, and you will instead be presented with the option to choose all active users or a public group. Practically speaking, for these sandbox types, you still have the option to manage access as you did before Selective Sandbox Access.
After this, it’s business as usual – the sandbox will be created or refreshed, you will be notified when it’s ready, and you can get directly to building, rather than worrying about user access!
Considerations
Unlike other Salesforce features, there are not many considerations or limits to this functionality, given how straightforward it is and the fact that it is available to all instances. Permissions are, of course, the first consideration that should come to mind, as only users with either the Manage Sandboxes or Manage Dev Sandboxes permission will be able to create or refresh all sandboxes, or just developer ones.
When it comes to the public group(s), permissions are needed to create and maintain them as with any others, but one consideration for Selective Sandbox Access is that the selected groups have to be users, and ideally less than 150 to avoid impacting the sandbox creation time.
One thing to keep in mind for Spring ‘25 is that if your organization is using Tooling API for sandbox management, the ActivationUserGroupId will become mandatory for Developer and Developer Pro Sandboxes in order to mimic the behavior you saw above on the sandbox creation page.
Summary
Finally, such functionality for Salesforce sandboxes has been long overdue, and it has definitely been worth the wait! Selective Sandbox Access will not only save you precious time from an administration perspective, but it will also ensure sandbox security and provide a much better experience for users who need access to the test environments.
Let us know your thoughts on Selective Sandbox Access in the comments below!