vulkro-sf impact-flow
Computes the data-flow blast radius of a planned change before you
deploy it. Given a set of components you intend to add, change, or
remove, impact-flow traces every downstream dependency through the
automation and reference graph and reports what the change would
ripple into. It answers the question that causes most deploy incidents:
"what else does this touch?"
Runs over the local project against a change set you supply. No org connection is required.
Synopsis
vulkro-sf impact-flow [PATH] --change <path> [flags]
PATH defaults to the current directory. --change points at the set
of components the deploy will modify (an SFDX package.xml, a diff
manifest, or a folder of changed metadata).
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--change <path> | string | (required) | The planned change set: a package.xml, a manifest of changed component names, or a folder of changed metadata. |
--format <fmt> | enum | table | Output format: table (human-readable blast-radius summary) or json (machine-readable dependency records, for a deploy gate). |
Exit codes
0- the change set has no detected downstream impact beyond the changed components themselves.1- downstream impact was found and reported (SF-PREDEPLOY-001and/orSF-PREDEPLOY-002fired).2- error: the change set could not be read, the project could not be parsed, or an internal error. The message names the cause and the next step.
What it does
impact-flow resolves each component in the change set into a node and
walks the dependency graph outward, emitting two finding classes:
- SF-PREDEPLOY-001: downstream data-flow impact. A component in the change set is read or written by automation (flows, Apex, validation rules, reports) that is not itself in the change set. Changing the component's type, removing it, or altering its behaviour would change what that downstream automation does. The finding lists each affected downstream component and the path from the change to it.
- SF-PREDEPLOY-002: high-blast-radius change. A component in the change set whose downstream dependent count exceeds a configurable threshold, marking the change as wide-reaching. This is the "renaming this field touches 40 flows" warning, surfaced before the deploy rather than after.
The output ranks impacted components by path length and dependent count so a release engineer can see the riskiest part of the change first.
Example
# Blast radius of a planned deploy described by a package.xml.
vulkro-sf impact-flow . --change ./manifest/package.xml
# JSON for a pre-deploy gate in CI.
vulkro-sf impact-flow . --change ./changed-metadata --format json > impact.json