# How to deploy Salesforce changes to production without the fear.

> Deploying safely with SyncOnAI 360 means every change is a proposal that runs named pre-flight checks and a validation against the target org, production waits for an approved proposal from a second admin where there is one, the deploy policy enforces freeze windows, and every deploy leaves a receipt with rollback.

Source: https://synconai360.com/use-cases/safe-deployment

## Key facts

- **6**: Named pre-flight checks
- **2**: People on production in multi-admin workspaces
- **0**: Rules that can pass a failed check
- **Every**: Deploy with a receipt

## Why Salesforce production deploys go wrong

Most failed deploys were preventable: data discarded by a narrowed field, an access change nobody noticed, a dependency nobody checked, coverage that fell short.

- **Unchecked changes.** Changes go to production because they worked in a sandbox.
- **One pair of eyes.** The author approves their own work.
- **Bad timing.** Deploys land during quarter end or a client freeze.
- **No way back.** Reverting means rebuilding the old version by hand.

## Which checks run before a Salesforce deploy?

Destructive operations, security and access, field presence, cascading dependencies, deploy order and test coverage. Each returns pass, warn or fail with a plain reason, and the proposal carries an overall risk of low, medium or high.

- Six named checks
- Pass, warn or fail with reasons
- Overall risk

## How is a change validated before deploy?

After the named checks, the change is validated against the target org without saving anything, Salesforce's own validate-only deployment. The errors shown are real errors from the real org.

- Validate-only against the target
- Real Salesforce errors
- Nothing saved

## Who approves a production deploy?

Production needs an approved proposal, and in a workspace with two or more admins the approver must be someone other than the author. A single-admin workspace can approve its own change, and the activity log records that it did.

- Maker-checker for production
- Single-admin approvals recorded
- Sandboxes stay quick

## How do you stop deploys at the wrong time?

The deploy policy sets freeze windows, required approvers and auto-approval for low-risk work. A policy can make deploys harder but can never let through a change that failed its checks or was rejected.

- Freeze windows
- Required approvers
- Never overrides a failed check

## What is left behind after a deploy?

A receipt: what changed, the request behind it, the checks, who approved it and when, and the version of each component recorded before. Roll back from the receipt; components the deploy created are removed separately and data changes cannot be reversed.

- A receipt per deploy
- Rollback to recorded versions
- Limits stated

## How do AI-built changes deploy safely?

Changes the AI or the agents draft go through exactly the same path as hand-built ones: a proposal with named checks, validation against the org, approval for production, and a receipt that records the request that produced the change.

Anything that would change records directly, such as anonymous Apex, waits for a person to press Allow, because data changes cannot be rolled back.

- Same path as hand-built work
- The request recorded on the receipt
- Data changes need Allow

## How to deploy safely

1. **Propose.** Build or describe the change.
2. **Check.** Read the named checks and risk.
3. **Validate.** Validate against the target org.
4. **Approve.** A second admin approves production.
5. **Deploy.** Deploy with a receipt and rollback.

## Production deploys, hopeful versus governed

| Without | With SyncOnAI 360 |
|---|---|
| It worked in the sandbox | Validated against the target org |
| The author approves | A second admin approves |
| Deploys at quarter end | Freeze windows enforced |
| Rebuilding the old version | Rollback from the receipt |

## Pre-deployment checklist

- [ ] Make sure the change exists as a proposal, not an edit in Setup.
- [ ] Read every named check, and resolve anything that fails.
- [ ] Look at warnings, especially access changes, and confirm they are intended.
- [ ] Validate against the target org and read any Salesforce errors.
- [ ] Check the deploy policy's freeze windows.
- [ ] Get approval from an admin other than the author.
- [ ] Know the rollback limits before you deploy.

## Who deploys safely

- **Release managers.** Govern one path for every change.
- **Salesforce admins.** Ship configuration with the checks a reviewer would run.
- **Developers.** Find failures in seconds, not in the release window.
- **Consultancies.** Deploy to client orgs with evidence and an undo.

## Frequently asked questions

### Does SyncOnAI 360 deploy through the Metadata API?

Yes, after validation against the org and approval.

### Can a deploy skip the checks?

No. A change that fails a check cannot deploy, whatever the policy says.

### Do sandbox deploys need approval?

No. Members can deploy to sandboxes freely.

### What if a deploy fails?

Salesforce's reason is shown, and Fix in chat opens the conversation with the error.

### Can we see who approved a deploy?

Yes, on its receipt.

### Does rollback reverse data changes?

No. It restores recorded metadata.

### Can deploy results go to Slack?

Yes. Every deploy result can post to a Slack channel.

### Is this on every plan?

Yes. Every plan includes every feature.

### Can a change be promoted from a sandbox?

Yes. Promoting a proposal to production brings it under the production org's policy and approval.

### What does the approver see?

The checks, risk, policy decision, affected components and a before and after of every file.

### What is deploy order?

One of the named checks: it confirms the components in a change will deploy in an order Salesforce accepts.

### Can low-risk changes skip the wait?

Auto-approval rules can approve low-risk work, but never a change that failed a check.