Where it sits: the first stage of the spine. Everything from SFDC + HubSpot lands in the Reporting database (xyopyttkhoxvnyeyijzb); the next stage (Lift & ER map) carries it to Transfer and resolves it to one made_id. This page is the per-field truth: what we pull, how, when it last pulled, and what we could pull but don’t.
The authoritative “when did it last pull” ledger. All CRM source feeds are fresh — re-verified 2026-09-09, most recent pulls 21:15–21:39 UTC against source records modified the same day. The dormant piece is the legacy identity crosswalk (external_ids / external_ids_account), unchanged since 2026-06-11 — see stage ② for why that is narrower than it sounds. Pipeline in one line: SFDC/HubSpot → edge functions + legacy n8n → Reporting sfdc_*/hubspot_*.
Worth stating plainly, because it changed the plan: the CRM feeds work and are current. Notably, Reporting’s own scheduler contains no Salesforce or HubSpot contact job at all — core object extraction runs in Joe’s n8n Cloud, which the consulting team can read but not edit. So the piece we cannot change is the piece that is working. Hardening ingestion is worth doing, but it moved later in the plan; the losses are downstream, in identity resolution.
sync-hubspot Edge Function is deployed but dormant — n8n is the real producerIts last sync_log entry is 2026-08-06 (17,654 records), yet hubspot_contacts.fetched_at is current to tonight. The mirror is therefore being written by something else — Joe’s n8n Cloud — while the in-repo Edge Function sits idle. Two consequences worth holding onto: the EF is not the contract to reason about when asking “how does HubSpot data arrive,” and reading its code tells you about a path that is not currently running. Establishing one owner per feed, with the dormant duplicates retired, is Stage F of the plan.
The MSS rebuild’s six destination tables (hubspot_v2_companies, _contacts, _campaigns, _campaign_members, _campaign_assets, _campaign_engagement) hold 0 rows between them — its workflows are inactive and their credential slots were never filled. Meanwhile mss-watchdog still runs every 30 minutes on Reporting, monitoring a pipeline that cannot produce rows. A watchdog guarding nothing trains people to ignore alerts; it needs an explicit retire-or-revive decision.
| Feed (source_key) | Landing table | Rows | Last pulled (max_ts) | State |
|---|
A mix. Salesforce + most HubSpot feeds are Supabase Edge Functions — Deno TypeScript in our repo (supabase/functions/), token/OAuth-authed, invoked by pg_cron. HubSpot companies + SFDC contact-roles/stage-history run on Joe’s n8n Cloud (visual flows, code not in our repo). No CLI tools, no standalone web apps. The lift is pg_cron SQL on Transfer.
| Feed / object | Mechanism | Code & where | Auth | Cadence |
|---|
Dual-writer caveat: some Reporting tables (e.g. sfdc_accounts) were historically written by both the describe-EF (sfdc-local) and legacy n8n — the EF is authoritative today (~14,200 recs twice daily); hubspot-nightly-n8n still logs an error (0 recs) every run, a dead legacy leg.
Manipulation (every object): SELECT named fields → paginate → skip relationship payloads · alias-rename to snake_case · drop-list · "" → null · fetched_at · upsert on conflict key · log to sync_log. Authoritative list: supabase/functions/sync-sfdc/_generated_fields.ts.
Contacts are a thin, hand-picked pull; companies ride legacy n8n; deals + associations + per-contact engagement are not pulled. This is the redesign’s real work.