# Administering Sandbox Vaults Sandbox Vaults are used to develop and test configuration changes, data migrations, and integrations, without affecting your production Vault and users. Sandbox Vaults are critical to an effective change control process. Creating a sandbox for a new project and refreshing your sandboxes often will help your organization avoid issues and delays when deploying changes in production. Vault Admins can create, refresh, and delete sandboxes through the Admin UI or Vault API. Sandbox administration options are available from the production Vault. When you log into sandbox Vaults, they will have a green banner to help you distinguish between your sandbox and production Vaults. The green Vault header in a sandbox Vault. You can remove this styling using the **SBX** button next to the Vault logo. Once removed, you must log out and log back in to get the styling back. Refreshing the page also returns the styling. This can be useful for taking screenshots in your sandbox Vaults when you want to simulate a user's actual experience. ## Sandbox Domains Veeva provides one sandbox domain and one production domain. User Acceptance Testing (UAT) Vaults should be in the sandbox domain. If you are testing domain-level settings, Veeva can provide an additional domain for that purpose. ## Sandbox Sizes & Limits {#sizes} Sandbox Vaults are available in the following sizes with corresponding limits: | Sandbox Size | Object Record Limit | Document Version Limit | Snapshots Included with Sandbox | Sandboxes Included in Production | | ------------ | -------------------------- | ------------------------ | :-----------------------------: | :-------------------------------: | | Small | 0 to 100,000 | 0 to 10,000 | two (2) | four (4) | | Medium | 100,000 to 1,000,000 | 10,000 to 100,000 | two (2) | two (2) | | Large | 1,000,000 to 10,000,000 | 100,000 to 1,000,000 | two (2) | zero (0) | | Very Large | 10,000,000 to 100,000,000 | 1,000,000 to 10,000,000 | two (2) | zero (0) | | Extra Large | 100,000,000 to 500,000,000 | 10,000,000 to 50,000,000 | two (2) | zero (0) | | Full | No Limit | No Limit | two (2) | one (1) | The limit on total object records excludes system-managed object records and configuration data. Sandbox Vaults that exceed these limits are blocked from creating new object records or documents. To remove this block, delete object records or document versions. Admins can then [recheck usage values][1] to ensure that the Vault is compliant. Each sandbox has a limit of 5GB of document templates, both active and inactive. If you create a sandbox from a Vault with more than 5GB, the resulting sandbox will not have any document templates copied to it.
### Sandbox Expiration Small sandboxes automatically expire after 30 days of inactivity. Vault sends an email warning to Vault Owners twice before sandbox deletion. Blocked or inactive sandbox Vaults display a warning on the _Name_ field on the **Admin > Deployment > Sandbox Vaults** page of the parent Vault. ### Viewing Usage Details {#usage} To view the usage details for a specific sandbox Vault, navigate to **Admin > Deployment > Sandbox Vaults** and click the Vault name. The limit usage values that appear here update once every 24 hours. The usage details of a sandbox Vault. To view the usage details of the sandbox Vault you're currently logged into, navigate to **Admin > Settings** and view the _License Information_. The limit usage values that appear here are initially zero (0) when you create or refresh the Vault. Click **Recheck Usage** to recalculate usage values. This action can be initiated up to 100 times in a 24-hour period. To view the specific objects and document versions that are consuming data, navigate to **Admin > Settings > Vault Data Usage Information**. ## Creating Sandbox Vaults {#create} Customers are entitled to four (4) _Small_, two (2) _Medium_, and one (1) _Full_ configuration sandbox Vaults for every production Vault. Prerelease Vaults do not count against these entitlements. If you require more sandboxes, you can place an add-on order with Veeva's finance team. Sandbox Vaults are always in your sandbox domain. ### How to Create Vaults To create a new sandbox Vault: 1. From your source Vault, navigate to **Admin > Deployment > Sandbox Vaults**. Source Vaults can be a production Vault or another Sandbox Vault with Sandbox allowances. 2. Under _Active Sandbox Vaults_, click **Create**. 3. Select whether to create a sandbox **From Vault** or **From Snapshot**. See details about sandbox snapshots. 4. Enter a **Name** for the new sandbox. See [details for Vault names][3]. 5. Select a **Size**. [See details about sandbox sizes and limits][2]. 6. Select a **Release**. See [details about sandbox release versions][4]. 7. Select a **Domain** for the new Vault. In most cases, there will only be one domain available. 8. Optional: Clear the **Vault Owner: Current User** checkbox. See [details about adding Vault owners][5]. 9. Click **Finish**. 10. Optional: If the source Vault contains more than 5GB of document templates, Vault displays a warning. Click **Continue** to proceed without copying any document templates, or **Cancel** to stop the sandbox creation process. 11. The creation process generally takes less than one hour, but may take up to eight hours. When complete, Vault sends you a notification. Expect additional time for sandbox creation requests during release periods. To ensure a successful, timely sandbox creation, you should avoid making requests 24 hours before and after scheduled releases. ### Vault Name {#name} When creating a new sandbox, the _Name_ value must follow these rules: * Must be unique across all sandbox Vaults for the current Vault and all Vaults in the domain; note that you may not be able to view all Vaults in the domain. * Special characters do not make the name unique, for example, _UAT:Sandbox_ and _UAT-Sandbox_ won't count as unique names * Names are not case sensitive, for example, _UAT\_Sandbox_ and _uat\_sandbox_ won't count as unique names ### Add Current User as Vault Owner {#owners} The **Vault Owner: Current User** setting adds the Vault Admin creating the sandbox as a Vault Owner in the sandbox Vault, using Cross-Domain User functionality. If you do not enable this setting, the Domain Admin users in the sandbox domain will become Vault Owners in the sandbox Vault. ## Managing Sandbox Allowances {#managing-sandbox-allowances} Manage sandbox allowances across all your sandboxes, including those created from another sandbox. The _Available Sandbox Vaults_ section lists the following sandbox limits and allowances: * **Size**: The sandbox size available. * **Available**: The total number of sandboxes available for creation or for granting to another sandbox allowance. * **Allowed**: The total number of sandbox entitlements granted to the current Vault. * **Temporary**: If enabled, any temporary sandbox allowances. The _Active Sandbox Vaults_ section provides sandbox details for all current sandboxes of which the current Vault is a direct or indirect parent, including those created from within a source other than the current sandbox. ### How to Set Sandbox Allowances You can only manage sandboxes created from the current (logged-in) Vault. Sandboxes created from other sandboxes are available for login and viewing only. To set allowances for a sandbox: 1. In your production Vault, navigate to **Admin > Deployment > Sandbox Vaults**. 2. Under _Active Sandbox Vaults_, find the Vault you want to modify the allowances for. From the **Actions** menu on the _Name_ field, select **Set Allowance**. 3. Select the action to take, either **Grant** or **Revoke**. 4. Select the allowance size from the drop-down and enter the number of allowances to grant or revoke. The number of available allowances is shown below the input field. 5. Optional: When granting allowances, check **Use Temporary Allowance** to create allowances out of your pool if temporary allowances are enabled in your Vault. ## How to Change Sandbox Size {#change-sizes} A Vault Admin can convert a sandbox from one size to another if there are sufficient allowances and the current sandbox meets the data and user limits of the requested size. To change the size of a sandbox: 1. In your production Vault, navigate to **Admin > Deployment > Sandbox Vaults**. 2. Under _Active Sandbox Vaults_, find the Vault you want to change the size for. From the **Actions** menu on the _Name_ field, select **Change Size**. 3. Select the **Requested Size**. The _Available Sandbox Vaults_ section shows the number of sandboxes available by size. If a requested size has no sandboxes available, you are unable to save your selection. 4. Click **Save**. Vault immediately changes the size of the sandbox and enforces the limits associated with the new size. This change does not affect existing data and configuration. To change the sizes of multiple sandboxes: 1. In your production Vault, navigate to **Admin > Deployment > Sandbox Vaults**. 2. From the **Actions** menu for _Active Sandbox Vaults_, select **Change Sandbox Sizes**. 3. Select the **Requested Size** for each sandbox. The _Available Sandbox Vaults_ section shows the number of sandboxes available by size. If a requested size has no sandboxes available, you are unable to save your selection. 4. Click **Save**. Vault immediately changes the size of the sandbox and enforces the limits associated with the new size. This change does not affect existing data and configuration. ## How Configuration Copying Works {#configurationcopying} When creating or refreshing a sandbox, Vault copies the configuration from your production Vault along with records from standard objects marked as configuration data. It's necessary for some components to be modified during that copying process, as outlined below.
* **Reports** and **Flash Reports** are included. However, during copying, flash reports are converted to normal reports and must be rescheduled. During a refresh, Vault deactivates a flash report's scheduled job, which you can reactivate in **Admin > Operations > Job Definitions**. * **Jobs** are included with their *Status* set to inactive. This is to prevent any jobs from running before an Admin adds users and content. * **Custom views** * **Document Templates** are included. However, Vault converts **Controlled Document Templates** to **Basic Document Templates**, as controlled templates rely upon documents in the Vault Library, which are excluded. See details on converting a document template from basic to controlled once the controlled template's document is in your Vault Library. * **Overlays** * **Signature pages** * **Formatted Outputs** * **Custom Sharing Rules** * **Groups** are included, however its user membership is not. Auto Managed Groups are excluded. * **Vault Connections** are included, however you will need to re-establish the connection. * During a refresh, **enhanced Collaborative Authoring** configurations are included. Legacy Collaborative Authoring settings are excluded during a refresh. ### Excluded Components Vault excludes the following components when creating or refreshing a sandbox: * **Documents** * **Object records** for certain objects. This list varies by application and is subject to change without notice. You can find the list for your application in the _Data Usage Information_ section of the **Admin > Settings > General Settings** page. * **Users** and **Auto Managed Groups**, which rely upon _User_ and _User Role Setup_ records. * **Domain-level settings**, such as SSO and security policies * **Annotation Tags** * User-specific **Security Overrides** are excluded. We recommend configuring security overrides using groups instead of individual users. * During a refresh, **legacy Collaborative Authoring** settings are excluded. Only enhanced Collaborative Authoring configurations are included during a refresh. You can recreate most of the excluded items in the new Vault using Configuration Migration Packages and Vault Loader. ### Vault Update Warning When the Veeva Vault service is undergoing maintenance in anticipation of a Veeva Vault release, Vault may display the following warning in the UI: _An update to your Veeva Vault service is underway. During this time, creating or refreshing your Sandbox Vault may take longer than usual. All other Vault features remain fully operational while we enhance our systems to ensure optimal performance for your Vault._ ## Refreshing Sandbox Vaults {#refresh} Refreshing an existing sandbox Vault overwrites the sandbox configuration with the latest configuration from the source Vault. Refreshing a sandbox does not delete or overwrite its existing snapshots. See the above section for a list of items that Vault [excludes during sandbox creation and refresh][7]. How often a sandbox can be refreshed depends on its size: * **Small**: Up to five (5) times in a 24-hour period * **Medium**: Once in a 24-hour period * **Large**: Once in a 24-hour period * **Very Large**: Once in a 24-hour period * **Extra Large**: Once in a 24-hour period * **Full**: Once in a 24-hour period A sandbox can be refreshed from any snapshot built from: * The sandbox being refreshed * The parent Vault of the sandbox being refreshed * The source Vault of the snapshot used to build the sandbox being refreshed ### How to Refresh Vaults To refresh a Vault: 1. In your production Vault, navigate to **Admin > Deployment > Sandbox Vaults**. 2. Under _Active Sandbox Vaults_, find the Vault you need to refresh. Click the **Actions** menu on the _Name_ field and choose **Refresh from Vault** or **Refresh from Snapshot**. See details about sandbox snapshots. 3. If you select **Refresh from Vault**, a message appears to warn you that refreshing deletes the Vault's current configuration. If you select **Refresh from Snapshot**, choose a snapshot in the dialog from which to refresh your Vault and click **Continue**. A message appears to warn you that refreshing deletes the Vault's current configuration. Click **Continue** to start the refresh process. The refresh process generally takes less than one (1) hour but may take up to eight (8) hours. When complete, Vault sends you a notification.
### Overwriting Configuration There is no way to retrieve configurations, data, or documents from a previous version of the sandbox Vault after refreshing, however, you can create a _Test Data_ package to export configurations and object data before refreshing your sandbox and import the package after refreshing. As with creating new sandboxes, Vault does not include users from the production Vault when refreshing. However, Vault does preserve Vault membership from the previous sandbox configuration, so you do not need to re-add the users who previously had access. Refreshing removes all files from the file staging. ### Sandbox Users Users within the sandbox who are assigned a security profile that exists in the production Vault retain their access rights after a refresh. Users with assigned security profiles that do not exist in the production Vault do not get added automatically after a refresh. Vault owners must add those users manually, and select a new security profile at that time. When refreshing a sandbox, only domain-level _User_ fields retain their values. Administers should review and set _User_ record fields on the refreshed sandbox as needed. ## Deleting Sandbox Vaults {#delete} Existing sandbox Vaults may be deleted unless the sandbox is a source Vault for a different sandbox. In most cases, you would refresh a sandbox Vault, rather than deleting. Deleting is only required if you need a sandbox with a different name or need to remove all existing sandbox users. Deleting a sandbox Vault also deletes any snapshots created from this Vault. Deleted sandboxes cannot be recovered. How often a sandbox can be deleted depends on its size. Small sandboxes can be deleted as often as necessary, and all other sizes can be deleted once every 24 hours. ### How to Delete Vaults To delete a Vault: 1. In your production Vault, navigate to **Admin > Deployment > Sandbox Vaults**. 2. Under _Active Sandbox Vaults_, find the Vault you need to delete. From the **Actions** menu of the _Name_ field, choose **Delete**. 3. A message appears to warn you that you cannot recover a deleted Vault. Click **Continue** to start the deletion process. The delete process may take several minutes. When complete, Vault sends you a notification.
### Linked Vault File Staging Some Vaults are set up with "linked" file staging, meaning that the sandbox shares file staging with another Vault. File staging areas are only linked by customer request through Veeva Support. If your sandbox has linked file staging, you will need to contact Veeva Support to unlink the sandbox from the shared file staging area before you can delete the Vault. ## Granting Access to Sandbox Vaults When creating a new sandbox, you have the option to add the current user with the Vault Owner profile. See [Add Current User as Vault Owner][5]. These Vault Owner users can configure access for other users. Users with the appropriate access can also remove the automatically added Vault Owners if needed. User access works as it does in production Vaults: Admins can add entirely new users, grant access to existing domain users, or add cross-domain users.
## Logging into Sandbox Vaults Users with access to a Sandbox Vault can log into the sandbox using the same Login page as the production Vault. Production Vault Owners, or Admins with appropriate permissions, can also log into the sandbox from the **Admin** area: 1. In the production Vault, navigate to **Admin > Deployment > Sandbox Vaults**. 2. Under _Active Sandbox Vaults_, use the gear icon on the _Name_ field to open the action menu and choose **Log in** for the appropriate sandbox. 3. Enter valid sandbox user credentials on the Login page. ## Sandbox Release Versions {#release-versions} In general, sandboxes have the same release version as the production Vault. However, some organizations with General Release Vaults have options for creating a sandbox using a Limited Release version. Each Limited Release version sandbox Vault counts toward the total configuration sandboxes allowed per production Vault. This feature allows customers the ability to manage their own Limited Release sandbox to proactively assess new functionality ahead of each General Release. For example, an Admin in a 21R1 General Release Vault could create a sandbox that uses the 21R1.2 Limited Release version. ## Related Permissions By default, administration options for sandbox Vaults are only available to Vault Owners. To grant access to other users, use a custom security profile with the following permissions:
Type Permission Label Controls
Security Profile Admin: Sandbox: Read Ability to view sandboxes in the Admin > Deployment > Sandbox Vaults page
Security Profile Admin: Sandbox: Create Ability to create sandboxes in the Admin > Deployment > Sandbox Vaults page
Security Profile Admin: Sandbox: Edit Ability to edit and refresh sandboxes in the Admin > Deployment > Sandbox Vaults page
Security Profile Admin: Sandbox: Delete Ability to delete and refresh sandboxes in the Admin > Deployment > Sandbox Vaults page
[1]: #usage [2]: #sizes [3]: #name [4]: #release-versions [5]: #owners [6]: #change-sizes [7]: #configurationcopying [8]: #delete