CRM sandbox change promotion with a controlled release
Move a tested CRM change into production through a controlled promotion record that names dependencies, an owner, release checks, and a usable rollback path.
CRM sandbox change promotion
A CRM sandbox change promotion should begin with a tested change and end with a verified production result. The release record connects those two states so an administrator does not rely on memory during deployment.
Name the change owner, affected objects, expected behavior, and planned release window. Include a rollback action that the owner can use if production behaves differently from the sandbox.
Describe the tested change
List the fields, automation, permissions, reports, or integrations touched by the change. Attach the sandbox test evidence and state which user roles were included in the review.
Keep unrelated improvements out of the release package. A narrow promotion is easier to inspect, communicate, and reverse than a bundle whose parts have different owners.
Check production dependencies
Compare the sandbox configuration with production before release. Look for missing fields, active workflows, permission differences, integration credentials, and reporting references that could change the result.
Assign each dependency a disposition rather than assuming it will work. If a required condition is missing, pause the promotion and return it to the owner with the exact gap.
Choose a release owner
One administrator should control the production action and the verification sequence. Other reviewers can approve their areas, but the release owner decides when the package is ready to move.
Publish the contact and release window to affected teams. Tell users what may change and where to report an unexpected result without asking them to diagnose the configuration.
Verify in production
Run a short set of production checks immediately after promotion using approved test records. Confirm permissions, automation outcomes, integration behavior, and the reports that depend on the changed data.
Record the result of every check and stop if a critical expectation fails. Do not mark the release complete because the deployment tool reported success.
Close or roll back
If verification passes, close the release with its production time and evidence links. Update the configuration record so later administrators know which version is active.
If verification fails, use the prepared rollback path and confirm the prior behavior returns. Preserve the failure evidence and open a fresh change request instead of quietly editing production until it appears fixed.
Sources
- Configuration Change Control, National Institute of Standards and Technology. Describes documented, reviewed, approved, implemented, and verified configuration changes.
Related GTM guides
Frequently asked questions
Is a successful deployment enough to close the change?
No. Run the planned production checks and record their results before closing the promotion.
What should a rollback plan contain?
Name the prior configuration, the person authorized to restore it, the trigger for rollback, and the checks that confirm recovery.