# Change Salesforce safely, with proof for every change. > 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. Source: https://synconai360.com/platform/change-management ## Key facts - **1**: Path for every change, AI-built or human - **2**: People behind every production change - **0**: Ways for a policy to let a failed check through - **1**: Click to roll back to the recorded version ## 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. - **Review becomes a formality.** When releases are frequent, the review step gets skipped exactly when it matters, and nothing in the tooling stops it. - **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. - **Side doors into production.** Someone fixes something directly in Setup. The next deploy overwrites it, or it quietly breaks something else. - **No clean way back.** When a release causes an incident, rollback means rebuilding the old version from a sandbox or from memory. ## 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 ## 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 ## 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 ## 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 ## 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 ## One path for every change 1. **Propose.** Chat, a builder or a teammate creates a proposal. 2. **Validate.** Pre-flight checks run and the change is validated against the target org. 3. **Iterate.** Deploy to a sandbox, test, and adjust. 4. **Approve.** A different admin approves production inside the deploy policy. 5. **Deploy and prove.** Tests run, the receipt is written, and rollback is one click away. ## 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 | ## Frequently asked questions ### What is Salesforce change management? 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. ### Does SyncOnAI 360 support segregation of duties? 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. ### What does validate-only mean? 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. ### Can a deploy policy override a failed check? 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. ### What does rollback restore? 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. ### What evidence is kept for auditors? 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. ### What about changes made directly in Salesforce? The Changes lens shows whether a change came through SyncOnAI 360 or elsewhere, and the audit flags production changes made outside the pipeline. ### Does SyncOnAI 360 have single sign-on or SCIM? 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. ### Is there an audit trail for the workspace itself? Yes. The activity log records deploys, org refreshes, settings changes such as AI keys and team changes, and org connections, with filters for each. ### Do changes from AI agents follow the same path? 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. ### Can we move a change from a sandbox to production? 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.