SyncOnAI360

Approval Gates

No Salesforce production change on one person's say-so.

The person who makes a production change cannot approve it. A deploy policy adds freeze windows, required approvers and safe auto-approval, and nothing can approve its way past a failed check.

Start freeBook a demo

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 Approval Gates enforce maker-checker control on Salesforce production changes: with two or more admins, an admin other than the author must approve. A workspace deploy policy sets freeze windows, required approvers and auto-approval rules, explains which rule applied to each proposal, and can only make deploys stricter.

People behind every production change
2People behind every production change
Ways for policy to override a failed check
0Ways for policy to override a failed check
Proposal explains which policy rule applied
EveryProposal explains which policy rule applied
Recorded exception: the single-admin workspace
1Recorded exception: the single-admin workspace

01The problem

Why separation of duties fails in Salesforce teams

Most teams have a policy that the builder should not approve their own change. Salesforce does not enforce it, deployment tools rarely do, and an auditor asking for evidence gets a spreadsheet.

  1. 01

    Policy on paper

    The rule exists in a document. The tools let anyone with access deploy to production.

  2. 02

    Freeze windows by email

    A change freeze is announced, and someone deploys anyway because nothing stops them.

  3. 03

    Approval fatigue

    Every change needs the same heavyweight approval, so people start rubber-stamping.

  4. 04

    No evidence

    When auditors ask who approved a change, the answer is a chat thread.

02maker checker

How does maker-checker approval work for Salesforce?

Sandbox deploys can be made by any member so teams can iterate quickly. 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, so the exception is visible rather than hidden. Rolling back a production deploy also needs an admin.

  • Author and approver are different admins
  • Sandbox deploys stay fast
  • Single-admin exception recorded

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.

03policy

What can a Salesforce deploy policy enforce?

The deploy policy sets freeze windows when deploys are blocked, required approvers for certain changes, and auto-approval rules for low-risk work so approvers spend their attention where it matters. 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. When a proposal is promoted from a sandbox to production, the target org's policy and freeze windows apply.

  • Freeze windows
  • Required approvers
  • Auto-approval for low-risk work
  • Never overrides a failed check

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

04roles

Who can approve Salesforce production changes?

Only admins can approve production changes, edit the deploy policy or roll back production. Admins and owners can also connect orgs and manage keys and members. Members can chat, search, build, propose changes, deploy to sandboxes and run projects.

Roles are chosen when someone is invited, and the first person in a new workspace is an admin. Two roles keep the model simple enough to explain to an auditor in one sentence.

  • Admins approve, set policy and roll back
  • Members build and deploy to sandboxes
  • Roles set at invitation

Workspace security

Settings · Security

  • Configuration onlyMetadata and code. CRM records stay in Salesforce.
  • Isolated per customerEnforced by the database and tested every release.
  • Keys in Google Cloud KMSCredentials encrypted under a per-customer key.
  • Second admin for productionThe author can never approve their own change.
  • Hosted in the United StatesEvery subprocessor listed with its region.

05evidence

What evidence does an approval leave?

Every deploy's receipt records what changed, the request that produced it, the checks it passed, who approved it and when. Privileged actions across the workspace go to the activity log, which can be filtered by deploys, logins, settings and org scans.

That turns the question an auditor asks, who approved this change, into a lookup instead of an investigation.

  • Approver and time on every receipt
  • Activity log of privileged actions
  • Evidence for audits

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

06promote

How do approvals work from sandbox to production?

Changes are built and tested in a sandbox, where members deploy freely. Promoting a proposal to production brings it under the production org's policy, freeze windows and approval rule, so a change is governed by the environment it is going to rather than the one it came from.

The approver sees the same proposal the author built: the named checks, the blast radius and the before and after of every file, validated against the target org.

  • Free iteration in sandboxes
  • Target org policy on promotion
  • One proposal from author to approver

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

07How it works

An approval, end to end

The same gate for AI-built and human changes.

  1. 01

    Propose

    A member or the AI creates a proposal with checks.

  2. 02

    Policy

    The deploy policy decides what approval is needed, and says why.

  3. 03

    Approve

    An admin other than the author approves production.

  4. 04

    Deploy

    The change deploys within the policy's windows.

  5. 05

    Record

    The receipt names the approver; the activity log records the action.

08Before and after

Approvals, on paper versus enforced

Without

With SyncOnAI 360

Anyone with access can deploy

A different admin approves production

Freeze windows by email

Freeze windows enforced on deploy

Every change gets the same heavy approval

Auto-approval for low-risk work

Overrides under pressure

Failed checks block whatever the policy says

Approval evidence in chat threads

Approver and time on every receipt

09Who uses it

Who uses approval gates

Compliance and auditShow who approved every production change and when from its receipt, with self-approval in single-admin workspaces recorded in the activity log rather than hidden.Salesforce adminsApprove production changes made by others with the checks, blast radius and before and after in front of you, and set freeze windows and required approvers once.ConsultanciesKeep client production orgs behind a second admin's approval, so even a fast-moving team cannot ship to production without a reviewer.Platform teamsLet members build, propose and deploy to sandboxes freely while production stays gated, with low-risk work auto-approved so approvers focus where it matters.
ApproversApprove with everything in one place: the change, its checks, what it affects and which policy rule applied, and know that a failed check cannot be waved through.

10Questions

Frequently asked questions

A control where the person who makes a production change cannot approve it. SyncOnAI 360 enforces it when a workspace has two or more admins.

A single-admin workspace can approve its own change, and the activity log records that it did.

Yes. The deploy policy sets freeze windows, required approvers and auto-approval rules.

No. Policy can only make deploys stricter; a failed or rejected change can never be let through.

No. Any member can deploy to a sandbox, so teams can iterate. Production needs approval.

Only admins can roll back a production deploy.

On each deploy's receipt, which names the approver and time, and in the workspace activity log.

Not yet. Single sign-on and user provisioning are scoped with Enterprise customers and not shipped today.

No. Auto-approval only removes the wait for a person on low-risk work. A change that fails its checks or was rejected can never deploy.

11Keep exploring

Related

Pre-flight ChecksNamed checks before anyone approvesDeploy and ApprovalsChecks, approval, receipts, rollbackRollbackBack to the recorded previous versionSafe ChangeValidate, approve, deploy, roll backEnterprise Salesforce teamsGovern every org and every change at scalePricingEvery 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