# Undo a Salesforce deploy in one click, safely. > SyncOnAI 360 Rollback reverses a Salesforce deploy by redeploying the version of each component recorded before it, started from the deploy's receipt. Production rollbacks need an admin, one rollback runs per deploy at a time, and the limits are explicit: components the deploy created and data changes are not reversed. Source: https://synconai360.com/features/rollback ## Key facts - **1**: Click from the receipt - **Every**: Deploy records the previous version first - **1**: Rollback in progress per deploy at a time - **Admin**: Required to roll back production ## Why undoing a Salesforce change is so painful Salesforce has no undo button for metadata. When a release causes an incident, rolling back means finding the old version in a sandbox or a repository, hoping it is the right one, and deploying it under pressure. - **Where is the old version?.** Nobody kept a copy of what the component looked like before the deploy. - **Wrong version restored.** The sandbox copy is newer or older than what was in production, and the rollback adds a new problem. - **Rollback under pressure.** The undo is itself an unreviewed change, made in the worst possible moment. - **False expectations.** Teams assume rollback reverses everything, including data and new components. It does not. ## How does Salesforce rollback work in SyncOnAI 360? Before each deploy, the version of every component it will change is recorded. Use Roll back on the receipt and those recorded versions are redeployed through the Salesforce Metadata API, returning each component to how it was. The rollback is itself recorded, and the components are read back into the repository afterwards so the org's picture stays accurate. - Previous version recorded before deploy - Redeployed from the receipt - Rollback recorded too ## Who can roll back a Salesforce production deploy? Rolling back production needs 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 follow the same mechanism, so teams can practise the undo path where it is cheap. - Admin required for production - One rollback at a time per deploy - Same path in sandboxes ## What does a Salesforce rollback not reverse? Components the deploy created are not deleted by a rollback; remove those separately. Rollback restores recorded metadata, so it cannot reverse data changes. Both limits are stated plainly so nobody discovers them during an incident. That is why data-changing Apex run from the chat waits for an explicit Allow: actions that cannot be rolled back are the ones held for a person's decision. - New components removed separately - Data changes are not reversed - Irreversible actions held for consent ## When should you fix forward instead? When a deploy fails, 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 succeeded but behaves badly, rollback returns to the known state while the fix is prepared. Either way, the fix goes through the same checks and approval, and the history shows both the original change and what followed. - Fix in chat from failed deploys - Rollback to a known state, then fix - Both recorded ## How do you plan for a Salesforce rollback? Treat rollback as part of the release, not an emergency. Sandbox rollbacks use the same mechanism, so a team can deploy, roll back and redeploy in a sandbox to confirm that both the change and its undo behave before production. Where a change creates components or alters data, plan their removal or correction separately before release, since those are the parts a rollback does not cover. The proposal's before and after view lists every file the change touches. - Rehearse the undo in a sandbox - Plan for created components - A separate plan for data changes ## What does a rollback look like in practice? Open the deploy from Deploys or from the org it changed and choose Roll back on its receipt. The recorded versions are redeployed through the same governed path, and a production rollback needs an admin. Afterwards the components are read back into the repository, so search, health and lineage reflect the restored state, and the history shows the original deploy and its rollback together. - Roll back from the receipt - Same governed path - History shows both ## Rolling back a deploy 1. **Open the receipt.** Find the deploy under Deploys or on the org. 2. **Roll back.** An admin starts the rollback for production. 3. **Redeploy.** The recorded previous versions are deployed. 4. **Tidy up.** Remove any new components separately if needed. 5. **Fix forward.** Prepare the corrected change as a new proposal. ## Rollback, improvised versus recorded | Without | With SyncOnAI 360 | |---|---| | Hunting for the old version | The previous version recorded before deploy | | Restoring the wrong copy | Exactly what was replaced, redeployed | | An unreviewed emergency change | An admin-controlled, recorded rollback | | Assumed to undo everything | Limits stated: new components and data | ## Who relies on rollback - **Salesforce admins.** Undo a deploy that behaves badly from its receipt, returning each component to its recorded previous version while the fix is prepared. - **Platform owners.** Have a documented undo path for every production change, limited to admins and one rollback at a time, with each rollback recorded. - **Consultancies.** Give clients the confidence to approve change: every deploy to their org can be rolled back to the version recorded before it, and the limits are stated in writing. - **Salesforce developers.** Practise the undo path in sandboxes, where it works the same way, and fix forward from Salesforce's own error with Fix in chat when a deploy fails. - **Approvers.** Approve production changes knowing each one has a recorded previous version to return to, which makes a careful yes easier to give than a defensive no. ## Frequently asked questions ### Can you roll back a Salesforce deployment? Yes, with SyncOnAI 360: the version of each component recorded before the deploy is redeployed from the receipt. ### Does rollback delete new components? No. Components the deploy created are not deleted by a rollback and are removed separately. ### Does rollback reverse data changes? No. Rollback restores recorded metadata; it cannot reverse data changes. ### Who can roll back production? Only admins. ### Can two people roll back at once? No. A deploy can only have one rollback in progress. ### Does it work for changes made outside SyncOnAI 360? Rollback relies on the version recorded at deploy time, so it covers deploys made through SyncOnAI 360. ### Is the rollback recorded? Yes, and the components are read back into the repository afterwards. ### Is rollback on every plan? Yes. Every plan includes every feature.