# How to roll back a Salesforce deployment. > Rolling back a Salesforce deployment with SyncOnAI 360 means opening the deploy's receipt and choosing Roll back, which redeploys the version of each component recorded before the deploy. Production rollbacks need an admin, one rollback runs per deploy at a time, and components the deploy created and data changes are not reversed. Source: https://synconai360.com/use-cases/rollback-salesforce ## Key facts - **Every**: Deploy records the previous version - **1**: Action from the receipt - **Admin**: Required to roll back production - **2**: Limits stated up front ## Why rolling back Salesforce is so hard Salesforce deploys forward only. Undoing a change means finding the old version, if anyone kept it, and deploying that under pressure. - **No previous version.** Nobody saved what the component looked like before. - **Pressure.** Rollback is improvised during an incident. - **Unclear limits.** Nobody knows what a rollback will and will not undo. - **Two people undoing at once.** Conflicting fixes make things worse. ## How does rolling back a Salesforce deploy work? Before each deploy, the version of every component it changes is recorded. Choose Roll back on the receipt and those versions are redeployed through the Metadata API. The rollback is itself recorded, and components are read back into the repository afterwards. - Versions recorded before deploy - Redeployed on rollback - Rollback recorded too ## Who can roll back production? An admin, the same as approving it. A deploy can only have one rollback in progress, so two people cannot race to undo the same change. Sandbox rollbacks work the same way, so the undo path can be rehearsed. - Admins for production - One rollback at a time - Rehearse in sandboxes ## What does a rollback not reverse? Components the deploy created are not deleted; remove them separately. Data changes cannot be reversed. Both limits are stated so nobody discovers them during an incident, and data-changing actions from the chat wait for an explicit Allow for that reason. - Created components remain - Data changes not reversed - Data actions need Allow ## How should you plan for rollback? Treat rollback as part of the release. Deploy, roll back and redeploy in a sandbox to confirm both directions behave, and plan separately for any components the change creates and any data it alters. - Rehearse both directions - Plan for created components - Plan for data ## When should you fix forward instead? When a deploy fails outright, Salesforce's reason is shown and Fix in chat opens the conversation with the error, so the change can be corrected and proposed again. When a deploy succeeds but misbehaves, rollback returns to the known state while the fix is prepared. - Failed deploys: fix forward - Misbehaving deploys: roll back - Both recorded ## What does the rollback record show? The rollback is recorded alongside the original deploy, so the history shows what was deployed, when it was rolled back and by whom. Components are read back into the repository afterwards, so search, health and lineage reflect the restored state. That record answers the question that follows every incident: what exactly was undone, and is the org now back where it was. - Deploy and rollback together - Repository refreshed - A clear incident record ## How to roll back 1. **Open the receipt.** From Deploys or the org it changed. 2. **Roll back.** An admin starts the rollback for production. 3. **Clean up.** Remove any components the deploy created. 4. **Fix.** Prepare the corrected change as a new proposal. ## Rollback, improvised versus recorded | Without | With SyncOnAI 360 | |---|---| | Hunting for the old version | Recorded before every deploy | | Improvised under pressure | One action from the receipt | | Unknown limits | Limits stated up front | | Two people undoing at once | One rollback at a time | ## Rollback readiness checklist - [ ] Confirm the deploy went through SyncOnAI 360, so a previous version was recorded. - [ ] Make sure an admin is available for a production rollback. - [ ] List any components the deploy created; they need removing separately. - [ ] Identify any data the change altered; rollback will not reverse it. - [ ] Rehearse the rollback in a sandbox for high-risk changes. - [ ] Decide in advance whether you will roll back or fix forward. - [ ] Record what happened alongside the receipt afterwards. ## Who relies on rollback - **Release managers.** A documented backout plan for every change. - **Salesforce admins.** Undo a bad deploy without rebuilding it. - **Consultancies.** Give clients confidence to approve change. ## Frequently asked questions ### Can Salesforce roll back a deployment natively? Not for metadata in general. SyncOnAI 360 records the previous version before each deploy so it can redeploy it. ### Who can roll back production? Admins. ### Does rollback delete new components? No. Remove components the deploy created separately. ### Does rollback restore data? No. It restores metadata only. ### Can two rollbacks run at once? No. One rollback per deploy at a time. ### Is the rollback recorded? Yes, alongside the original deploy. ### Does it work for changes made outside SyncOnAI 360? No. Only deploys made through SyncOnAI 360 have recorded previous versions. ### Is this on every plan? Yes. Every plan includes every feature. ### Can sandbox deploys be rolled back? Yes, the same way, which makes sandboxes a good place to rehearse. ### How quickly does a rollback start? As soon as an admin starts it from the receipt; one rollback per deploy runs at a time. ### What is a backout plan in SyncOnAI 360? The receipt itself: it holds the previous version of each component, ready to redeploy, with the limits stated. ### Does rollback need its own approval? Rolling back production needs an admin, the same as approving the original deploy.