# Release week without the chasing. > SyncOnAI 360 for release managers puts every Salesforce change on one governed path. Each proposal carries named pre-flight checks, the components it affects and a validation against the target org; production needs a second admin's approval; a deploy policy sets freeze windows; and every deploy leaves a receipt with rollback. Source: https://synconai360.com/solutions/salesforce-release-managers ## Key facts - **1**: Path to production for every change - **2**: People on every production change in multi-admin workspaces - **12**: Affected components named on each proposal - **Every**: Deploy leaves a receipt with rollback ## Why Salesforce release management turns into detective work Most Salesforce releases are assembled by asking people what they changed. Changes arrive from Setup, from change sets, from an IDE and now from AI tools, and the release manager is the one person expected to know what all of them do. - **Changes from everywhere.** Admins in Setup, developers in an IDE, contractors in their own sandboxes, AI in a chat window. Each route has its own record, or none. - **Approval without context.** An approver is shown a list of files and asked to say yes, with no view of what the change touches or whether it has been validated. - **Side-door production edits.** A quick fix made straight in production is overwritten by the next release, and nobody knows until a user complains. - **No reliable undo.** When a release misbehaves, the way back is rebuilding the old version by hand under pressure. ## How does every Salesforce change reach one release path? Whether a change is drafted by the AI, built on the Flow, Lightning page, component or Apex builders, or asked for in the chat, it becomes a proposal: the files, a before and after view of each one, and the request that produced it. Nothing reaches an org any other way. Members can deploy to sandboxes freely so teams keep their pace. Promoting a proposal to production brings it under the production org's policy, so the release manager governs one path rather than policing several. - AI, builders and chat all produce proposals - Before and after for every file - Sandboxes free, production governed ## What does a release manager see before approving? Each proposal runs named pre-flight checks: destructive operations that would discard data, security and access changes, field presence, cascading dependencies, deploy order and test coverage. Every check returns pass, warn or fail with a plain reason, and the proposal carries an overall risk of low, medium or high. The change is then validated against the target org without saving anything, so the errors shown are Salesforce's own. Up to twelve affected components are named, automation and validation first and access grants last, so the approval is about real consequences. - Six named checks with plain reasons - Validation against the target org - Blast radius named on the proposal ## How do freeze windows and approval rules work? The deploy policy sets freeze windows when deploys are blocked, required approvers for certain changes, and auto-approval for low-risk work. Each proposal explains which rule applied to it, so nobody has to guess why a deploy is waiting. Production needs an approved proposal, and when a workspace has two or more admins the approver must be someone other than the author. A policy can make deploys harder; it can never let through a change that failed its checks or was rejected. - Freeze windows and required approvers - Maker-checker for production - No rule can override a failed check ## How do you catch changes made outside the release? Every audit reads the last thirty days of the org's Setup Audit Trail. Change checks flag production changes made outside the deploy pipeline, validation rules that were recently deactivated, and a single user making an unusually high number of changes. Before a release, compare metadata between a sandbox and production, or between snapshots of the same org, to see exactly which components differ and avoid overwriting a fix that went in another way. - Side-door changes raised as findings - Compare orgs before a release - Compare snapshots over time ## What is left behind after a release? Every deploy leaves a receipt: what changed, the request behind it, the checks and their results, who approved it and when, and the version of each component recorded before the deploy. Roll back from the receipt and those versions are redeployed; production rollbacks need an admin. Rollback does not delete components the deploy created and cannot reverse data changes, and the product says so plainly. Work items on project boards link to the deploys that delivered them, and the activity log records deploys, refreshes and settings changes across the workspace. - A receipt for every deploy - Rollback to the recorded version - Work items linked to deploys - Workspace activity log ## A release on SyncOnAI 360 1. **Build in sandboxes.** Contributors propose and deploy to sandboxes as they work. 2. **Compare.** Check what differs between the sandbox and production. 3. **Review.** Read the checks, risk and blast radius on each proposal. 4. **Approve.** A second admin approves production inside the policy's windows. 5. **Record.** Each deploy leaves a receipt, ready to roll back. ## Release management, chased versus governed | Without | With SyncOnAI 360 | |---|---| | Asking people what they changed | Every change arrives as a proposal | | Approving a list of files | Approving checks, risk and blast radius | | Freeze windows in a calendar invite | Freeze windows the deploy path enforces | | Side-door edits found by users | Side-door edits raised as findings | | Rebuilding the old version by hand | Rollback from the receipt | ## Who you work with on a release - **Salesforce admins.** Build and propose configuration changes, see the checks on their own work before it reaches you, and approve each other's production changes. - **Salesforce developers.** Propose Apex and components with their tests, see coverage checked before deploy day, and fix forward from Salesforce's own errors. - **Delivery managers.** See work items close when the deploy that delivered them succeeds, and report on releases from receipts. - **Auditors and IT leaders.** Answer who approved what and when from receipts and the activity log, without asking the release manager. ## Frequently asked questions ### Is SyncOnAI 360 a Salesforce release management tool? It gives release managers one governed path for every change: proposals with named checks and validation, maker-checker approval, a deploy policy with freeze windows, receipts and rollback. ### Can we enforce a change freeze? Yes. The deploy policy sets freeze windows when deploys are blocked, and each proposal explains which rule applied. ### Who can approve production? Admins. When a workspace has two or more admins, the approver must be someone other than the person who made the change. ### Does it replace change sets? For changes made through SyncOnAI 360, yes: they deploy through the Salesforce Metadata API after validation and approval. It does not import existing change sets. ### Can it detect changes made directly in production? Yes. The audit reads the Setup Audit Trail and flags production changes made outside the deploy pipeline. ### Can we compare a sandbox with production? Yes. Metadata can be compared between orgs or between snapshots of the same org. ### What does rollback cover? It redeploys the version of each component recorded before the deploy. It does not delete components the deploy created and cannot reverse data changes. ### Does it integrate with Jira? Audit findings can be raised as Jira Cloud issues, with status checked back on demand. It is not a two-way sync. ### Is this on every plan? Yes. Every plan includes every feature. ### What happens when a deploy fails? Salesforce's reason is shown on the deploy, and Fix in chat opens the conversation with the error so the change can be corrected and proposed again. ### Do sandbox deploys need approval? No. Members can deploy to sandboxes freely; production needs an approved proposal, so teams keep their pace where it is safe. ### Can a member roll back production? No. Rolling back production needs an admin, the same as approving it, and a deploy can only have one rollback in progress at a time.