Skip to main content

vulkro-sf consistency

Compares the metadata of two retrieved orgs (typically a sandbox against production) and reports where they have diverged. Org drift is the silent failure mode behind "it worked in the sandbox": a field, a validation rule, or a flow version that exists in one org but not the other, so a deploy that was safe in test breaks in production.

The command works over two retrieved metadata folders. No live connection is opened by consistency itself: retrieve each org with your sf CLI first, then point the command at the two folders.

Synopsis​

vulkro-sf consistency --base <path> --target <path> [flags]

Flags​

FlagTypeDefaultDescription
--base <path>string(required)The reference org's retrieved metadata folder (for example the sandbox).
--target <path>string(required)The org being compared against the base (for example production).
--format <fmt>enumtableOutput format: table (human-readable on the terminal) or json (machine-readable, for piping into a release-gate check).

Exit codes​

  • 0 - the two orgs are consistent within the checked metadata scope.
  • 1 - divergence was found and reported.
  • 2 - error: a folder is missing or unreadable, the metadata could not be parsed, or an internal error. The message names the cause and the next step.

What it does​

consistency builds a metadata index for each folder and diffs them, emitting two finding classes:

  • SF-MULTIORG-001: component present in one org only. A metadata component (object, field, flow, validation rule, permission set, and others) that exists in the base but not the target, or the reverse. This is the divergence that breaks a deploy: source references a component the destination org does not have.
  • SF-MULTIORG-002: component present in both but materially different. A component present in both orgs whose definition has drifted: a field with a different type or length, a flow whose active version differs, a validation rule with a changed formula, a permission set granting a different scope. The two orgs agree the component exists but disagree on what it is.

Each finding names the component, the divergence class, and which side holds which value, so a release engineer can decide whether to align the orgs or block the deploy.

Example​

# Compare a retrieved sandbox against retrieved production.
vulkro-sf consistency --base ./sandbox-metadata --target ./prod-metadata

# JSON for a release-gate check in CI.
vulkro-sf consistency --base ./sandbox-metadata --target ./prod-metadata \
  --format json > consistency.json