# Every Salesforce change checked, approved and reversible. > SyncOnAI 360 Deploy and Approvals is the path every change takes to a Salesforce org: a proposal with named pre-flight checks and blast radius, validation against the target org, approval by an admin other than the author for production, deployment through the Salesforce Metadata API, and a receipt with one-click rollback. Source: https://synconai360.com/features/deployments ## Key facts - **2**: People behind every production change - **1**: Click to roll back to the recorded previous version - **0**: Ways for policy to let a failed check through - **75%**: Apex coverage, with tests run on production deploys ## Why Salesforce releases still go wrong Salesforce makes it easy to change production directly, and most incidents start there: a change nobody reviewed, made by one person, with no record of what it replaced. AI-generated changes make the volume higher and the stakes the same. - **One person can ship to production.** Without separation of duties, the person who made a change is the person who approved it. Auditors notice, and so do incidents. - **Checks that can be skipped.** A tight deadline turns a review step into a formality. If the process lets a failed check through once, it will again. - **No record of what was replaced.** When a deploy causes a problem, rolling back means rebuilding the old version from memory or an old sandbox. - **Changes made outside the process.** Someone edits production directly in Setup. Nobody knows until the next deploy overwrites it or it breaks. ## What is in a Salesforce change proposal? A proposal is a change waiting to be deployed. Chat and the builders create them, and every one shows named pre-flight checks with a pass or a reason for failure, the blast radius of the change in the org, a risk badge with the policy decision for it, and a before and after view of every file. Before a proposal is offered, it is validated against the target org without changing anything, so the errors you see are real Salesforce errors. A proposal that fails a pre-flight check cannot be deployed, whatever the policy says. - Named pre-flight checks, each pass or fail with a reason - Blast radius from the org's dependency map - Before and after for every file - Validated against the target org first ## How does two-person approval work for Salesforce production? Sandbox deploys can be made by any member, so teams can iterate. Production needs an approved proposal, and when a workspace has two or more admins, the approver must be an admin other than the person who made the change. A workspace with a single admin can approve its own change, and the activity log records that it did. Only admins can approve production changes, edit the deploy policy or roll back a production deploy. Roles are simple: admins and owners can do everything; members can chat, build, propose and deploy to sandboxes. - Maker and checker are always different people when possible - Single-admin approvals recorded, never hidden - Admin-only production approval, policy and rollback ## Can you enforce freeze windows and approval rules? The deploy policy sets freeze windows, required approvers and auto-approval rules for low-risk changes, and each proposal explains which rule applied to it. A policy can make deploys harder; it can never let through a change that failed its checks or was rejected. A proposal deployed to one org can be redeployed to another, for example from a sandbox to production. The target's policy and freeze windows apply, and production still needs an admin. - Freeze windows and required approvers - Auto-approval rules for low-risk work - Policy only ever adds friction, never removes checks - Promote from sandbox to production under the target's rules ## How do Salesforce deploy receipts and rollback work? Deploys use the Salesforce Metadata API, and production deploys that include Apex run its tests at Salesforce's 75% coverage bar. Every deploy has a receipt: what changed, the request that produced it, the checks, who approved it and when. Roll back from the receipt and SyncOnAI 360 deploys the version of each component recorded before the change. Rolling back production needs an admin, and a deploy can have only one rollback in progress. After a successful deploy, the changed components are read back straight away, and the audit flags production changes made outside the pipeline. - A receipt with requester, request, checks, approver and time - Rollback to the recorded previous version - Deployed components read back immediately - Changes made outside the pipeline flagged by the audit ## Who can do what in a governed Salesforce workspace? There are two roles. Admins and owners can do everything, including connecting orgs, managing keys and members, approving production changes, editing the deploy policy and rolling back production. Members use the workspace fully: chat, search, build, propose changes, deploy to sandboxes and run projects. That split keeps the people who build moving quickly in sandboxes while production stays behind an admin's decision. The first person in a new workspace is an admin, and new people are invited by email with the role chosen up front. - Admins: orgs, keys, members, production approval, policy and rollback - Members: chat, build, propose and deploy to sandboxes - Roles chosen when someone is invited ## How a change reaches production 1. **Propose.** Chat, a builder or a teammate creates a proposal. 2. **Check.** Named pre-flight checks run and the change is validated against the org. 3. **Test.** Deploy to a sandbox and try it. 4. **Approve.** An admin other than the author approves production, inside the policy. 5. **Deploy and record.** The deploy runs, tests pass, and the receipt is written with rollback. ## Releases, with and without SyncOnAI 360 | Without | With SyncOnAI 360 | |---|---| | Whoever built it pushes it | A different admin approves production | | Reviews skipped under pressure | Failed checks block the deploy, whatever the policy | | No idea what else a change touches | Blast radius on every proposal | | Rollback by rebuilding from memory | One-click rollback to the recorded version | | Direct edits in production go unnoticed | The audit flags changes made outside the pipeline | ## Who relies on governed deploys - **Salesforce admins.** Deploy with named checks, validation against the org and a receipt for every change, and roll back from the receipt if something misbehaves. - **Platform owners.** Keep production behind maker-checker approval with a deploy policy for freeze windows and required approvers that can never relax the checks. - **Consultancies.** Ship client changes through one governed path, so every deploy to a client org has its evidence, approval and undo recorded. - **Salesforce developers.** See real Salesforce errors from a validate-only deployment before release, and fix forward from the error in the chat. ## Frequently asked questions ### How does SyncOnAI 360 deploy to Salesforce? Through the Salesforce Metadata API. Every change is a proposal that is validated against the target org first, and production deploys need an approved proposal. ### Can one person deploy to production alone? Not while a second admin exists. The person who made a production change cannot approve it; another admin must. A workspace with a single admin can approve its own change, and the activity log records it. ### What are pre-flight checks? Named checks a proposal must pass before it can be deployed, each showing a pass or the reason it failed. A failed check blocks the deploy regardless of policy. ### What does blast radius mean? Everything else in the org that uses the components being changed, calculated from the org's dependency map and shown on the proposal for approvers. ### How does rollback work? Use Roll back on the deploy receipt. It deploys the version of each component recorded before the change. Components the deploy created are not deleted by a rollback and are removed separately. ### Can we set freeze windows? Yes. The deploy policy sets freeze windows, required approvers and auto-approval rules. Each proposal explains which rule applied to it. ### Do Apex tests run? Production deploys that include Apex run its tests, and Salesforce requires 75% coverage. A Developer Edition org counts as production. ### Can we move a change from sandbox to production? Yes. A proposal deployed to one org can be redeployed to another. The target's policy and freeze windows apply, and production needs an admin. ### 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 it can be corrected and proposed again. ### Can members deploy? Members can deploy to sandboxes and propose production changes. Approving production, editing the deploy policy and rolling back production are admin actions. ### Does a rollback delete components the deploy created? No. A rollback redeploys the version of each component recorded before the deploy. Components the deploy created are not deleted by a rollback and are removed separately. ### Is two-person approval included on every plan? Yes. Every plan includes every feature. Two-person approval takes effect once a workspace has two or more admins. ### Can a deploy have more than one rollback running? No. A deploy can only have one rollback in progress at a time, and rolling back production needs an admin.