Deploy Sandboxes
Deploy Sandboxes
@salesforcedocs
Last updated: December 1, 2022
© Copyright 2000–2022 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of salesforce.com, inc.,
as are other names and marks. Other marks appearing herein may be trademarks of their respective owners.
CONTENTS
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
SANDBOXES: STAGING ENVIRONMENTS FOR
CUSTOMIZING AND TESTING
Want to customize your organization in a staging environment where you can test changes without affecting your production organization
or its users? Want to have an organization that users can log into and test new features before they’re production-ready? Or maybe you
just want to log into a Salesforce organization for training or development that mirrors your production organization.
IN THIS SECTION:
When to Use a Sandbox
Sandboxes create copies of your Salesforce org in separate environments. Use them for development, testing, and training, without
compromising the data and applications in your production org.
Sandbox Setup Considerations
Sandbox behavior is similar to a Salesforce production org, but important differences affect how you configure and test a sandbox
org.
Create, Clone, or Refresh a Sandbox
Create a sandbox to use for development, testing, and training. Clone a sandbox to copy its data and metadata into another sandbox.
Refresh an existing sandbox to update its contents.
Manage Your Sandboxes
In Setup, enter Sandboxes in the Quick Find box, then select Sandboxes. Sandboxes displays the available sandboxes that
you purchased and a list of your sandboxes in use.
Manage Your Sandboxes Programmatically
Use Salesforce CLI to authorize in to, create, and clone sandboxes. Traditionally, admins create and manage sandboxes through the
Setup UI. But we realize that many admins and developers want the ability to create and manage their development and testing
environments programmatically, and to automate their CI processes. Salesforce CLI enables you to do both.
Inactive Sandbox Expiration
To better utilize capacity and support growth, we perform a routine cleanup of inactive sandboxes. A sandbox is considered inactive
and eligible for deletion if it hasn’t been accessed for 180 days.
Deploy Your Changes
Migrate metadata changes between Salesforce orgs by using the deployment tools available in Setup.
Secure Your Sandbox Data with Salesforce Data Mask
Salesforce Data Mask is a powerful data security resource for Salesforce admins and developers. Instead of manually securing data
and access for sandbox orgs, admins can use Data Mask to automatically mask the data in a sandbox. Data Mask enables admins
and developers to mask sensitive data in sandboxes such as Personally Identifiable Information (PII) or sales revenue.
1
Sandboxes: Staging Environments for Customizing and Sandbox Types and Templates
Testing
IN THIS SECTION:
Sandbox Types and Templates
Sandboxes are isolated from your production org, so operations that you perform in your sandboxes don’t affect your production
org.
Sandbox Licenses and Storage Limits by Type
A sandbox is a copy of your organization in a separate environment that you can use for a variety of purposes, such as testing and
training. Sandboxes are completely isolated from your Salesforce production organization. The operations you perform in your
sandboxes don’t affect your Salesforce production organization. You can create different sandbox environments for your org,
depending on your needs for storage, copy configuration, and frequency of refresh.
SEE ALSO:
Sandbox Types and Templates
Deploy Your Changes
Choose Your Tools for Developing and Deploying Changes
2
Sandboxes: Staging Environments for Customizing and Sandbox Types and Templates
Testing
Full Sandbox
A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support performance testing, load testing, and
staging. Full sandboxes are a replica of your production org, including all data, such as object records and attachments, and metadata.
The length of the refresh interval makes it difficult to use Full sandboxes for development.
We recommend that you apply a sandbox template so that your sandbox contains only the records that you need for testing or
other tasks.
When you create a Full sandbox, you also have to decide how much field tracking history and Chatter activity to include.
• The default is to omit field tracking, but you can include up to 180 days of field tracking. If you track field history for many objects
in your production org, specify fewer days to avoid generating an excessive amount of data.
• Chatter activity data can be extensive, which can add a significant amount of time to your Full sandbox copy.
Limit the amount of field history that you copy, and copy your Chatter data only if you need it for your testing use cases.
Sandbox Licenses
You purchase licenses for each sandbox type and can purchase multiple licenses of each type. Sandbox licenses are hierarchical. Specifically,
the following table shows the type of sandbox you can create with each license:
3
Sandboxes: Staging Environments for Customizing and Sandbox Types and Templates
Testing
In use
The displayed value represents the number of sandboxes that you’ve purchased and used.
Note: If you don’t see a sandbox option or need licenses for more sandboxes, contact Salesforce to order sandboxes for your org.
When your sandbox licenses expire, your existing sandboxes are subject to certain restrictions. See Unlock a Sandbox on page 25 for
resolution of license expiration issues.
IN THIS SECTION:
Create or Edit Sandbox Templates
Sandbox templates control which data is copied into a sandbox.
SEE ALSO:
Create a Sandbox
Sandbox Licenses and Storage Limits by Type
Unlock a Sandbox
4
Sandboxes: Staging Environments for Customizing and Sandbox Licenses and Storage Limits by Type
Testing
2. Click New Sandbox Template or click Edit next to an existing template you want to modify.
3. Enter a name and description for the sandbox template.
4. To add objects to the template, select the checkbox for each object you want from the available Objects list.
The Object Details section shows you the objects to be added automatically with the one you’ve selected.
5. To remove objects from the template, deselect the checkbox for the object in the available Objects list.
If you remove an object you previously selected, dependent objects you didn’t explicitly select are removed. If you attempt to remove
an object with dependent objects, you receive a warning requesting a confirmation of the removal. After you confirm your choice,
those objects are also removed.
6. Click Save.
To understand how to use a Sandbox template during sandbox creation or refresh, see Create a Sandbox on page 15.
To understand how a Sandbox template is used by the sandbox copy engine to create a Full or Partial Copy sandbox, see Sandbox
Licenses and Storage Limits by Type on page 5.
Warning: If you modify your object schema, your sandbox templates could be altered to include objects that are required by
relationships. If you make a change to a required relationship in your object schema, review your sandbox templates to ensure
that objects that you expect to be selected are still selected.
SEE ALSO:
Create a Sandbox
Sandbox Licenses and Storage Limits by Type
Sandbox Types and Templates
Developer Pro 5 5
Sandbox
• If you need licenses for more sandboxes, contact Salesforce to order sandboxes for your organization.
• You can order an unlimited number of QA databases.
5
Sandboxes: Staging Environments for Customizing and Sandbox Licenses and Storage Limits by Type
Testing
Note: You can buy additional Developer Pro sandboxes for any edition, or Partial and Full sandboxes for Enterprise, Unlimited,
and Performance editions.
Developer Sandboxes aren’t available for purchase but are bundled with add-on sandboxes of other types.
• The Developer Pro Sandbox add-on is bundled with 5 Developer Sandboxes.
• The Partial Copy Sandbox add-on is bundled with 10 Developer Sandboxes.
• The Full Sandbox add-on is bundled with 15 Developer Sandboxes.
Note: You can match provisioned licenses in production to your sandbox org without having to refresh your sandbox. This process
updates sandbox license counts to match the counts in production. The process also adds licenses that are in production but not
in sandbox, and deletes licenses that aren’t in production.
Developer Pro Sandbox 1 day Data storage: 1 GB Metadata only Not available
File storage: 1 GB
Partial Copy Sandbox 5 days Data storage: 5 GB Metadata and sample Required
File storage: Same as data
your production org
Full Sandbox 29 days Same as your production Metadata and all data Available
org
Note: Sandboxes don’t send email notifications when storage limits are reached. However, if you reach the storage limit of your
sandbox, you can’t save new data in it. To check your storage limits, from Setup, enter Storage Usage in the Quick Find box,
then select Storage Usage.
SEE ALSO:
Create a Sandbox
Create or Edit Sandbox Templates
Sandbox Setup Considerations
Refresh Your Sandbox
6
Sandboxes: Staging Environments for Customizing and Sandbox Setup Considerations
Testing
SEE ALSO:
Knowledge Article: Match production and sandbox licenses without a sandbox refresh
Apex Developer Guide: SandboxPostCopyInterface
Create a Sandbox
Sandbox Types and Templates
Sandbox Licenses and Storage Limits by Type
Unlock a Sandbox
7
Sandboxes: Staging Environments for Customizing and Servers and IDs
Testing
• The copy process doesn’t copy Contact data to Developer or Developer Pro sandboxes. Therefore, USER PERMISSIONS
Customer Portal users aren’t copied. However, the copy process does copy the Customer Portal
To view a sandbox:
licenses, so you can create Customer Portal users in Developer or Developer Pro sandboxes.
• View Setup and
• When you create or refresh a sandbox, user email addresses are modified so that production Configuration
users don’t receive automatically generated email messages from the sandbox. User email
To create, refresh, activate,
addresses are appended with .invalid. This modification ensures that the system ignores and delete a sandbox:
these email addresses. For example, a user email of • Manage Sandbox
[email protected] in production becomes
[email protected] when migrated to sandbox. If
you want sandbox users to receive automatically generated emails as part of testing, you can correct the email addresses while
8
Sandboxes: Staging Environments for Customizing and Email Deliverability
Testing
logged in to the sandbox. Return email addresses set in users’ Email Settings in production aren’t appended with .invalid in
the sandbox.
Warning: Sandboxes change Salesforce user email addresses, but don’t change other email addresses in Salesforce, such as
email addresses in contact records. To avoid sending unsolicited email, manually invalidate or delete all email addresses in
your sandboxes that don’t belong to users of the sandbox. When testing outbound email, change contact email addresses to
the addresses of testers or an automated test script.
• Each sandbox user’s account email must be verified before that user's account can send email from Salesforce.
Email Deliverability
New and refreshed sandboxes use the System email only setting by default. Sandboxes created
EDITIONS
before Spring ’13 default to All email.
This setting applies to production and sandbox. To set it, from Setup, enter Deliverability Available in: both Salesforce
in the Quick Find box, and then select Deliverability. If editable, set the access level in the Access Classic (not available in all
to Send Email section. If Salesforce restricted your ability to change this setting, you can’t edit the orgs) and Lightning
access level. Experience
• No access—Allows only password reset emails. Prevents all other outbound email to and from Available in: Professional,
users. Enterprise, Performance,
• System email only—Allows only automatically generated emails, such as new user and password Unlimited, and
Database.com Editions
reset emails.
• All email—Allows all types of outbound email. Default for new orgs that aren’t sandboxes.
USER PERMISSIONS
Tip: The System email only setting is useful for controlling email sent from sandboxes so
that testing and development work doesn’t send test emails to your users. To view a sandbox:
• View Setup and
Configuration
To create, refresh, activate,
and delete a sandbox:
• Manage Sandbox
9
Sandboxes: Staging Environments for Customizing and Configuring Full Sandboxes
Testing
10
Sandboxes: Staging Environments for Customizing and Customization and Data Changes
Testing
• Always log in to your sandbox org using either the My Domain login URL for the sandbox or https://test.salesforce.com.
My Domain login URLs are recommended because they add an extra layer of security. In sandboxes with enhanced domains, sandbox
My Domain login URLs are in the format MyDomainName--SandboxName.sandbox.my.salesforce.com. You can
find an org's My Domain login URL on the My Domain Setup page.
• Remember to log in using the modified username as described in Users and Contacts on page 8.
• If using the API, after you log in, use the redirect URL that is returned in the loginResult object for subsequent access. This URL reflects
the instance on which the sandbox is located and the appropriate server pool for API access.
• Sandbox copies are made with federated authentication with SAML disabled. Configuration information is preserved, except the
value for Salesforce Login URL. Salesforce Login URL is updated to match your sandbox URL, for example
https://yourInstance.salesforce.com/, after you re-enable SAML. To enable SAML in the sandbox, from Setup,
enter Single Sign-On Settings in the Quick Find box, then select Single Sign-On Settings. Then click Edit, and select
SAML Enabled. For more information about configuring SAML settings, see Configure SAML Settings for Single Sign-On.
The version of your sandboxes can differ from Salesforce AppExchange around the time of a
USER PERMISSIONS
Salesforce release. Check the logo in the upper left corner of your sandbox home page for To view a sandbox:
version information. • View Setup and
Configuration
• If your org uses quote templates and you create a Developer Pro sandbox, you can’t open
templates that contain Text/Image fields for editing within the sandbox. To create, refresh, activate,
and delete a sandbox:
• If your production org uses an image in quote templates or service reports and you copy the
• Manage Sandbox
org to your sandbox, the image path is not correct and the image appears as a broken link. To
display the image, reinsert it from the correct location on your sandbox.
• Big Object records are not copied to a sandbox. The sandbox contains the Big Object definition, but none of the records associated
with the Big Object.
11
Sandboxes: Staging Environments for Customizing and Multi-Factor Authentication
Testing
Multi-Factor Authentication
Sandbox environments are temporarily excluded from the multi-factor authentication (MFA)
EDITIONS
requirement that went into effect on February 1, 2022. But we strongly recommend using MFA for
sandboxes that include intellectual property, customer data, or other Salesforce production data. Available in: both Salesforce
To develop a strategy for managing MFA in sandbox environments, review these considerations. Classic (not available in all
orgs) and Lightning
Note: To learn more about the MFA requirement, see the Salesforce Multi-Factor
Experience
Authentication FAQ.
• When you create or refresh a sandbox, all Multi-Factor Authentication for User Interface Logins Available in: Professional,
user permission assignments — whether set via profiles or permission sets — are copied over Enterprise, Performance,
from your production org. However, none of the MFA verification methods that a user has Unlimited, and
Database.com Editions
registered for your production org are copied to your sandbox. As a result, all MFA-enabled
users must register an MFA method the first time they log in to a new sandbox. And they must
repeat this step each time the sandbox is refreshed. USER PERMISSIONS
• If a user registers Salesforce Authenticator as an MFA verification method for their sandbox To view a sandbox:
account, the connection to the account is invalidated each time the sandbox is refreshed. But • View Setup and
the connection details aren’t automatically removed from Salesforce Authenticator. To avoid Configuration
a long list of invalid connected accounts in Salesforce Authenticator, users should manually To create, refresh, activate,
delete their old sandbox account from the app each time the sandbox is refreshed. and delete a sandbox:
Salesforce Authenticator assigns the same default name each time a user registers the app for • Manage Sandbox
their sandbox account. To avoid losing track of which sandbox connected accounts are active
and which are invalid, delete the old sandbox account before logging in to the new version of
the sandbox.
• If you use SSO for access to your production org but want to use MFA instead of SSO for your sandboxes, do so by assigning the
Multi-Factor Authentication for User Interface Logins user permission to users when you create or refresh a sandbox.
But when you deploy customizations to your production org, take care that you don’t accidentally include the sandbox’s MFA
configuration. To help keep MFA isolated to your sandbox:
– Use a dedicated permission set to assign the Multi-Factor Authentication for User Interface Logins permission to sandbox users.
– Give the permission set an obvious MFA-related name so it’s easy to distinguish it from other permission sets.
– Create a checklist that reminds Salesforce admins to exclude the MFA permission set from each deployment.
SEE ALSO:
Implement Multi-Factor Authentication
Register Verification Methods for Multi-Factor Authentication
Salesforce Authenticator
12
Sandboxes: Staging Environments for Customizing and Product and Service Exclusions
Testing
USER PERMISSIONS
To view a sandbox:
• View Setup and
Configuration
To create, refresh, activate,
and delete a sandbox:
• Manage Sandbox
13
Sandboxes: Staging Environments for Customizing and Create, Clone, or Refresh a Sandbox
Testing
https://MyDomainName.my.salesforce.com/00Oz0000000EVpU&pv0={!Account_ID} and
https://yourInstance.salesforce.com/00Oz0000000EVpU&pv0={!Account_ID}, don’t work in your
org’s sandboxes. We recommend that you use only relative URLs in your production org. Otherwise, correct the URLs in each sandbox.
• Salesforce has a background process that permanently deletes records in the Recycle Bin that are older than 15 days. This process
runs at different times on different servers, so the timestamp in your sandbox differs from the timestamp in your production org.
Applications and integrations that depend on this timestamp can fail if they are first connected to one environment, such as your
production org, and then connected to another environment, such as your sandbox. Consider this behavior when developing
applications and integrations that depend on this timestamp.
The time of the latest execution of the background delete process is available through the getDeleted() API call.
• For Salesforce authentication providers set up in the Summer ’14 release and earlier, the user identity provided by a sandbox does
not include the org ID. The destination org can’t differentiate between users with the same user ID from two sources (such as two
sandboxes). To differentiate users, edit the Salesforce Auth. Provider settings in the destination org, and select the checkbox to
include the org ID for third-party account links. After you enable this feature, your users must reapprove the linkage to their third-party
links. Salesforce authentication providers created in the Winter ’15 release and later have this setting enabled by default.
• After an org’s sandbox refresh is completed, a user has login access for 10 years after the refresh date if they are:
– A Salesforce admin.
– Copied into the sandbox from the production org, not created directly in the sandbox.
• To log in as any user, access your sandbox via test.salesforce.com or the My Domain login URL for the sandbox, which
you can find on the My Domain page in Setup. The option to log in as any user isn’t available when users access a sandbox from
production by using the Login link.
14
Sandboxes: Staging Environments for Customizing and Create a Sandbox
Testing
Sandbox Cloning
You can create a sandbox by cloning an existing sandbox rather than using your production org as your source. Save time by
customizing a sandbox with a set of data and metadata and then replicating it. 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. Your colleagues can easily clone individual sandboxes instead of sharing one sandbox and avoid stepping on each other’s
toes.
Monitor Your Sandbox’s Progress
From Setup, enter Sandboxes in the Quick Find box, then select Sandboxes. The list of your sandboxes displays a progress
bar for items in the queue, in progress, or recently completed.
Create a Sandbox
When you create a sandbox, Salesforce copies the metadata from your production org to a sandbox
EDITIONS
org.
1. From Setup, enter Sandboxes in the Quick Find box, then select Sandboxes. Available in: both Salesforce
Classic (not available in all
2. Click New Sandbox.
orgs) and Lightning
3. Enter a name (10 characters or fewer) and description for the sandbox. Experience
We recommend that you choose a name that: Available in: Professional,
• Reflects the purpose of this sandbox, such as QA. Enterprise, Performance,
Unlimited, and
• Has only a few characters, because Salesforce appends the sandbox name to usernames
Database.com Editions
on user records in the sandbox environment. Names with fewer characters make sandbox
logins easier to type.
USER PERMISSIONS
4. Select the type of sandbox you want.
If you don’t see a sandbox option or need licenses for more, contact Salesforce to order To view a sandbox:
sandboxes for your org. • View Setup and
Configuration
If you reduce the number of sandboxes you purchase, you are required to match the number
To create, refresh, activate,
of your sandboxes to the number you purchased. For example, if you have two Full sandboxes and delete a sandbox:
but purchased only one, you can’t create a Full sandbox. Instead, convert a Full sandbox to a • Manage Sandbox
smaller one, such as a Developer Pro or Developer sandbox, depending on which types you
have available.
6. To run scripts after each create and refresh for this sandbox, specify the Apex class you previously created from the SandboxPostCopy
interface.
7. Click Create.
15
Sandboxes: Staging Environments for Customizing and Refresh Your Sandbox
Testing
Tip: Try to limit changes in your production org while the sandbox copy proceeds.
The process takes from several minutes to several days, depending on the size and type of your org.
When your sandbox is ready for use, you receive a notification email that your sandbox has completed copying.
To access your sandbox, click the link in the notification email. Users can log in to the sandbox at https://test.salesforce.com
by appending .sandbox_name to their Salesforce usernames. For example, if a username for a production org is [email protected],
and the sandbox is named “test,” the modified username to log in to the sandbox is [email protected].
If you prevent user logins from https://login.salesforce.com in production through My Domain settings, the sandbox
prevents user logins from https://test.salesforce.com by default. In this case, instruct users to log in to the sandbox using
its My Domain login URL in the format https://MyDomainName--SandboxName.sandbox.my.salesforce.com.
You can find an org's My Domain login URL on the My Domain Setup page.
Note: Salesforce automatically changes sandbox usernames, but not passwords. New sandboxes have the default email deliverability
setting System email only. The System email only setting is especially useful for controlling email sent from sandboxes
so that testing and development work doesn’t send test emails to your users.
SEE ALSO:
Apex Developer Guide: SandboxPostCopyInterface
Sandbox Types and Templates
Sandbox Licenses and Storage Limits by Type
Create or Edit Sandbox Templates
Sandbox Setup Considerations
Unlock a Sandbox
To view a sandbox:
2. Next to the name, click Refresh.
• View Setup and
3. Review the Name, Description, and Create From values, and edit these values if needed. Configuration
4. Select the type of sandbox environment you want. To create, refresh, activate,
and delete a sandbox:
A table shows the number and type of sandbox licenses available in your org. You can select a
• Manage Sandbox
different sandbox type to refresh.
16
Sandboxes: Staging Environments for Customizing and Activate Your Refreshed Sandbox
Testing
If the sandbox you’re refreshing is a clone, this option isn’t available. A cloned sandbox refreshes from its source org and retains the
source org’s sandbox license type. If a sandbox’s source org is deleted, the clone refreshes from production.
6. To activate your sandbox immediately after you refresh it, select Auto Activate. In this case, you don’t receive an activation email.
7. Click Create.
8. Refreshing your sandbox can move it to a different Salesforce instance. For example, the sandbox can move from CS40 to CS50. If
you’re subscribed to Trust Notifications, check your subscription settings to ensure that you continue to receive updates about
unforeseen incidents and planned maintenance that affects your sandbox.
9. If you disconnected a tenant on the Manage Cloud-to-Cloud Connections page, reconnect it by following the steps in the appropriate
implementation instructions.
Salesforce starts copying data to the sandbox.
If you didn’t select Auto Activate while refreshing your sandbox, Salesforce sends you an email when your sandbox is ready to activate.
17
Sandboxes: Staging Environments for Customizing and What are Preview and Non-Preview Sandboxes?
Testing
Preview Sandbox
A preview sandbox provides early access to new features and lets you test your configurations before the production upgrade. Preview
sandboxes are upgraded approximately six weeks in advance of production orgs during every major release.
Non-Preview Sandbox
Non-preview sandboxes aren’t upgraded early. Use non-preview sandboxes when building new changes for your production org.
Some Considerations
Review these considerations when you create, refresh, or delete a sandbox.
Creating a Sandbox
• A sandbox isn’t a point-in-time snapshot of the exact state of your data. We recommend that you limit changes to your production
org while a sandbox is being created or refreshed. Setup and data changes to your production org during the sandbox creation and
refresh operations can result in inconsistencies in your sandbox. Check for inconsistencies in your sandbox after it’s created or
refreshed.
• If you’ve reached your org's limit, some types of sandboxes aren’t available. For example, if your org is limited to one full sandbox,
and you already have a full sandbox, you can’t create another full sandbox. However, you can refresh your existing full sandbox.
• Requests to create a sandbox can’t be canceled.
18
Sandboxes: Staging Environments for Customizing and Sandbox Cloning
Testing
Refreshing a Sandbox
• When you finish with a sandbox, you can refresh it. This process replaces the sandbox with a copy of your production org. Requests
to refresh a sandbox can’t be canceled.
• You can choose to either activate or discard a refreshed sandbox. A discarded sandbox can’t be recovered. Discarding a refreshed
sandbox reverts it to its previous version, and deletes the new version. Activating a refreshed sandbox deletes the previous sandbox
version.
• If you have active Salesforce-to-Salesforce connections in your sandbox, deactivate the connections and then reactivate them after
the sandbox is refreshed. The connections and mappings aren’t copied to the refreshed sandbox.
• If you have any tenant connections listed in the Manage Cloud-to-Cloud Connections page, such as for Omnichannel Inventory,
disconnect them before refreshing the sandbox. If you plan to reconnect any of the tenants after refreshing the sandbox, record
their information before disconnecting them.
Deleting a Sandbox
• If you’ve reduced your org’s number of sandbox licenses, a Delete link shows next to existing sandboxes. Delete a sandbox before
creating or refreshing any more sandboxes.
• A deleted sandbox can’t be recovered.
• Deleting a sandbox doesn’t terminate your sandbox subscription. If you delete your sandbox, you can create a new one.
• If you have any tenant connections listed in the Manage Cloud-to-Cloud Connections page, such as for Omnichannel Inventory,
disconnect them before deleting the sandbox. If you plan to reconnect any of the tenants after deleting the sandbox, record their
information before disconnecting them.
Sandbox Cloning
You can create a sandbox by cloning an existing sandbox rather than using your production org as your source. Save time by customizing
a sandbox with a set of data and metadata and then replicating it. 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. Your
colleagues can easily clone individual sandboxes instead of sharing one sandbox and avoid stepping on each other’s toes.
IN THIS SECTION:
Clone a Sandbox
When you clone a sandbox, all its data and metadata are copied to the new sandbox. A cloned sandbox uses the same license type
as its source org. For example, to clone a Full sandbox you must have a Full sandbox license available.
Refresh a Cloned Sandbox
Refreshing a cloned sandbox updates the sandbox’s metadata and data from its source org.
19
Sandboxes: Staging Environments for Customizing and Sandbox Cloning
Testing
Clone a Sandbox
When you clone a sandbox, all its data and metadata are copied to the new sandbox. A cloned
EDITIONS
sandbox uses the same license type as its source org. For example, to clone a Full sandbox you
must have a Full sandbox license available. Available in: both Salesforce
If custom domains are associated with your sandbox, before you clone it, review Considerations Classic (not available in all
for Custom Domains in Sandboxes. orgs) and Lightning
Experience
1. From Setup, enter Sandboxes in the Quick Find box, then select Sandboxes.
2. Click New Sandbox, or click Clone next to a completed sandbox. Available in: Professional,
Enterprise, Performance,
If you're cloning a Developer or Developer Pro sandbox hosted on a Hyperforce instance, our Unlimited, and
Quick Clone technology enhances the speed at which your sandbox is replicated. To see whether Database.com Editions
your sandbox is on Hyperforce, check the Location information in the list of sandboxes in Setup.
3. Enter a name (10 characters or fewer) and description for the sandbox. USER PERMISSIONS
We recommend that you choose a name that: To view a sandbox:
• Reflects the purpose of this sandbox, such as QA. • View Setup and
Configuration
• Has only a few characters, because Salesforce appends the sandbox name to usernames
on user records in the sandbox environment. Names with fewer characters make sandbox To create, refresh, activate,
logins easier to type. and delete a sandbox:
• Manage Sandbox
4. If you clicked New Sandbox, from the Create From dropdown, select the name of the sandbox
that you want to clone.
5. If you clicked Clone, confirm that the sandbox name selected in the Create From dropdown is the sandbox you want to use as your
source org.
6. Make sure that the org you’re cloning has the license type that you want for your new sandbox. To use a different license type,
choose a different source org from the Create From dropdown.
7. Click Next.
8. To run scripts after each creation and refresh for this sandbox, specify an Apex class that extends the SandboxPostCopy interface.
The Apex class you specify must exist in your source org.
9. Click Create.
Tip: Avoid making changes in your source org while the sandbox copy occurs.
When your new sandbox is ready, you can manage it from your production org like any other sandbox.
20
Sandboxes: Staging Environments for Customizing and Sandbox Cloning
Testing
A cloned sandbox refreshes from its source org and retains the source org’s sandbox license To view a sandbox:
type. If a sandbox’s source org has been deleted, the clone refreshes from your production org. • View Setup and
Configuration
5. If you want to activate your sandbox immediately after you refresh it, select Auto Activate. In To create, refresh, activate,
this case, you don’t receive an activation email. and delete a sandbox:
6. To run scripts after each creation and refresh for this sandbox, specify an Apex class that extends • Manage Sandbox
the SandboxPostCopy interface. The Apex class you specify must exist in your source org.
7. Click Create.
8. Refreshing your sandbox can move it to a different Salesforce instance. For example, the sandbox can move from CS40 to CS50. If
you’re subscribed to Trust Notifications, check your subscription settings to ensure that you continue to receive updates about
unforeseen incidents and planned maintenance that affect your sandbox.
Salesforce starts copying metadata and data to the sandbox.
If you didn’t select Auto Activate, Salesforce emails you when your sandbox is ready to activate.
SEE ALSO:
Activate Your Refreshed Sandbox
21
Sandboxes: Staging Environments for Customizing and Monitor Your Sandbox’s Progress
Testing
USER PERMISSIONS
To view a sandbox:
• View Setup and
Configuration
To create, refresh, activate,
and delete a sandbox:
• Manage Sandbox
To view a sandbox:
• View Setup and
Configuration
To create, refresh, activate,
and delete a sandbox:
• Manage Sandbox
22
Sandboxes: Staging Environments for Customizing and Sandbox Action and Status Reference
Testing
Salesforce displays this option only for active sandboxes. You must
be logged in to your org as an administrator to see the Log In USER PERMISSIONS
button.
To view a sandbox:
Refresh Click Refresh to replace a sandbox with a new copy. • View Setup and
Configuration
Salesforce activates the Refresh button only for sandboxes that
To create, refresh, activate,
are eligible for refreshing. Your existing copy of the sandbox
and delete a sandbox:
remains available while you wait for the refresh to be completed.
• Manage Sandbox
The refreshed copy is inactive until you activate it.
Note: The Delete and Refresh operations are available only when the refresh interval for that sandbox type has elapsed.
23
Sandboxes: Staging Environments for Customizing and Sandbox Action and Status Reference
Testing
Sandbox Statuses
Status Description
Sampling The copy engine is determining which object records are sampled and copied from the
production org. This status is used only by Partial Copy sandboxes.
Pending The sandbox is in the queue to be processed by the copy engine. If other sandbox copy
requests were made before yours, your sandbox could remain in this state for an extended
period of time.
Processing The copy engine has picked up the copy request and is working to build the sandbox.
Suspended The copy engine was interrupted while refreshing or creating the sandbox. The copy
engine automatically recovers from this state and returns to processing. If this status
remains unchanged for more than one hour, contact Salesforce Customer Support.
Stopped The copy engine couldn’t recover from multiple events. If your sandbox is in this state,
contact Salesforce Customer Support for specific details and next steps. Salesforce is
notified automatically of sandboxes in this state so we can resolve the issues.
Pending Activation The copy engine created the sandbox and is waiting for you to activate or discard it.
Activating The copy engine is completing the final steps to make your new sandbox available.
Discarding The copy engine is marking the refreshed sandbox for deletion, because you clicked
Discard. The current sandbox and your production org aren’t affected by this process.
Completed The copy engine has completed the creating or refreshing the sandbox, and the new
sandbox is active. You can log in to your new sandbox org.
Deleting The copy engine is marking the sandbox environment and all sandbox history for
deletion. This status is used after you click Delete. This process doesn’t affect your
production org.
Locking A background process is locking the sandbox. See the Locked status for more details.
Locked You can’t log into this sandbox because you let some or all your sandbox licenses expire.
Contact your account manager to restore the expired licenses. You have 60 days to restore
the licenses. If the licenses aren’t restored within 60 days, your sandbox is deleted.
24
Sandboxes: Staging Environments for Customizing and Unlock a Sandbox
Testing
Unlock a Sandbox
Sandboxes are licensed separately from the Salesforce service and are subject to restrictions. When
EDITIONS
your sandbox licenses expire, Salesforce decreases the count of available sandbox licenses for the
selected sandbox type. Available in: both Salesforce
If your current license count is lower than the number of your provisioned sandbox orgs, Salesforce Classic (not available in all
removes sandbox services, such as Refresh, Sandbox org accessibility, or Login. orgs) and Lightning
Experience
Note: Salesforce doesn’t automatically delete sandbox orgs because of a license expiration.
Available in: Professional,
Sandboxes are locked when all the licenses for a type of sandbox expire. Salesforce deletes sandboxes Enterprise, Performance,
that have been locked for 60 days. Users who created or most recently refreshed any sandbox for Unlimited, and
your org are notified prior to scheduling the sandbox for deletion. They get at least three email Database.com Editions
notifications over 30 days.
Salesforce deletes new sandboxes that weren’t activated within 30 days. Users who created or most
recently refreshed any sandbox for your org get at least two email notifications before we schedule the unactivated sandbox for deletion.
Here are some scenarios and solutions, based on licensing and usage.
All sandboxes of a The license count of a Your org has three full You don’t have access to Purchase the correct
particular type are locked given type, including sandboxes and zero full the sandboxes. sandbox licenses to
higher hierarchical types, sandbox licenses. unlock the sandboxes.
is zero.
All sandboxes are locked Your production org is Your org has one full If your production org is Contact your Salesforce
locked. sandbox and one locked, all sandboxes representative to unlock
developer-sandbox, but associated with the org your org. When your
you can't log in to either are locked. production org is
sandbox. unlocked, the sandboxes
are unlocked as well.
SEE ALSO:
Create a Sandbox
Sandbox Licenses and Storage Limits by Type
Manage Your Sandboxes
Sandbox Setup Considerations
25
Sandboxes: Staging Environments for Customizing and Manage Your Sandboxes Programmatically
Testing
Note: This change doesn’t terminate or change any of your sandbox subscriptions. If your sandbox is deleted due to inactivity,
your subscription remains in effect, and you’re still able to create sandboxes.
We send out automated email notifications for inactive sandboxes at 90, 120, and 150 days. The user who requested the sandbox is
notified of the upcoming expiration date. If this user is inactive, then all users in the production org with the Manage Sandbox user
permission are notified. After 180 days, a final email is sent notifying users that the sandbox has been deleted. After the sandbox has
been deleted, it can’t be recovered.
To continue using any existing sandbox, log in to the sandbox at least once every 179 days. If your sandbox is deleted, the license is
made available, and you can use this license to create sandboxes.
26
Sandboxes: Staging Environments for Customizing and Deploy Your Changes
Testing
IN THIS SECTION:
Choose Your Tools for Developing and Deploying Changes
Whether you’re an admin using point-and-click tools or a developer writing code, you can pick the right tool, work in a sandbox,
and deploy complete changes to a production org. You can customize and code changes for your org in a sandbox using one, or
more, of the tools provided by Salesforce.
Connect Organizations for Deployment
Deploy connections for change sets and authorize a deployment connection.
Change Sets
Use change sets to send customizations from one Salesforce org to another. For example, you can create and test a new object in
a sandbox org, then send it to your production org using a change set. Change sets can contain only modifications you can make
through the Setup menu. For example, you can’t use a change set to upload a list of contact records. Change sets contain information
about the org. They don’t contain data, such as records.
Modify Metadata Through Metadata API Functions Permission
Users must have the Customize Application permission to create, update, and delete metadata records. Thereafter, users with the
Modify Metadata Through Metadata API Functions permission can edit metadata (including Apex) through Metadata API even if
they don’t also have the Modify All Data permission. Metadata API is used for deployments using change sets, the Ant Migration
Tool, or the Salesforce CLI. Users must have the permission that enables use of the feature supported by the metadata they’re trying
to modify. They must also have the permission that enables their deployment tool.
Special Behavior in Deployments
When deploying changes to Salesforce, consider how individual components in your deployment behave so that you include all
the necessary changes. Use the information here to determine what to include in your deployment and how the changes appear
in the destination.
Monitor Deployments
You can monitor deployments that are in progress, check which deployments are waiting for execution, and view the results of
completed deployments on the Deployment Status page.
SEE ALSO:
Change Sets
Monitor Deployments
27
Sandboxes: Staging Environments for Customizing and Choose Your Tools for Developing and Deploying Changes
Testing
IN THIS SECTION:
Develop and Deploy Apex in the Developer Console
The Developer Console is an integrated development environment with a collection of tools you can use to create, debug, and test
applications in your Salesforce org.
Develop and Deploy Using Salesforce Extensions for Visual Studio Code
Salesforce Extensions for VS Code is powered by Salesforce CLI and the Salesforce APIs. Together with Visual Studio Code, the
Salesforce extension pack provides a robust development environment. Deploy to and retrieve from your sandboxes and other
development orgs. Manage, push to, and pull from your scratch orgs. Write, debug, and refactor your org’s code.
Develop and Deploy Using Metadata API
Use Metadata API to retrieve, deploy, create, update or delete customization information, such as custom object definitions and
page layouts, for your org. This API is intended for managing customizations and for building tools that can manage the metadata
model, not the data itself.
Deploy Using the Ant Migration Tool
Download the Ant Migration Tool if you want to perform a file-based deployment of metadata changes and Apex classes from a
Developer Edition or sandbox org to a production org using Apache's Ant build tool.
Deploy Using Change Sets
You can deploy workflows, rules, Apex classes and triggers, and other customization from a sandbox org to your production org.
You can create an outbound change set in the Salesforce user interface and add the components that you want to upload and
deploy to the target org.
SEE ALSO:
Extend Salesforce with Clicks, Not Code
Enhance Salesforce with Code
28
Sandboxes: Staging Environments for Customizing and Choose Your Tools for Developing and Deploying Changes
Testing
USER PERMISSIONS
Develop and Deploy Using Salesforce Extensions for Visual Studio Code
Salesforce Extensions for VS Code is powered by Salesforce CLI and the Salesforce APIs. Together
EDITIONS
with Visual Studio Code, the Salesforce extension pack provides a robust development environment.
Deploy to and retrieve from your sandboxes and other development orgs. Manage, push to, and Available in: Enterprise,
pull from your scratch orgs. Write, debug, and refactor your org’s code. Performance, Unlimited,
For information about downloading, installing, and using Salesforce Extensions for VS Code, visit Developer, and
the documentation site. Database.com Editions
Note: Salesforce Extensions for VS Code is a free resource provided by Salesforce to support
users and partners. It is not considered part of our Services for purposes of the Salesforce Main
Services Agreement.
SEE ALSO:
Choose Your Tools for Developing and Deploying Changes
SEE ALSO:
Choose Your Tools for Developing and Deploying Changes USER PERMISSIONS
29
Sandboxes: Staging Environments for Customizing and Choose Your Tools for Developing and Deploying Changes
Testing
Note: The Ant Migration Tool is a free resource provided by Salesforce to support its users and partners, but is not considered
part of our Services for purposes of the Salesforce Main Services Agreement.
SEE ALSO:
Ant Migration Tool Guide
Choose Your Tools for Developing and Deploying Changes
Available in Enterprise,
SEE ALSO: Performance, Professional,
Change Sets Unlimited, and
Database.com Editions
Choose Your Tools for Developing and Deploying Changes
30
Sandboxes: Staging Environments for Customizing and Connect Organizations for Deployment
Testing
31
Sandboxes: Staging Environments for Customizing and Connect Organizations for Deployment
Testing
Note: This illustration describes one possible code migration path. Your department must create its own policies for orgs to send
and receive change sets to one another.
SEE ALSO:
Deploy a Change Set
Viewing Available Deployment Connections
Authorizing a Deployment Connection
Viewing Details of a Deployment Connection
SEE ALSO:
Viewing Available Deployment Connections
Viewing Details of a Deployment Connection
Deployment Connections for Change Sets
32
Sandboxes: Staging Environments for Customizing and Connect Organizations for Deployment
Testing
Name
A list of orgs that have deployment connections to the org you are currently logged into. Click the name of an org to view more
information about the connection.
Description
A brief description of the connected orgs.
Type
The type of org you are connected to. Possible values are Production, Full Copy Sandbox, Configuration Only Sandbox, and Developer
Sandbox.
Upload Authorization Direction
The arrows show the direction in which uploads can occur. A broken line means that no change sets are authorized in either direction.
To authorize the connected org to send you inbound change sets, edit the deployment connection for this org. If you want to send
outbound change sets to a connected org, the administrator for that org must edit the connection for that org.
SEE ALSO:
Authorizing a Deployment Connection
Viewing Details of a Deployment Connection
Deployment Connections for Change Sets
SEE ALSO:
Authorizing a Deployment Connection
Viewing Available Deployment Connections
Deployment Connections for Change Sets
33
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
Change Sets
Use change sets to send customizations from one Salesforce org to another. For example, you can
EDITIONS
create and test a new object in a sandbox org, then send it to your production org using a change
set. Change sets can contain only modifications you can make through the Setup menu. For example, Available in: both Salesforce
you can’t use a change set to upload a list of contact records. Change sets contain information Classic and Lightning
about the org. They don’t contain data, such as records. Experience
When you want to send customizations from your current org to another org, create an outbound
Available in Enterprise,
change set. Once you send the change set, the receiving org sees it as an inbound change set. Performance, Professional,
Sending a change set between two orgs requires a deployment connection. Change sets can only Unlimited, and
be sent between orgs that are affiliated with a production org. For example, a production org and Database.com Editions
a sandbox, or two sandboxes created from the same org can send or receive change sets.
USER PERMISSIONS
IN THIS SECTION:
To edit deployment
Permission Sets and Profile Settings in Change Sets connections:
Developers can use permission sets or profile settings to specify permissions and other access • Deploy Change Sets
settings in a change set. When deciding whether to use permission sets, profile settings, or a AND
combination of both, consider the similarities and differences.
Modify Metadata
Components Available in Change Sets Through Metadata API
The components available for a change set vary by experience and edition. Also, some Functions
components require corresponding features to be enabled in your Salesforce org. To use outbound change
Change Sets Implementation Tips sets:
• Create and Upload
Review these tips before you implement your change sets.
Change Sets
Change Sets Best Practices To use inbound change sets:
Review these best practices about dependencies, validation, and access settings. • Deploy Change Sets
Deploy Inbound Change Sets AND Modify Metadata
Through Metadata API
An inbound change set is a change set that has been sent from another Salesforce org to the Functions
org you are logged in to. A change set must be deployed for the changes to take effect. You
can deploy the contents of an inbound change set as a whole but not on a
component-by-component basis.
Upload Outbound Change Sets
An outbound change set is a change set created in the Salesforce org in which you are logged in and that you want to send to another
org. You typically use an outbound change set for customizations created and tested in a sandbox and that are then sent to a
production org.
SEE ALSO:
Deployment Connections for Change Sets
Special Behavior in Deployments
Release Management Video: From Sandbox to Production How To Series (Salesforce Classic)
34
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
• Keep in mind that by default, change set deploys enable dependencies. For example, if
your change set contains a custom profile with Lead Conversion enabled, Lead object
permissions are enabled.
Included permissions and settings that • Apex class access • Assigned apps
require supporting components
• Visualforce page access • Custom object permissions
• Custom field permissions
• Apex class access
• Visualforce page access
For Visualforce page access and Apex class access, always include supporting components in the change set.
35
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
Note: Login IP ranges included in profile settings overwrite the login IP ranges for any matching profiles in the target org.
SEE ALSO:
Deploy Inbound Change Sets
Upload Outbound Change Sets
Change Sets Best Practices
Note:
• If you create or modify components unavailable in a change set, you can’t send those components from one org to another
in a change set. In this case, migrate the changes manually by repeating the steps you performed when you created or modified
the component.
• By default, list views are visible to all users when you deploy a change set. You can deploy a change set with Restricted Visibility,
or change the visibility in the destination org if necessary.
• Deployed custom tabs are hidden by default for all users. They’re visible only if the change set also contains profiles that set
the visibility property appropriately. Professional Edition orgs are an exception—deployed custom tabs in those orgs are always
visible by default.
• Reports stored in the My Personal Custom Reports folder (private reports) don’t appear in the list of reports that can be added
to the change set. Reports stored in the Unfiled Public Reports folder appear in the list of reports that can be added to the
change set, but they aren’t deployed even if added to the change set. To deploy a private or unfiled report using a change set,
first copy or move the report to a different report folder.
36
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
• Approval Process
• Asset File
• Assignment Rule
• Assistant Recommendation Type
• Aura Component Bundle
• Auth. Provider
• Auto-Response Rule
• Bot
• Button or Link
• CORS Whitelist Origin
• Call Center
• Campaign Influence Model
• Channel Menu Deployment
• Chatter Extension
• Classic Letterhead
• Communication Channel Layout
• Compact Layout
• Content Security Policy Trusted Site
• Custom Data Type
• Custom Field
• Custom Help Menu Section
• Custom Index
• Custom Label
• Custom Metadata Type
• Custom Notification Type
• Custom Object
• Custom Permission
• Custom Report Type
• Custom Setting
• Dashboard
• Data Service
• Digital Experience
• Digital Experience Bundle
• Document
• Duplicate Rule
• EclairNG Map GeoJson
• Email Service
• Email Template (Classic and Lightning, including templates made in Email Template Builder)
• Embedded Service Deployment
• Entity Implements
37
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
• Escalation Rule
• Event Subscription
• External Credential
• Extension
• External Data Source
• External Service Registration
• Field Mapping
• Field Set
• Flow Definition
• Folder
• Global Value Set
• Group
• Home Page Component
• Home Page Layout
• Inbound Network Connection
• Lightning Bolt
• Lightning Community Template
• Lightning Community Theme
• Lightning Experience Theme
• Lightning Message Channel
• Lightning Page
• Lightning Web Component Bundle
• List View
• Managed Content Type
• Matching Rule
• Microsoft® Outlook® Web App Domain
• Named Credential
• Network
• Outbound Network Connection
• Page Layout
• Path Assistant
• Permission Set
• Permission Set Group
• Platform Cache Partition
• Platform Event Channel
• Platform Event Channel Member
• Platform Event Subscriber Configuration
• Post Template
• Prompt
• Queue
38
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
• Recommendation Strategy
• Record Type
• RecordAction Deployment
• Remote Site
• Report
• Reporting Snapshot
• Restriction Rule
• Role
• S-Control
• Scoping Rule
• Security Custom Baseline
• Send Action
• Sharing Criteria Rule
• Sharing Owner Rule
• Site.com
• Static Resource
• Tab
• Transaction Security Policy
• User Provisioning Config
• Validation Rule
• Visualforce Component
• Visualforce Page
• Whitelisted URL for Redirects
• Workflow Email Alert
• Workflow Field Update
• Workflow Outbound Message
• Workflow Rule
• Workflow Task
• Zone
IN THIS SECTION:
Restrictions for Approval Processes in Change Sets
Understand these restrictions before you include approval processes in change sets.
SEE ALSO:
Validate a Change Set
Create an Outbound Change Set
Select Components for an Outbound Change Set
Special Behavior in Deployments
39
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
40
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
page. An example of a component with many dependencies is a custom field that belongs to a custom object with 2,500 dependent
components.
Action overrides in change sets
An action override is pulled into a change set if the override is associated with a custom object or app that is included in the change
set.
Because you can’t include standard objects in a change set, you can’t use a change set to deploy an action override associated with
a standard object.
SEE ALSO:
Change Sets Best Practices
Special Behavior in Deployments
Important: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain
terms to avoid any effect on customer implementations.
Deploy all dependent components
Make sure each outbound change set contains all interdependent components that don't exist in the target org. If you try to deploy
a component that refers to another component missing from the target org and from the change set, the deployment fails.
Change sets give you fine-grained control over what you deploy. For example, you can migrate custom fields individually. To deploy
a custom object and all of its fields, you must add the custom object and every field to the change set; adding just the custom object
to the change set won't cause deployment to fail, but results in an empty custom object.
Add permissions and access settings to outbound change sets
Adding profiles or permission sets to outbound change sets allows administrators to migrate permissions for users so they can access
the new functionality. There are significant differences between permission sets and profile settings in change sets. For details, see
“Permission Sets and Profile Settings in Change Sets on page 35”.
Clone a change set to add dependent components to an uploaded change set
After you upload a change set, you can't change its contents. If you need to add dependent components to a change set you already
uploaded, clone the change set, add the dependent components, and then upload it again.
Use distinct names for global publisher layouts and Outlook publisher layouts
When you add page layouts to an outbound change set, the type for global publisher layouts and Outlook publisher layouts isn’t
displayed. Make sure that you provide unique names for your global publisher layouts and Outlook publisher layouts so that you
can differentiate them in an outbound change set.
Plan deployments around maintenance schedule
Plan your deployment activities around the maintenance schedule for both your production and sandbox orgs. Some features require
information from your production org when accessed from a sandbox. In addition, the originating org is locked while validating an
outbound change set, and the target org is locked while deploying an inbound change set. (When change sets lock an org, you can
still read and write data to the org, but you can’t make any setup changes that would modify the metadata.)
Validate change sets before deployment
You can perform a test deployment of an inbound change set to view the success or failure messages that would occur with an
actual deployment. This is a good idea if you are planning a deployment on a schedule (for example during low-use hours) and want
to determine if the deployment will succeed ahead of time. However, you don't need to perform a test deployment every time you
deploy, as this process takes time to complete and the org is locked for the duration. (You can still read and write data to the org,
41
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
but you can’t make any setup changes that would modify the metadata.) To test deploy an inbound change set, click its name and
then click Validate.
View component details
You can view the XML representation of a component after you upload an outbound change set or before you deploy an inbound
change set.
Limit change sets to 10,000 files
Change sets are limited to 10,000 files. If your change set exceeds this limit, you can create separate change sets for email templates,
dashboards, and reports. These components are often the most numerous and have fewer dependencies.
Delete or rename components using the Web interface
You can't use change sets to delete or rename components. To delete components, use the Web interface on the target org. To
rename a component, first delete the component on the target org and then upload the new component in a change set.
Note: Editing the sharing settings for objects in a master-detail relationship, such as changing org-wide defaults from Controlled
by Parent to Public Read/Write, is considered deleting a component.
Consider possible delays in deployment time when a change set includes field type changes
If a change set includes changes to custom field types, the deployment time might be delayed by an extended period of time
because custom field type changes might require changes in a large number of records. To avoid long delays in deployment, an
alternative is to apply the field type change manually after the change set is deployed.
Plan for tests to run in the target org
When a change set is deployed to a production org, all local Apex tests in that org are run by default if you’re deploying any Apex
classes or triggers. If the target org is a sandbox, however, tests aren’t automatically run.
SEE ALSO:
Change Sets Implementation Tips
Special Behavior in Deployments
42
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
SEE ALSO:
Change Sets
Note: Inbound change sets are permanently deleted six months after the change set is uploaded.
SEE ALSO:
Viewing Change Set Details
Validate a Change Set
Deploy a Change Set
SEE ALSO:
Viewing Inbound Change Sets
Validate a Change Set
Deploy a Change Set
Note: We recommend starting a validation during off-peak usage time and limiting changes to your org while the validation is
in progress. The validation process locks the resources that are being deployed. Changes you make to locked resources or items
related to those resources while the validation is in progress can result in errors.
1. From Setup, enter Inbound Change Sets in the Quick Find box, then select Inbound Change Sets.
2. Click Validate next to the change set you want to validate.
43
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
To review the change set before validating it, click the name of the change set to view its detail page. When ready, click Validate.
Note: If the change set has been deleted from its source org, the Validate link isn’t available. If a deployment of the change
set is in progress, the Validate link isn’t available until after the deployment completes.
Note: If you change a field type from Master-Detail to Lookup or vice versa, the change isn’t supported when using the Validate
option to test a deployment. This change isn’t supported for test deployments to avoid data loss or corruption. If a change that
isn’t supported for test deployments is included in the deployment package, the test deployment fails and issues an error.
If your deployment package changes a field type from Master-Detail to Lookup or vice versa, you can still validate the changes
before you deploy to production. Perform a full deployment to another test sandbox. A full deployment includes a validation of
the changes as part of the deployment process.
Change sets that have been successfully validated might qualify for a quick deployment. For more information, see Quick Deployments.
SEE ALSO:
Viewing Inbound Change Sets
Viewing Change Set Details
Deploy a Change Set
Note: If the change set has been deleted from its source org, the Deploy link isn’t available. If a deployment of the change
set is already in progress, the Deploy link isn’t available until after the deployment completes.
Alternatively, you can perform a quick deployment to shorten your deployment time to production. Change sets that have been
successfully validated can sometimes qualify for a quick deployment. For more information, see Quick Deployments.
A change set is deployed in a single transaction. If the deployment is unable to complete for any reason, the entire transaction is rolled
back. After a deployment completes successfully, all changes are committed to your org and the deployment can’t be rolled back.
Note: The Lightning Platform requires that at least 75% of your code is covered by unit tests before you can deploy it to a
production org. Ideally, strive for 100% coverage. The code coverage restriction isn’t enforced for sandbox or Developer Edition
orgs.
Deployment Options
To prevent a deployment from failing when components are referenced by Apex jobs, in the Deployment Settings page, click Allow
deployments of components when corresponding Apex jobs are pending or in progress, and then click Save. This option lets
you deploy components that are referenced by Apex jobs—including scheduled jobs, batch jobs, and future methods— that are pending
or in progress. This option applies to change sets and deployments that are started through the Metadata API.
Note:
• Enabling this option can sometimes cause Apex jobs to fail due to unsupported changes.
44
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
• This option doesn’t affect editing and saving Apex code in the Salesforce user interface (in Setup or the Developer Console).
These operations fail when there are active jobs associated with the Apex class.
SEE ALSO:
Viewing Inbound Change Sets
Viewing Change Set Details
When Change Sets Become Unavailable
Special Behavior in Deployments
Monitor Deployments of Change Sets
SEE ALSO:
Deploy a Change Set
Deployment Connections for Change Sets
Monitor Deployments
Note: A delay can occur between when the source sandbox is deleted or refreshed and when the target org shows the
change set as unavailable. The length of the delay depends on how long it takes internal database cleanup processes to
complete. When the source sandbox is deleted or refreshed, assume that the change set is no longer available for deployment
in the target org.
45
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
Tip: To help ensure a smooth deployment, review information about permission sets and profile settings in change sets.
After you upload a change set, its status becomes closed, and you can’t make changes to its components. Also, the components in a
closed change set don’t get refreshed. To redeploy the same set of components, clone the change set. The cloned change set includes
the latest changes to its components source. You can add and remove components in the cloned change set. Cloning change sets is
helpful during the iterative phases of a project.
IN THIS SECTION:
Select Components for an Outbound Change Set
View and Add Dependent Components to a Change Set
A dependency is a relationship where one or more components must exist for another component to exist. Add dependent
components to a change set, unless the dependent components exist in every org where this change set is deployed.
Upload an Outbound Change Set
When you’ve assembled the components in a change set, you can upload it to another Salesforce org. After you upload a change
set, you can't edit it or recall it.
Create an Outbound Change Set
An outbound change set is a change you send from the Salesforce org you are logged into to another org.
Clone an Outbound Change Set
You can create a copy of an existing change set by cloning it.
Delete an Outbound Change Set
Outbound Change Set Validation Errors
Uploading Change Sets During Staggered Salesforce Service Upgrades
SEE ALSO:
Permission Sets and Profile Settings in Change Sets
Deploy Inbound Change Sets
Change Sets
46
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
2. In the Change Sets list, click the name of a change set, or create a new one.
3. Click Add to add components.
4. Choose the type of component and the components you want to add, and then click Add to Change Set.
5. Click Add Profiles to add profile settings to the change set.
Note: You can’t add profile settings to a change set in Professional Edition.
Note: Dependent components rely on the existence of other components. Unless you’re certain that the dependent
components exist in every org this change set will be deployed to, add dependent components to the change set.
SEE ALSO:
Create an Outbound Change Set
View and Add Dependent Components to a Change Set
Components Available in Change Sets
Warning: If your change set contains more than 2500 dependencies, you can see only the first 2500 in the Component
Dependencies page.
SEE ALSO:
Select Components for an Outbound Change Set
Upload an Outbound Change Set
Components Available in Change Sets
Note: If the change set doesn’t contain any components, the Upload link isn’t available.
47
Sandboxes: Staging Environments for Customizing and Change Sets
Testing
3. Select the org you want to send the change set to.
4. Click Upload.
Note: Outbound change sets expire six months after upload. Change sets are permanently deleted when they expire.
SEE ALSO:
Uploading Change Sets During Staggered Salesforce Service Upgrades
Create an Outbound Change Set
SEE ALSO:
Clone an Outbound Change Set
Outbound Change Set Validation Errors
SEE ALSO:
Create an Outbound Change Set
SEE ALSO:
Create an Outbound Change Set
48
Sandboxes: Staging Environments for Customizing and Modify Metadata Through Metadata API Functions Permission
Testing
SEE ALSO:
Create an Outbound Change Set
Upload an Outbound Change Set
SEE ALSO:
Upload an Outbound Change Set
Important: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain
terms to avoid any effect on customer implementations.
49
Sandboxes: Staging Environments for Customizing and Special Behavior in Deployments
Testing
The behaviors listed in the Metadata API section apply if you’re using the Ant Migration Tool or Salesforce Extensions for Visual Studio
Code.
50
Sandboxes: Staging Environments for Customizing and Special Behavior in Deployments
Testing
• In production orgs, you can enable the setting to deploy a new active version of a process or flow via change sets or Metadata
API. The setting doesn't appear in non-production orgs (such as scratch, sandbox, and developer orgs), because you can always
deploy a new active version. See Deploy Processes and Flows as Active.
Permissions
See Permission Sets and Profile Settings in Change Sets on page 35.
Page Layout
A deployment containing a profile and record type, but not the assigned page layout for that record type, removes the existing
layout assignment from the profile for that record type. Always include all page layouts for all required record types in the change
set.
Picklist Values
Values for a picklist field in a target that aren’t included in the change set are set to inactive.
For example, if the target’s picklist includes an active value of 1, and the change set’s picklist doesn’t include 1 as a value, 1 changes
from active to inactive in the target.
Sharing
Simultaneously updating the sharingModel field for an object and adding a new owner-based sharing rule isn’t supported.
You can add an owner-based sharing rule when the overall default is public, and then update the sharingModel, which results
in a single sharing recalculation. You can deploy a criteria-based or guest user sharing rule and changes to the sharingModel
field together using change set components.
Metadata API
Apex Classes and Apex Triggers
By default, changes to Apex code that has Apex jobs pending or in progress can’t be deployed. To deploy these changes, take one
of these steps.
• Cancel Apex jobs before deploying changes to Apex code. Reschedule the jobs after the deployment.
• Enable deployments with Apex jobs in the Salesforce user interface in the Deployment Settings page.
Approval Processes
• To use approval processes on Salesforce Knowledge articles with the Metadata API, the article type must be deployed. For article
version (_kav) in approval processes, the supported action types are: Knowledge Action, Email Alert, Field Update, and Outbound
Message.
• If the approval process references any post templates that contain custom fields, resave those post templates in the originating
organization before adding them to the change set. From Setup, in the Quick Find box, enter Post Templates, and then
select Post Templates. For each post template, click Edit and then Save.
• The metadata doesn’t include the order of active approval processes. It can be necessary to reorder the approval processes in
the destination after deployment.
• If you change the Unique Name of an approval process that previously was included in a change set and deployed in another
organization, and you resend the approval process via a change set, a new approval process is created upon deployment in the
other organization. The previously deployed approval process isn’t modified.
Authentication Providers
Beginning in November 2022, if a change set includes an authentication provider with a consumer secret defined, the consumer
secret is changed to a placeholder value. You must insert the consumer secret manually during change set deployment. Change
sets generated before November 2022 can deploy successfully without modifications throughout the Winter ’23 release.
Custom Fields
Starting in API version 30.0, when deploying a new custom field, the default values for the editable and readable fields in
profile field permissions are false. To override the default values, include field permissions for the new field in your profiles.
51
Sandboxes: Staging Environments for Customizing and Special Behavior in Deployments
Testing
Custom Objects
Simultaneously inserting a custom object, updating the sharingModel field for an object, and adding a new owner-based
sharing rule isn’t supported. Instead, three separate deployments are required. First deploy the custom object, then deploy the
updated sharingModel for the object, and then deploy the new owner-based sharing rule. You can update the sharingModel
field and add a criteria-based or guest user sharing rule in one deployment.
Connected App
• You can’t set the consumerKey in Metadata API. It’s included in a retrieve operation for informational purposes. If you try to
move the connected app to another org, you must remove the consumerKey from the .zip file before the deployment to
an org. A new key is generated in the destination.
• Mobile settings of connected apps aren’t supported in change sets and must be manually migrated.
Groups
Members of the public group aren’t migrated when you deploy the group type.
Master-Detail Relationships
A Metadata API deployment that includes Master-Detail relationships deletes all detail records in the Recycle Bin in these cases.
1. For a deployment with a new Master-Detail field, soft delete (send to the Recycle Bin) all detail records before proceeding to
deploy the Master-Detail field, or the deployment fails. During the deployment, detail records are permanently deleted from the
Recycle Bin and can’t be recovered.
2. For a deployment that converts a Lookup field relationship to a Master-Detail relationship, detail records must reference a master
record or be soft-deleted (sent to the Recycle Bin) for the deployment to succeed. But a successful deployment permanently
deletes any detail records in the Recycle Bin.
Page Layout
A deployment containing page layout assignments replaces all existing page layout assignments in the destination org with the
assignments specified in the .zip file. Existing page layouts in the org disappear if they’re not included in the .zip file. Always include
all page layouts for all required record types in the .zip file.
Picklist Values
Values for a picklist field in a target org that aren’t included in the metadata are set to inactive.
For example, if the target org has a picklist that includes an active value of 1, and the metadata doesn’t include a picklist value of
1, 1 changes from active to inactive in the target org.
Profiles
If a package includes a profile with a name that doesn’t exist in the target, a new profile is created with that name. If the deployed
profile doesn’t specify any permissions or settings, the resulting profile consists of all the permissions and settings in the Standard
Profile.
Note: Custom fields on the ContentVersion object are available to all profile users. When you export profile metadata, all
custom fields are exposed.
Sharing
• Using API version 29.0, you can’t change the sharingModel of an object using Metadata API. Manually change the target
through the user interface.
• Starting with API version 30.0, you can change the sharingModel of an object for internal users using Metadata API and
the user interface.
• Simultaneously updating the sharingModel field for an object and adding a new owner-based sharing rule isn’t supported
in Metadata API. You can add an owner-based sharing rule when the overall default is public, and then update the
sharingModel, which would result in a single sharing recalculation. You can deploy a criteria-based or guest user sharing
rule and changes to the sharingModel field together using the Metadata API.
52
Sandboxes: Staging Environments for Customizing and Monitor Deployments
Testing
Workflow
Test mode for flow triggers isn’t supported in the Metadata API. If you want a flow trigger to run the latest flow version when an
administrator causes the workflow rule to fire, enable test mode via the user interface after deployment.
SEE ALSO:
Deploy a Change Set
Change Sets
Components Available in Change Sets
Working with the Zip File
Monitor Deployments
You can monitor deployments that are in progress, check which deployments are waiting for
EDITIONS
execution, and view the results of completed deployments on the Deployment Status page.
This page lists all deployments—change sets, Metadata API-based deployments, including Available in: both Salesforce
deployments started from the Salesforce Extensions for Visual Studio Code and the Ant Migration Classic (not available in all
Tool, and package installations. orgs) and Lightning
Experience
The size and complexity of the metadata components affect the deployment time. To track the
status of deployments that are in progress or have completed in the last 30 days, from Setup, enter Available in: Enterprise,
Deployment in the Quick Find box, then select Deployment Status. Deployments are Performance, Unlimited,
listed in different sections depending on their status. Developer, and
Database.com Editions
After all components have been deployed without errors, Apex tests start executing, if required or enabled. A second chart shows how
many Apex tests have run out of the total number of tests and the number of errors returned. In addition, the chart shows the name of
the currently running test. For example, in the following chart, 77 tests have completed execution out of a total of 120, and 1 test failed.
53
Sandboxes: Staging Environments for Customizing and Monitor Deployments
Testing
Field Description
Name The change set name or a unique identifier that’s used to track the Metadata API deployment. For a Metadata API
deployment, this value is returned by the deploy() call.
Start Time The date and time when the deployment actually started, not the time the request was queued. This value is the
time the deployment Status is set to In Progress.
Validated The date and time when the deployment validation finished.
If the current deployment has errors, you can view these errors before the deployment finishes by clicking View Errors.
Pending Deployments
You can initiate multiple deployments, but only one deployment can run at a time. The other deployments will remain in the queue
waiting to be executed after the current deployment finishes. Queued deployments are listed under Pending Deployments in the order
they will be executed.
Deployment Validations
A deployment validation is a deployment that is used only to check the results of deploying components and is rolled back. A validation
doesn't save any deployed components or change the Salesforce org in any way. You can determine whether a deployment is a validation
only (Validate) or an actual deployment (Deploy) by inspecting the information for pending deployments or the Status column of
deployments in the Failed and Succeeded sections.
If a validation completed successfully in the last 10 days, and all tests passed with sufficient code coverage, you can perform a quick
deployment by deploying this validation to production without running tests. See Quick Deployments.
Canceling a Deployment
You can cancel a deployment while it’s in progress or in the queue by clicking Cancel next to the deployment. The deployment then
has the status Cancel Requested until the deployment is completely canceled. A canceled deployment is listed in the Failed
section.
Completed Deployments
Deployments that have finished are listed either in the Failed or Succeeded sections depending on their status.
54
Sandboxes: Staging Environments for Customizing and Monitor Deployments
Testing
Deployments that have finished but failed, and deployments that were canceled are listed in the Failed section. No changes were
committed to the Salesforce org for these deployments because files were missing, components had errors, tests failed, or the deployment
was canceled.
Deployments that have completed successfully or have partially succeeded are listed in the Succeeded section. Only deployments to a
non-production org can partially succeed. These are deployments that have the rollbackOnError field set to false in the
deployment options and have errors in a subset of components. In a partially succeeded deployment, the failed components aren’t
committed and the remaining components are committed to the org.
To get more details about a deployment, click View Details next to a deployment. Use the information on the Deployment Details page
to view the errors and troubleshoot problems for a failed or partially succeeded deployment. The Deployment Details page includes the
error messages that occurred during the deployment, errors for Apex tests with stack trace information, code coverage warnings, and
information about slow tests. For a successful deployment, the Deployment Details page shows information about the deployment
including how many components were deployed and how many Apex tests were run.
Deployment Status
The Status column for completed deployments in the Failed and Succeeded sections lists the type and status of a deployment and
has two parts:
• The prefix indicates whether the deployment is a validation only (Validate:) or an actual deployment (Deploy:).
• The second part of the status value contains the status of the deployment: Failed or Canceled for failed deployments, Succeeded
for succeeded deployments, or Partially Succeeded for partially succeeded deployments.
Quick Deployments
As part of a deployment, all Apex tests are run in production. If the production org contains many Apex tests, executing the tests can
be time consuming and can delay your deployment. To reduce deployment time to production, you can perform a quick deployment
by skipping the execution of tests. Quick deployments are available for change sets and Metadata API components when the following
requirements are met.
• The components have been validated successfully for the target environment within the last 10 days.
• As part of the validation, Apex tests in the target org have passed.
• Code coverage requirements are met.
– If all tests in the org or all local tests are run, overall code coverage is at least 75%, and Apex triggers have some coverage.
– If specific tests are run with the Run specified tests test level, each class and trigger that was deployed is covered by at least
75% individually.
A validation is a deployment that’s used only to check the results of deploying components and doesn’t save any components in the
org. A validation enables you to view the success or failure messages that you would receive with an actual deployment. You can validate
change sets or metadata components through the API or the Ant Migration Tool.
To learn how to validate a change set, see Validate a Change Set in the Salesforce Help.
To validate components with the Ant Migration Tool, set the checkOnly option to true in the deploy target. See Deploying Changes
to a Salesforce Organization in the Ant Migration Tool Guide.
Performing a Quick Deployment through the User Interface or the API
To perform a quick deployment, first run a validation-only deployment with Apex test execution on the set of components that you
need to deploy. If your validation succeeds and qualifies for a quick deployment, you can start a quick deployment.
You can quick-deploy validated change sets and Metadata API components in the user interface. In the Deployment Status page, deploy
a recent validation by clicking Quick Deploy next to your validation or on the validation’s detail page. This button appears only for
qualifying validations.
55
Sandboxes: Staging Environments for Customizing and Monitor Deployments
Testing
To learn how to perform a quick deployment of change sets and run specific tests, check out this video: Release Management: Deploy
Changes Efficiently with Quick Deployments & Test Levels (Salesforce Classic).
Alternatively, you can start a quick deployment through Metadata API or the Ant Migration Tool for Metadata API components (excluding
change sets). For Metadata API, call deployRecentValidation() and pass it the validation ID. For the Ant Migration Tool, use
the <sf:deployRecentValidation> task.
Note: Quick Deploy is enabled for recent validations in which Apex tests have executed successfully and code coverage requirements
have been met. Note the following.
• In production, quick deployments are supported for validations that meet the criteria. You can deploy recent validations of
change sets and Metadata API components (including components validated by using the Ant Migration Tool).
• In sandbox, Quick Deploy is supported only for validations that explicitly enable test execution (for example, by choosing a
test option when validating inbound sets or through the testLevel parameter for the Migration Tool). By default, Apex
tests aren’t required nor ran in sandbox deployments.
• If you perform a deployment after a validation, whether through Quick Deploy, a package installation, or a regular deployment,
all validations no longer qualify for quick deployment. Revalidate the set of components to quick-deploy.
56
Sandboxes: Staging Environments for Customizing and Secure Your Sandbox Data with Salesforce Data Mask
Testing
SEE ALSO:
Deploy Inbound Change Sets
Upload Outbound Change Sets
Metadata API Developer’s Guide
Ant Migration Tool Guide
IN THIS SECTION:
Recommended Data to Mask
We recommend that you mask fields that typically contain Personally Identifiable Information (PII) or other sensitive data.
Levels of Masking
Data Mask delivers different levels of masking to help keep your sensitive production data private in a sandbox. You can replace
sensitive data in your sandboxes with random characters, replace sensitive data with similarly mapped words, or eliminate it.
Install the Managed Package in a Production Org
Data Mask is a managed package that you install in your production org. You then run the masking process from any new sandbox
created from the production org. To install and use Data Mask, you must enable certain features in your production org and specify
user permissions. After you install the package, Salesforce automatically upgrades it with new features and bug fixes. Data Mask
currently supports API version 50.0.
Create, Edit, or Clone a Data Mask Configuration
You can configure the masking process in one of two ways. Configure it in production, then when a sandbox is created or refreshed,
the configuration appears in the sandbox. Or, configure the masking process in an existing sandbox.
57
Sandboxes: Staging Environments for Customizing and Recommended Data to Mask
Testing
Levels of Masking
Data Mask delivers different levels of masking to help keep your sensitive production data private in a sandbox. You can replace sensitive
data in your sandboxes with random characters, replace sensitive data with similarly mapped words, or eliminate it.
58
Sandboxes: Staging Environments for Customizing and Install the Managed Package in a Production Org
Testing
an entry such as Susan Badger, [email protected] in production would transform into vqiz olmmt,
[email protected] in a sandbox. This transformation enables business processes to function, but preserves the
confidentiality in the production environment.
Warning: Deletion can remove the ability to test some business processes, so be selective in choosing privacy assurance methods.
Once data is deleted from a sandbox, it can’t be restored.
2. Follow the standard process for installing a managed package using the Data Mask package link.
3. Assign these permissions and profiles to your user in your production org.
59
Sandboxes: Staging Environments for Customizing and Create, Edit, or Clone a Data Mask Configuration
Testing
Note: If your user doesn’t have this permission or write access for the objects being masked, the masking process still
runs, but those objects are not masked.
Note: If you manually add an additional user to your sandbox org who will run data mask, assign these same permissions
and profiles for that user.
4. Assign the Data Mask User permission set license to your user.
5. Assign the Data Mask permission set included in the installed package to your user.
IN THIS SECTION:
Install in Existing Sandboxes
To use Data Mask in sandboxes created before you installed the managed package in your production org, additional steps are
required.
SEE ALSO:
View and Manage Your Permission Set Licenses
Install a Package
“View All” and “Modify All” Permissions Overview
Assign a Permission Set License to a User
Assign Permission Sets to a Single User
SEE ALSO:
Install the Managed Package in a Production Org
60
Sandboxes: Staging Environments for Customizing and Create, Edit, or Clone a Data Mask Configuration
Testing
1. To create a masking configuration and select which data to mask, go to the App Launcher and click the Data Mask app. You can
edit or clone a previously saved masking configuration or start from scratch.
2. On the Home tab, select an option:
• To create a mask, click New Mask.
• To edit an existing mask, click the dropdown for the masking configuration and select Edit.
• To clone an existing configuration and use that as the starting point, click the dropdown and then select Clone.
IN THIS SECTION:
Org-Level Settings
Configure settings for masking data outside of objects and fields.
Set Masking Rules
Set masking rules for standard and custom objects in your sandbox org.
Set Filter Criteria
Target specific data records for masking to meet business requirements and security goals.
SEE ALSO:
Levels of Masking
Org-Level Settings
Configure settings for masking data outside of objects and fields.
Choose whether to Anonymize Case Comments, Delete All Email, or Delete All Chatter.
• Anonymize Case Comments: Replace all case comments with a 5 character random value. Business processes that the customer
has in place around Case Comments are not be affected, but any potentially sensitive data is anonymized. For example, a case
comment, "This customer is experiencing trouble updating their contact information and wants to change their email address to
“[email protected]" is replaced with XYZ42.
• Delete All Email: Delete all data in the EmailMessage object in the sandbox org. EmailMessages that reference records that don't
exist are not deleted. Such orphaned emails need to be purged in the production org before creating your sandbox.
Note: See this Knowledge Article for more information about purging emails.
• Delete All Chatter: Delete all chatter data in the sandbox org.
Important: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain
terms to avoid any effect on customer implementations.
Important: A user must have view access on objects to configure masking and modify access on objects and related fields to
mask. A particular field may not be available for masking because of its type (currently picklist, formula, checkbox, and roll-up
summary are not supported). External objects, platform events, and BigObjects are not supported.
61
Sandboxes: Staging Environments for Customizing and Create, Edit, or Clone a Data Mask Configuration
Testing
Important: Choose the objects and the masking type to apply to its fields carefully. The choices that you make determine the
speed of data mask completion.
The following masking types are available:
Replace with Random Value Replaces sensitive data with random Percent, Number, Currency, Geolocation
numbers that are readable, but not
recognizable. Specify minimum and
maximum values for the field.
Replace all with True/False Replaces all boolean checkbox data with Checkbox
either True or False
Replace From Library Replaces sensitive data with random but Text, Short Text, Email, Address
recognizable data using one of these
selected libraries:
• First Name
• Last Name
• Company Name
• Email
• Street
• City
• Country
• Country (Abbr.)
• State
• Postal Code
• Phone Number
• Social Security Number
For text or text area fields that have
duplicate matching rules defined, enable
Unique to prevent unintended reuse of
library words or random characters. Data
Mask appends the record ID to make the
masked fields unique.
Replace using Pattern Replaces sensitive data with data generated Text, Email, Address
using a defined pattern. The pattern must
follow the following rules:
• %c = replace with lower-case letter (a-z)
62
Sandboxes: Staging Environments for Customizing and Create, Edit, or Clone a Data Mask Configuration
Testing
Delete Deletes sensitive data entirely, leaving an Text, Phone, Date, Long Text Area, Email,
empty data set Fax, Date/Time, Geolocation, Address,
Percent, Number, Currency, URL
To mask objects that have multiple records with master detail or lookup relationships to the same record, select Run in Serial Mode.
Use serial mode only if Data Mask fails to execute successfully. For more information, see Data Mask Considerations.
3. Click Save.
63
Sandboxes: Staging Environments for Customizing and Run Data Mask Job
Testing
INTEGER, DOUBLE is less than, is less than or equal to, is greater than, is greater than
or equal to, is null, is not null
4. Select the matching criteria. Matching criteria options are based on field type.
5. If necessary, add more conditions, and repeat steps 3 and 4.
6. o create a filter criteria, enter the condition logic. For example, 1 AND (2 OR 3).
7. Optionally, to preview your query in SOQL, click Query Preview.
64
Sandboxes: Staging Environments for Customizing and Run Data Mask Job
Testing
Last Run Aborted on <date> Status if job fails during the execution
Last Ran <date> with Error(s) Status if job runs with errors
3. To verify that the records are properly masked, manually spot check your sandbox data. Then you can grant more users access to
the sandbox.
The masking process runs asynchronously and can take several hours for large sandboxes. Data Mask disables the following automations
during execution:
• Triggers
• Workflow Rules
• Validation Rules
• Flows
• Field History Tracking
• Feed Tracking
Automations are re-enabled once execution is complete. If the Email Deliverability setting is set to All Emails, you receive an email when
the job completes.
To see more information about the masking process for each job, refer to the Run Logs tab in Data Mask.
IN THIS SECTION:
Stop Data Mask Job
You can stop a current running data mask job.
SEE ALSO:
Guidelines for Configuring Deliverability Settings for Emails Sent from Salesforce
Data Mask Considerations
Stop Data Mask Job
Important: Stop does not undo any masking that has already completed.
If a data mask job fails during execution and is fatally aborted, click the dropdown arrow for that masking configuration and select
Re-enable Automation to reactivate automations that were disabled by the data mask job.
65
Sandboxes: Staging Environments for Customizing and Data Mask Considerations
Testing
Important: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain
terms to avoid any effect on customer implementations.
Duplicate Rules
Masking certain records can be affected depending on duplicate rules set up for the object. Data masking skips records with existing
data that conflicts with any duplicate matching rules. It also skips if there is a large number of records to mask and if replacing the data
with library values inadvertently creates duplicates. To prevent skipping, you can configure a user profile that bypasses Duplicate Rules,
and you can run Data Mask from this profile.
66
INDEX
A T
Ant task for Apex 28 Tools for Apex 28–29
Apex
tools 28–29
67