SyncOnAI360

Deploy and Approvals

Every Salesforce change checked, approved and reversible.

Changes from chat, the builders or your team become proposals with named checks and a blast radius. Production needs a second admin's yes, and every deploy leaves a receipt you can roll back from.

Start freeTalk to our team

Proposal: Case intake fault handling

Acme Production

Checks passed

Made by

D. Chen, admin

Cannot approve own production change

Approver

M. Okafor, admin

Policy: production requires an admin other than the author. Recorded on the receipt.

In one paragraph

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.

People behind every production change
2People behind every production change
Click to roll back to the recorded previous version
1Click to roll back to the recorded previous version
Ways for policy to let a failed check through
0Ways for policy to let a failed check through
Apex coverage, with tests run on production deploys
75%Apex coverage, with tests run on production deploys

01The problem

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.

  1. 01

    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.

  2. 02

    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.

  3. 03

    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.

  4. 04

    Changes made outside the process

    Someone edits production directly in Setup. Nobody knows until the next deploy overwrites it or it breaks.

02proposals

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

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

03approval

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

Proposal: Case intake fault handling

Acme Production

Checks passed

Made by

D. Chen, admin

Cannot approve own production change

Approver

M. Okafor, admin

Policy: production requires an admin other than the author. Recorded on the receipt.

04policy

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

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

05receipts

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

Deploy receipt

Acme Production

Deployed
Change
Case_Intake_Route: fault path added
Requested
"Add fault handling to the intake Flow"
Checks
5 of 5 passed
Approved by
M. Okafor, admin
Deployed
Today, 14:22 to Acme Production
Previous version recorded

06roles

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

Proposal: Case intake fault handling

Acme Production

Checks passed

Made by

D. Chen, admin

Cannot approve own production change

Approver

M. Okafor, admin

Policy: production requires an admin other than the author. Recorded on the receipt.

07How it works

How a change reaches production

The same path for every change, whoever or whatever drafted it.

  1. 01

    Propose

    Chat, a builder or a teammate creates a proposal.

  2. 02

    Check

    Named pre-flight checks run and the change is validated against the org.

  3. 03

    Test

    Deploy to a sandbox and try it.

  4. 04

    Approve

    An admin other than the author approves production, inside the policy.

  5. 05

    Deploy and record

    The deploy runs, tests pass, and the receipt is written with rollback.

08Before and after

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

09Who uses it

Who relies on governed deploys

Salesforce adminsDeploy with named checks, validation against the org and a receipt for every change, and roll back from the receipt if something misbehaves.Platform ownersKeep production behind maker-checker approval with a deploy policy for freeze windows and required approvers that can never relax the checks.ConsultanciesShip client changes through one governed path, so every deploy to a client org has its evidence, approval and undo recorded.Salesforce developersSee real Salesforce errors from a validate-only deployment before release, and fix forward from the error in the chat.

10Questions

Frequently asked questions

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.

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.

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.

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.

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.

Yes. The deploy policy sets freeze windows, required approvers and auto-approval rules. Each proposal explains which rule applied to it.

Production deploys that include Apex run its tests, and Salesforce requires 75% coverage. A Developer Edition org counts as 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.

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.

Members can deploy to sandboxes and propose production changes. Approving production, editing the deploy policy and rolling back production are admin actions.

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.

Yes. Every plan includes every feature. Two-person approval takes effect once a workspace has two or more admins.

No. A deploy can only have one rollback in progress at a time, and rolling back production needs an admin.

11Keep exploring

Related

Lineage and ImpactWhat breaks before you change itAI AgentOrg-aware chat and specialist agentsEnterprise Salesforce teamsGovern every org and every change at scalePlatformUnderstand, build, ship and deliver in one workspaceTrust CenterWhat we hold and how it is protectedPricingEvery feature on every plan

Start in 5 minutes. No card required.

Connect your Salesforce org. Run your first health scan. Ask your first question. See what you've been missing.

Start free, connect my orgBook a demo with SyncOnAI
  • Anthropic
  • OpenAI