Promoting Change Requests from Sandbox to Production Accounts
You can submit change requests to promote integrations from your sandbox account to your associated production account using the Change Requests screen within Sandbox Management in Global Settings. With this feature, you can streamline the deployment process by promoting validated configurations without needing to manually export, import, and reconfigure dependencies.
At this time, only integrations can be promoted from sandbox accounts to production accounts.
To submit a change request from sandbox for an integration
In order to submit a change request from your sandbox account to your production account, you must first make and save changes to an integration within your sandbox account. Once changes have been saved, you can promote the integration to create an inbound change request within your production account.
- Navigate to Integrations and select Integrations.
The Integrations screen appears, where you can proceed with creating a new integration or updating an existing integration as necessary.
- After you have configured your integration on the Integration builder screen, click the Save button. Once you have saved your integration, the Submit change request button will become available at the bottom of the screen.
Note:
The Submit change request button can only be enabled by clicking the Save button on the Integration builder screen. Navigating away from the Integration builder screen will disable the button.
- Click the Submit change request button.
The Promote Integration modal appears.
To review inbound change requests in production
Once you have sent change requests from your sandbox account, you can navigate back to your production account for review.
- On the Global Settings menu within your production account, select . The Sandbox Management screen appears.
Change Requests Screen Reference
- Field
- Description
- Context Menu
-
Click this icon and select whether to deploy, reject, or delete the change request.
- Sandbox
-
The name of the sandbox from which the change request originated.
- Module
-
The product from which the change request originated.
- Name
-
The name of the record associated with the change request.
- Dependencies
-
The number of related objects that will be impacted by the proposed change if deployed.
- Date created
-
The date and time on which the change request was created.
- Actions
-
Click the View Details link to view additional details about the change request, such as the creator, created date, and status of the request along with any dependencies.
To deploy inbound change requests to production
- Click the Context Menu icon corresponding to the change request you want to deploy, and select Deploy. If dependencies are found for the change request, the Dependencies found modal will appear. If credentials are needed, the Select existing Credentials field will appear with a drop-down of existing credentials. You can also click the Set up Credentials link if you need to create new credentials.
- Click the Accept and Continue button. The Deploy Change Request modal appears.
- Click the Deploy button. The change request is then moved from the New tab to one of the following tabs based on the success of the deployment:
-
If the deploy action has not yet completed, the change request will appear in the In Progress tab. The View Details link will also populate with additional details regarding the deployment, such as who deployed the request, the deployed date and time, and comments provided on the Deploy Change Request modal, if any.
-
If the deploy action has completed and was successful, the change request will appear in the Deployed tab. The View Details link will also populate with additional details regarding the deployment, such as who deployed the request, the deployed date and time, and comments provided on the Deploy Change Request modal, if any.
-
If the deploy action has completed but was not successful, the change request will appear in the Failed tab.
Note:You can return to your sandbox account and resubmit the change request to try again. If the issue persists, please create a support case here.
-
To reject inbound change requests
- Click the Context Menu icon corresponding to the change request you want to reject, and select Reject. The Reject Request modal appears.
Note:
The Reject Request modal also appears if you click the Deny button on the Dependencies found modal.
- Click the Reject button. The change request is then moved from the New tab to the Rejected tab of the Change Requests screen. The View Details link will also populate with additional details regarding the rejection, such as who rejected the request, the rejected date and time, and comments provided on the Reject Request modal, if any.
To delete inbound change requests
- Click the Context Menu icon corresponding to the change request you want to delete, and select Delete. The Delete the change request modal appears.
Sandbox Promotion FAQ
The following responses are supported solutions to frequently asked questions (FAQ) on promoting changes from sandbox accounts. The OneTrust team continuously monitors these inquiries and will make additional FAQ available as they are identified.
How do I promote main workflows and subflows together?
Main workflows and subflows can be promoted as separate change requests. Once you have deployed both changes in production, you will need to add the subflow records back into the main workflow within Integrations.
My workflow uses subflow triggers. How can I make sure these are added to the main workflow?
Navigate to the main workflow within Integrations, select the subflow, and populate the subflow record accordingly.
What URL should I use for webhook configurations in my environment (sandbox vs. production)?
The webhook URL should correspond to the environment you are working in. If you are configuring webhooks in a sandbox environment, use the URL for your sandbox account. For production, make sure you are using the URL for your production account.