Introduction

The problem

Every system in a GTM stack can answer questions about itself. Salesforce will tell you which flows reference a field, in Salesforce. None of them can tell you that the same field feeds a HubSpot workflow, a Make scenario, a dbt model and a reverse-ETL sync, because none of them can see the others.

So the question that actually matters before a change, “what else touches this?”, gets answered by asking around. Someone remembers the integration. Someone else does not, and a sync breaks quietly three weeks later, by which point nobody connects the two events.

What Meshie does

You connect the systems you already run. Meshie reads their metadata, never their records, and builds one graph of nodes (fields, objects, flows, workflows, models, tables) and edges (the references between them). Then it answers three questions against that graph:

• Impact: what breaks if this changes, grouped by system, with the file and line each reference came from.
• Unused: which fields nothing references, and which only look that way.
• Ask: the same queries in plain language, with the evidence attached to every claim.

The same answers come out of the CLI and the API, running the same query functions the web app calls. There is one implementation of impact, not three that drift.

What Meshie does not do

• It does not deploy. Meshie reads. Changes go out through whatever pipeline you already use. The product is the verification, not the speed.
• It does not read your records. Object and field definitions, flow and workflow configuration, model and table structure. Never Contacts, Leads, Deals or their contents. The Security page lists exactly what is read per system.
• It does not replace anything in your stack. Nobody’s tool count goes down because of this. Meshie is a layer across what you have.
• It does not guess to look complete. Which is the next point, and the one worth reading.

Evidence, and the absence of it

Every edge in the graph carries where it came from: the extractor that found it, the file, and a tier saying whether it was declared in configuration, observed at runtime, or inferred. You can always get from a claim to the line of XML behind it.

The harder case is a reference Meshie can see but cannot resolve: Apex that builds a field name at runtime, a query assembled from configuration. Those become UNKNOWN edges rather than being dropped, and any node they reach is marked reachable_from_unknown. That mark outranks everything else in the product: a field with one is never reported as safe to delete, no matter how empty its reference list looks.

Where to go next

• Sample report to see a finished impact result before you connect anything.
• Quick start if you want a map of your own stack in about ten minutes.
• The graph if you would rather understand the model before you connect anything.
• The impact query for exactly what a result contains, field by field.
• CLI and API if you are here to wire Meshie into something else.
• Support if something is not working or you have a question these pages do not answer.