SyncOnAI360

Pre-flight Checks

Catch the problem before anyone is asked to approve it.

Every Salesforce change runs named checks for data loss, access changes, dependencies, deploy order and test coverage, then a validation against the real org, before it reaches an approver.

Start freeBook a demo

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

In one paragraph

SyncOnAI 360 Pre-flight Checks run on every proposed Salesforce change: destructive operations, security and access, field presence, cascading dependencies, deploy order and test coverage. Each check passes, warns or fails with a reason, the change is validated against the target org without saving anything, and a failed check blocks deployment regardless of policy.

Named checks on every proposal
6Named checks on every proposal
Outcomes: pass, warn or fail, always with a reason
3Outcomes: pass, warn or fail, always with a reason
Ways to deploy past a failed check
0Ways to deploy past a failed check
Affected components named, most important first
12Affected components named, most important first

01The problem

Why Salesforce deployments fail where nobody expects

Deploy failures are expensive because they happen late: in the release window, in front of the approver, or worse, after a deploy that succeeded and quietly broke something.

  1. 01

    Data loss by narrowing

    Shortening a text field or changing a type can discard existing data, and nothing warns you.

  2. 02

    Silent access changes

    A permission or sharing change hidden in a bundle gets approved without anyone noticing it.

  3. 03

    Wrong deploy order

    A component deployed before what it references fails, or partially succeeds.

  4. 04

    Coverage at the gate

    Apex without tests meets Salesforce's coverage requirement in production, and fails there.

02checks

Which pre-flight checks run on a Salesforce change?

Destructive operations checks whether any field change would narrow a field in a way that discards existing data. Security and access names anything that changes permissions, sharing or external access. Field presence confirms each item carries real, deployable metadata with its object and field names resolved. Cascading dependencies lists what else in the org references each component.

Deploy order confirms dependent components are deployed after what they reference. Test coverage discovery checks whether Apex in the proposal can pass Salesforce's 75% gate in production, and warns when it carries no tests of its own.

  • Destructive operations
  • Security and access
  • Field presence
  • Cascading dependencies
  • Deploy order
  • Test coverage discovery

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

03outcomes

What do pass, warn and fail mean?

Every check returns pass, warn or fail with a plain reason. Fail means the change cannot be deployed as it stands, such as an item with no deployable content or a change that would discard data. Warn means a person should look, such as an access change, which is often intended but should never be approved by accident.

The proposal also carries an overall risk, low, medium or high, and the policy decision for it, so the approver sees the whole picture in one place.

  • Pass, warn or fail with a reason
  • Access changes warn, never hide
  • Overall risk with the policy decision

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.

04validate

What does validating against the org add?

After the named checks, the change is validated against the target org without saving anything, the same validate-only deployment Salesforce provides. The errors you see are real Salesforce errors from the real org, not predictions.

A proposal that fails a pre-flight check cannot be deployed, whatever the deploy policy says. Policies can add freeze windows and required approvers, but they can never let a failed check through.

  • Validate-only against the target org
  • Real Salesforce errors
  • Failed checks always block

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

05blast

How is blast radius shown on a proposal?

The cascading dependency check lists the components that reference what the change touches, named and grouped by type, with automation and validation before access grants, because a permission set referencing a field carries less review signal than a Flow that branches on it. Up to twelve are named on the proposal.

Where impact analysis is not yet available for a metadata type, the check says so with a warning rather than reporting no impact.

  • Named affected components
  • Signal types first, access grants last
  • Unknown impact reported, not hidden

Lineage: Case.Priority

Acme Production · what uses it, what it uses

Changing the values of Case.Priority affects 6 components. Two Flows branch on the value "High" and would stop routing escalations.

  • 2 Flowsread Case.Priority and branch on it
  • 1 Apex classsets it on insert
  • 1 validation rulerequires it on escalation
  • 1 reportgroups by it
  • 1 Lightning pageshows it on the console

06daily

How do teams use pre-flight checks day to day?

Most changes pass every check and move straight to approval. The checks earn their place on the few that do not: a field narrowed in a way that would discard data, an access change nobody mentioned, a Flow that depends on what is about to change. Those are caught in seconds, before anyone is asked to approve.

Because each check gives a plain-language reason, a warning is something an approver can act on rather than a code to look up.

  • Clean changes move straight on
  • Risky ones caught before approval
  • Plain-language reasons

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

What happens before approval

Every change, whoever drafted it.

  1. 01

    Propose

    The change becomes a proposal with a before and after.

  2. 02

    Check

    Six named checks run and report pass, warn or fail.

  3. 03

    Measure impact

    Affected components are named as the blast radius.

  4. 04

    Validate

    A validate-only deploy runs against the target org.

  5. 05

    Approve

    Only then is an approver asked, with everything in view.

08Before and after

Release checks, manual versus pre-flight

Without

With SyncOnAI 360

A checklist someone may skip

Six named checks on every proposal

Data loss discovered later

Destructive operations flagged before deploy

Access changes approved unnoticed

Access changes named for the approver

Coverage failures at the gate

Coverage checked before the deploy

Overrides under deadline

Failed checks block, whatever the policy

09Who uses it

Who relies on pre-flight checks

Salesforce adminsSee in plain language why a change is safe or not before it deploys: data that would be discarded, access it changes, and what else in the org relies on it.
Approvers and release managersApprove from one view: named checks with pass, warn or fail, an overall risk, the policy decision and the components affected, rather than a file list.
Salesforce developersFind out a change will fail with real Salesforce errors from a validate-only deployment, well before a release window rather than during it.Platform ownersRely on a gate that no policy can relax: a change that fails a pre-flight check cannot deploy, whoever approves it.

10Questions

Frequently asked questions

Named checks that run on every proposed Salesforce change before an approver sees it: destructive operations, security and access, field presence, cascading dependencies, deploy order and test coverage.

No. A proposal that fails a pre-flight check cannot be deployed, whatever the policy says.

Granting access is often intended. The warning makes sure the approver notices; failing every access change would train people to override checks.

The change is checked against the target org as a deployment that saves nothing, so real Salesforce errors appear early.

The destructive operations check flags field changes that would narrow a field and discard existing data.

Yes. Test coverage discovery checks whether the proposal's Apex can pass Salesforce's coverage gate in production.

The components in the org that reference what a change touches, named on the proposal.

Yes. Every plan includes every feature.

11Keep exploring

Related

Deploy and ApprovalsChecks, approval, receipts, rollbackApproval GatesMaker-checker and deploy policyLineage and ImpactWhat breaks before you change itSafe ChangeValidate, approve, deploy, roll backApex Test CoverageReal coverage, class by classPricingEvery 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