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

> 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.

Source: https://synconai360.com/features/approvals

## Key facts

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

## 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.

- **Policy on paper.** The rule exists in a document. The tools let anyone with access deploy to production.
- **Freeze windows by email.** A change freeze is announced, and someone deploys anyway because nothing stops them.
- **Approval fatigue.** Every change needs the same heavyweight approval, so people start rubber-stamping.
- **No evidence.** When auditors ask who approved a change, the answer is a chat thread.

## 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

## 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

## 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

## 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

## 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

## An approval, end to end

1. **Propose.** A member or the AI creates a proposal with checks.
2. **Policy.** The deploy policy decides what approval is needed, and says why.
3. **Approve.** An admin other than the author approves production.
4. **Deploy.** The change deploys within the policy's windows.
5. **Record.** The receipt names the approver; the activity log records the action.

## 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 |

## Who uses approval gates

- **Compliance and audit.** Show 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 admins.** Approve 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.
- **Consultancies.** Keep client production orgs behind a second admin's approval, so even a fast-moving team cannot ship to production without a reviewer.
- **Platform teams.** Let members build, propose and deploy to sandboxes freely while production stays gated, with low-risk work auto-approved so approvers focus where it matters.
- **Approvers.** Approve 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.

## Frequently asked questions

### What is maker-checker for Salesforce?

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.

### What if we only have one admin?

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

### Can we set freeze windows?

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

### Can policy approve a change that failed checks?

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

### Do sandbox deploys need approval?

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

### Who can roll back production?

Only admins can roll back a production deploy.

### Where is approval evidence kept?

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

### Is single sign-on available for approvers?

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

### Can auto-approval skip checks?

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.