SyncOnAI360

Ship safely

Change Salesforce safely, with proof for every change.

Every change, from the AI or a person, takes one path: named checks, its blast radius, validation against the org, a second admin's approval for production, a receipt, and a way back.

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 Safe Change is the governance path for every change to a Salesforce org. Changes become proposals with named pre-flight checks and blast radius, are validated against the target org, need an admin other than the author to approve production, deploy under a workspace policy, and leave a receipt with rollback to the previous version.

Path for every change, AI-built or human
1Path for every change, AI-built or human
People behind every production change
2People behind every production change
Ways for a policy to let a failed check through
0Ways for a policy to let a failed check through
Click to roll back to the recorded version
1Click to roll back to the recorded version

01The problem

Why governance breaks down as Salesforce change speeds up

Most Salesforce governance is a process on paper: a review meeting, a change log, a release checklist. It works until the volume of change goes up, and AI has just made the volume go up a lot.

  1. 01

    Review becomes a formality

    When releases are frequent, the review step gets skipped exactly when it matters, and nothing in the tooling stops it.

  2. 02

    Segregation of duties on paper

    Policies say the builder cannot approve their own change; the tools let them. Auditors ask for evidence that the policy was enforced.

  3. 03

    Side doors into production

    Someone fixes something directly in Setup. The next deploy overwrites it, or it quietly breaks something else.

  4. 04

    No clean way back

    When a release causes an incident, rollback means rebuilding the old version from a sandbox or from memory.

02validate

How are Salesforce changes validated before approval?

Every change is a proposal. It shows named pre-flight checks, each with a pass or the reason it failed, a before and after view of every file, a risk badge with the policy decision, and its blast radius: everything else in the org that uses the components being changed.

Before it is offered for approval, the proposal is validated against the target org without changing anything, the same validate-only deployment Salesforce provides, so the errors are real. A proposal that fails a pre-flight check cannot be deployed, whatever the policy says.

  • Named pre-flight checks with reasons
  • Blast radius from the org's dependency graph
  • Validate-only against the target org
  • Failed checks block deployment, always

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

03approve

How does maker-checker approval work for Salesforce?

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

Only admins can approve production changes, edit the deploy policy or roll back production. Members chat, build, propose and deploy to sandboxes. The roles are simple enough to explain to an auditor in one sentence.

  • Maker and checker are different admins
  • Single-admin exception 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 release policy in Salesforce deploys?

The deploy policy sets freeze windows, required approvers and auto-approval rules for low-risk changes, and every proposal explains which rule applied to it. A policy can only make deploys stricter: it can never let through a change that failed its checks or was rejected.

Changes move from a sandbox to production by redeploying the same proposal to the target org, where that org's policy and freeze windows apply. The audit flags production changes made outside the pipeline, so side doors show up rather than stay hidden.

  • Freeze windows and required approvers
  • Auto-approval only for what policy allows
  • Sandbox to production under the target's rules
  • Changes outside the pipeline flagged by the audit

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

05prove

What evidence does every Salesforce deploy leave?

Deploys run through the Salesforce Metadata API, and production deploys that include Apex run its tests at Salesforce's 75% coverage bar. Every deploy leaves a receipt: what changed, the request that produced it, the checks it passed, who approved it and when.

Roll back from the receipt and the version of each component recorded before the deploy is redeployed. Components the deploy created are not deleted by a rollback and are removed separately. Privileged actions across the workspace are written to an activity log, and deployed components are read back immediately after a successful deploy.

  • Receipts naming request, checks, approver and time
  • Rollback to the recorded previous version
  • Activity log of privileged actions
  • Deployed changes read back immediately

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

06activity

What does the workspace activity log record?

Alongside each deploy's receipt, the workspace activity log records who did what across the workspace: deploys started, succeeded or failed, org metadata refreshes, settings changes such as an updated AI key or a team change, and org connections. Filters narrow it to deploys, logins, settings or org scans.

Admins use it to show who changed an AI key or connected an org, delivery leads to trace deploy activity across the team, and compliance teams to supplement audit exports with workspace actions. It records privileged activity rather than every read, and says so.

  • Deploys, org refreshes, settings and connections
  • Filters for deploys, logins, settings and scans
  • A record of privileged activity for compliance

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

07How it works

One path for every change

The same governance whether the change came from the AI, a builder or a person.

  1. 01

    Propose

    Chat, a builder or a teammate creates a proposal.

  2. 02

    Validate

    Pre-flight checks run and the change is validated against the target org.

  3. 03

    Iterate

    Deploy to a sandbox, test, and adjust.

  4. 04

    Approve

    A different admin approves production inside the deploy policy.

  5. 05

    Deploy and prove

    Tests run, the receipt is written, and rollback is one click away.

08Before and after

Governance, on paper versus enforced

Without

With SyncOnAI 360

Reviews skipped under deadline pressure

Failed checks block deployment regardless of policy

Builders approving their own changes

A different admin approves production

Freeze windows in a calendar invite

Freeze windows enforced on every deploy

Direct changes in production go unnoticed

Changes outside the pipeline flagged by the audit

Rollback by rebuilding from memory

Rollback to the recorded previous version

09Questions

Frequently asked questions

The controls around how changes reach a Salesforce org: review, validation, approval, deployment and the ability to reverse. SyncOnAI 360 enforces them in the product rather than in a document.

Yes. With two or more admins, the approver of a production change must be an admin other than the person who made it. A single-admin workspace can approve its own change, and the activity log records it.

The change is checked against the target org as a deployment that does not save anything, so real Salesforce errors appear before anyone is asked to approve.

No. A policy can make deploys stricter, with freeze windows and required approvers, but it can never let through a change that failed its checks or was rejected.

It redeploys the version of each component recorded before the deploy. Components the deploy created are not deleted by a rollback and need removing separately.

Each deploy receipt records what changed, the request behind it, the checks, the approver and the time, and privileged actions are written to the activity log.

The Changes lens shows whether a change came through SyncOnAI 360 or elsewhere, and the audit flags production changes made outside the pipeline.

Not yet. Single sign-on and user provisioning are not shipped; they are scoped with Enterprise customers. The Trust Center lists what is in place today.

Yes. The activity log records deploys, org refreshes, settings changes such as AI keys and team changes, and org connections, with filters for each.

Yes. Every change, whether drafted by the chat, an agent, a builder or a person, becomes a proposal with checks and the same approval rules.

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.

10Keep exploring

Related

Deploy and ApprovalsChecks, approval, receipts, rollbackLineage and ImpactWhat breaks before you change itEnterprise Salesforce teamsGovern every org and every change at scaleTrust CenterWhat we hold and how it is protectedPlatformUnderstand, build, ship and deliver in one workspacePricingEvery 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