# Catch the problem before anyone is asked to approve it. > 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. Source: https://synconai360.com/features/preflight ## Key facts - **6**: Named checks on every proposal - **3**: Outcomes: pass, warn or fail, always with a reason - **0**: Ways to deploy past a failed check - **12**: Affected components named, most important first ## 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. - **Data loss by narrowing.** Shortening a text field or changing a type can discard existing data, and nothing warns you. - **Silent access changes.** A permission or sharing change hidden in a bundle gets approved without anyone noticing it. - **Wrong deploy order.** A component deployed before what it references fails, or partially succeeds. - **Coverage at the gate.** Apex without tests meets Salesforce's coverage requirement in production, and fails there. ## 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 ## 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 ## 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 ## 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 ## 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 ## What happens before approval 1. **Propose.** The change becomes a proposal with a before and after. 2. **Check.** Six named checks run and report pass, warn or fail. 3. **Measure impact.** Affected components are named as the blast radius. 4. **Validate.** A validate-only deploy runs against the target org. 5. **Approve.** Only then is an approver asked, with everything in view. ## 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 | ## Who relies on pre-flight checks - **Salesforce admins.** See 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 managers.** Approve 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 developers.** Find out a change will fail with real Salesforce errors from a validate-only deployment, well before a release window rather than during it. - **Platform owners.** Rely on a gate that no policy can relax: a change that fails a pre-flight check cannot deploy, whoever approves it. ## Frequently asked questions ### What are pre-flight checks? 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. ### Can a failed check be overridden? No. A proposal that fails a pre-flight check cannot be deployed, whatever the policy says. ### Why do access changes only warn? Granting access is often intended. The warning makes sure the approver notices; failing every access change would train people to override checks. ### What does validate-only mean? The change is checked against the target org as a deployment that saves nothing, so real Salesforce errors appear early. ### Does it catch data loss? The destructive operations check flags field changes that would narrow a field and discard existing data. ### Does it check Apex coverage? Yes. Test coverage discovery checks whether the proposal's Apex can pass Salesforce's coverage gate in production. ### What is blast radius? The components in the org that reference what a change touches, named on the proposal. ### Are pre-flight checks on every plan? Yes. Every plan includes every feature.