Is this Salesforce deployment risky? A pre-deployment impact review from package.xml or git diff

What a pre-deployment review must cover

The native tools, and what they leave out

Validation deploy. The Salesforce CLI command sf project deploy validate checks that a deployment would succeed without deploying it. It requires Apex tests, and it returns a job ID you can pass to sf project deploy quick within 10 days. Its help text says it is meant for production orgs. For a sandbox, it suggests sf project deploy start --dry-run --test-level RunLocalTests. Test levels are RunAllTestsInOrg, RunLocalTests, RunSpecifiedTests and RunRelevantTests (beta). Destructive manifests go in with --pre-destructive-changes or --post-destructive-changes.

A validation proves the change compiles and the chosen tests pass. It does not list what depends on what you changed. Compiling also does not check a field named inside a dynamic SOQL string. That fails only when the code runs, and only if a test happens to run it.

Dependency API. The Tooling API object MetadataComponentDependency lists dependencies between components. Salesforce’s Tooling API guide (Winter ‘27) still labels it Beta and “for evaluation purposes only, not for production use”. A Tooling API query returns at most 2,000 records and leaves out reports. Bulk API 2.0 raises that to 100,000 records and includes reports.

By hand. Open each flow and trigger on each touched object. This works for small changes. It does not scale to a 40-file pull request.

Step by step

1. Get the change list. Use the shape you already have:
   • a package.xml, plus destructiveChanges.xml for deletions,
   • the changed files from git diff --name-status main...HEAD,
   • or a plain list of components, with “added”, “modified” or “deleted” for each.
2. Mark the deletions. Deletions carry the most risk. Treat a renamed component as a deletion plus an addition.
3. For each deletion, list what depends on it. Any dependent means the change is not ready.
4. For each modified component, list its callers. Apex classes, triggers, flows and formulas that use it.
5. Check the automation on each touched object. Look for two automations writing the same field, and for anything that saves the record again.
6. Select the tests. Find the test classes that reach the changed Apex. Run them with --test-level RunSpecifiedTests --tests ... in a validation deploy.
7. Check access for new fields and objects. Confirm a permission set grants each one.
8. Write down what you could not check. Unresolved names, wildcard members (*) and metadata types you cannot inspect all keep the answer at “review first”.

How go, review first and no-go are decided

The rule that matters most: never “go” while anything in the change set was left unreviewed. A short list of problems is only good news if the list is complete.

With sf-intelligence

sf-intelligence runs this review on your computer, from the metadata it retrieved from your org. Ask your AI assistant: “Is this deployment risky?” and paste the package.xml and destructiveChanges.xml, or the git diff --name-status output. The assistant runs the review_change analysis.

Here is a real review on Verdant, the built-in demo org. The change set modifies an Apex class and a flow, and deletes a field:

<!-- package.xml -->
<types><members>ProjectTriggerHandler</members><name>ApexClass</name></types>
<types><members>Installation_On_Complete</members><name>Flow</name></types>

<!-- destructiveChanges.xml -->
<types><members>Invoice__c.Amount__c</members><name>CustomField</name></types>

The decision is no-go. Here is why:

"deployDecision": {
  "decision": "no-go",
  "reasons": [
    "1 blocking change(s): CustomField:Invoice__c.Amount__c (3 dependent(s))",
    "1 risky change(s) with firm dependents: ApexClass:ProjectTriggerHandler",
    "1 change(s) need manual review"
  ]
},
"reviewed": [
  { "id": "CustomField:Invoice__c.Amount__c", "changeKind": "deleted", "verdict": "blocking",
    "dependents": ["ApexClass:PaymentService", "CustomField:Invoice__c.Balance__c",
                   "CustomField:Project__c.Total_Invoiced__c"] },
  { "id": "ApexClass:ProjectTriggerHandler", "changeKind": "modified", "verdict": "risky",
    "dependents": ["ApexTrigger:ProjectTrigger"], "testCoverage": "covered",
    "selectedTests": ["ApexClass:PaymentServiceTest", "ApexClass:ProjectTriggerHandlerTest"] },
  { "id": "Flow:Installation_On_Complete", "changeKind": "modified", "verdict": "review" }
]

The same change as git paths gives the same decision. It also lists README.md as skipped, because it is not metadata:

D	force-app/main/default/objects/Invoice__c/fields/Amount__c.field-meta.xml
M	force-app/main/default/classes/ProjectTriggerHandler.cls
M	README.md

Two more real results from the demo org:

• A list of names with no change kind gives review-first, with the reason that it was “reviewed as ‘modified’ because no change kind was given”. A deletion in that list would be under-called, so say which items are deletions.
• Adding a new field gives go. With the access check turned on, the same answer also warns that the field “would deploy with access to NOBODY”, because no permission set grants it. The decision stays go, so read the access warning too.

What it does not cover: changes made in the org since your last refresh, code inside managed packages, and fields named in string-built dynamic SOQL. It selects tests. It does not prove they test the right thing. The same review can also run in CI as a GitHub Action.