Meshie
All documentation

The impact query

What breaks if you change this. One node in, every direct reference back, with the evidence to check each one yourself.

What it answers

Point it at a field, a picklist value, or any other node in the graph, and it answers one question: what in this org, and every connected one, references it right now. Not a guess from a name match, a traversal of edges Meshie already extracted from real configuration, each one carrying where it came from and how sure the extractor is.

It is the query the web app, the CLI (meshie impact), and the API all call the same way. There is one implementation, not three that can drift apart.

What a result contains

Fieldtarget_idMeaningThe node you asked about, echoed back so a result is never ambiguous about what it describes.
Fieldtarget_view_urlMeaningA link into the real system (Salesforce, HubSpot, ...), when one can be built with confidence. Null for component types a static export cannot address directly, see below.
Fielddirect_referencesMeaningEvery node with an edge into the target. Each row carries its own source_id, edge_type, tier, confidence, evidence_file and view_url.
Fieldreachable_from_unknownMeaningTrue if some path to this node passes through an edge Meshie could not resolve. The single field to check before trusting the list is complete.
Fieldaffected_by_systemMeaningThe same references, grouped by which connected system each one lives in, so “does this touch HubSpot” is a lookup, not a scan of the list.
FielddepthMeaningHow many hops the traversal ran. Direct references only today (depth 1); see the note below.
FieldcoverageMeaningWhich connected systems this answer read and which it could not: the checked / not-checked strip, see below.

Reading one reference row

Every entry in direct_references is a claim you can check, not one you have to trust:

  • tier says where the edge came from: DECLARED (read straight out of static configuration), OBSERVED (a runtime or integration-layer signal), or INFERRED (derived from other edges). See Tiers and confidence for what each one does and does not promise.
  • confidence is a number from 0 to 1, independent of tier: an exact reference in configuration is 1, a name match that needed a heuristic is lower and shown as-is rather than rounded away.
  • evidence_file is the path to the exact file the edge was extracted from, so a result is never just an assertion. It is relative to the system’s metadata root, for example objects/Account/fields/Status__c.field-meta.xml.
  • view_url is a best-effort deep link to the reference’s own row in its source system, null whenever one cannot be built with confidence (Salesforce Flows, Apex and reports need an internal record id a static export does not carry, so those are always null today).

Checked and not checked

A reference list is only as complete as the systems it was read from. Every result therefore carries coverage, and the app shows it as one row under the verdict: the hubs this answer checked, and the hubs it could not. A hub lands in the second group for one of two reasons, each stated on the row:

  • NOT_CONNECTED: a connected-app record in a system you did connect names a hub Meshie has an adapter for, but that hub is not connected here. “HubSpot detected as connected but not monitored; edges into it are not visible.” The row links straight to that hub’s connect step.
  • SCAN_FAILED: the hub is connected, its latest scan failed, and no earlier scan exists to read. Nothing from it is in the answer.

A checked hub whose latest scan failed but has an older scan to read is marked STALE: it is in the answer, from data that may be out of date. coverage.complete is true only when every hub is plainly CHECKED. When it is false and the reference list is empty, the headline reads “No references found in the systems checked” rather than “Nothing references this”: an unchecked hub makes an empty list a partial answer, never a safe-to-delete verdict.

coverage.detection_measured is false when no connected hub has yet reported which other systems touch it (an uploaded export never does). An empty not-checked group then means “unknown”, and the app says so, not “none”.

Deep links

target_view_url and each reference’s own view_url point into the system the node actually lives in: a Salesforce Setup page, a HubSpot property editor, wherever the thing you are looking at can be opened and edited. They are never links back into Meshie. A null means no reliable link could be built for that component type yet, not that the reference is somehow less real.

Depth, today and later

depth is always 1 right now: the result is the target’s direct references, not a transitive closure. A field used by a Flow that is itself invoked by three other Flows shows the one direct reference, not four. Widening this is a known next step, tracked against the query’s own spec rather than shipped quietly, so a change in what depth means is a documented one, not a surprise in the shape of a response you already parse.

Calling it yourself

Same query, three ways in:

meshie impact salesforce:CustomField:Account.Status__c
No account, against a local metadata export.
meshie remote impact salesforce:CustomField:Account.Status__c --json
Against a hosted workspace, from the CLI.
curl "https://meshie.ai/api/w/acme/graph/impact?id=salesforce:CustomField:Account.Status__c" \
  -H "Authorization: Bearer agtm_..."
Straight over HTTP, with a CLI token.

Full route reference, request/response shapes and error statuses live on the API page; command flags and exit codes live on the CLI page.