How Salesforce and HubSpot become one canonical identity in the META database, in five connected stages: the inputs that land in Reporting, the lift & ER map that carries them to Transfer, the custodian agent that resolves them, the human-in-the-loop that confirms the uncertain, and the canonical record every downstream app reads. Pick a stage below, or walk them in order.
Everything we pull from Salesforce & HubSpot — per field, where it lands in Reporting, when it last pulled, and what we could pull but don’t.
Freshness · Mechanisms · Salesforce · HubSpot →The pg_cron lift from Reporting → Transfer, the ER map that resolves each row to a canonical made_id, and how it’s meant to stay in sync.
The self-contained agent that runs it: its knowledge, its matching methodology, its five skills, its tools, its runs, and a memory that learns over time.
Knowledge · Methodology · Skills · Tools · Run · Memory →What a person actually does on /made-id-review: the six review surfaces, when a match is routed to a human, and how merges & mints are confirmed.
What “one MADE-ID” is: the canonical company record, the identity map, provenance, the merge mechanic, and the downstream apps that read it.
The record · Identity map · Provenance · Downstream →SFDC + HubSpot → edge functions + n8n → Reporting sfdc_*/hubspot_*
sync_*_from_reporting → Transfer; er_identity_map resolves to made_id
watch · verify · match · mint · merge · learn — propose-only
/made-id-review — a person confirms the uncertain
one companies.made_id / contact_made_id, read by every app
The custodian proposes; a human commits every uncertain link. The only fully-automatic write is the ≥0.999 auto-merge primitive. Nothing is ever silently deleted — sub-floor candidates land in a census so the next run knows they were already examined. This is what keeps the identity system trustworthy as it scales.
xyopyttkhoxvnyeyijzb + Transfer jrfcfayphcmaxsixxupu, 2026-09-09 22:00 UTC. Not for external share.