Lesson 2 of 6 · 48 min

CRM data modeling & hygiene

The Salesforce object model vs HubSpot’s shared-database property model, which side hosts the join, dedup that survives scale (normalize → hash → fuzzy → semantic), matching rules and duplicate jobs, and the lifecycle plumbing that breaks most automations — with the schema-design interview drill.

The join you draw decides everything

Before any enrichment or scoring, you model the CRM — and the single decision that ripples furthest is which object parents which. RevBlack puts it sharply: “HubSpot starts with people. Salesforce starts with companies.” Every “single source of truth” interview prompt is implicitly asking which side hosts the join. Get the model wrong and dedup, routing, and reporting all inherit the bug. This lesson is the data layer the rest of the stack stands on — and the schema-modeling exercise is one of the four canonical GTM-engineer technical rounds.

In Salesforce, the model is objects + fields + relationships. The four GTM-anchoring standard objects are Account, Contact, Lead, and Opportunity. A single Contact can relate to multiple Accounts, and Accounts support hierarchy and account-team modeling — which makes the Account the natural join table for any cross-sell motion. Schema Builder lets you add custom objects interactively, but every custom object adds API quota and report-fanout cost, so mature orgs map ICP signals one-to-one onto discrete custom objects rather than stuffing freeform notes onto Account. The Lead-vs-Contact split is load-bearing: Leads are unqualified and convert into a Contact + Account, and your dedup logic has to span that conversion boundary.

HubSpot’s model is objects + properties + associations, and the architectural difference that matters is the single database shared across Marketing Hub, Sales Hub, Service Hub, and Operations Hub. A custom property on the Contact object is visible to workflows, lists, reports, and the AI assistant without syncing — the cognitive model is “object = noun, property = attribute, association = verb.” HubSpot is person-centric: the Company object holds firmographics, the Contact object holds the person, and you decide where the join lives. Interview angle. A Salesforce-first answer must mention the Lead/Contact split and Account hierarchy; a HubSpot-first answer must mention Company vs Contact and the shared DB — either way, a strong answer names data-provenance fields, not just raw values.

HubSpot’s Data ModelHubSpot Admin HUG

code

1SALESFORCE vs HUBSPOT — the model philosophy that drives your merge logic23  Dimension          Salesforce                       HubSpot4  ----------------   ------------------------------   --------------------------------5  Primitive          object + field + relationship    object + property + association6  Standard objects   Account, Contact, Lead, Opp      Company, Contact, Deal, Ticket7  Starts from        companies (Account-centric)      people (Contact-centric)8  Customization      Apex triggers, flows, formulas   Workflows, Ops Hub custom code9  Cross-team view    per-object, sharing rules + OWD  single DB, shared automatically10  Dedup primitive    matching rules + duplicate jobs  native + Insycle/Koalify11  Choose when        enterprise, deep customization   SMB/mid-market, velocity > leverage1213  The "single source of truth" prompt = "which side hosts the join, and where14  does provenance (source, confidence, enrichment status) live?"

Pick the CRM on change-management budget, not feature list

The senior framing is that HubSpot vs Salesforce is a velocity-vs-leverage trade, decided on three axes — deal size, headcount of RevOps engineers, and customization need — not on a feature checklist. HubSpot wins fast SMB/mid-market deployment with shared objects and a no-code property layer; Salesforce is the heavyweight with deep Apex/Visualforce/LWC customization and an admin team to run it. The recommended pattern: pick the CRM that matches your change-management budget, then model ICP signals as discrete properties or objects instead of freeform text. A custom object you can’t staff the maintenance of is a liability, not leverage.

Where the two models bite differently: in Salesforce, a web-to-lead POST hits an Apex trigger that runs matching rules — if a duplicate, it routes to the existing Account’s lead workflow; else it creates Lead + Contact + Account. The routing and assignment logic that low-code can’t express at scale lives in Apex. In HubSpot, the same flow is a Workflow plus an Operations Hub custom-code action (NodeJS 12.x) that calls a CRM webhooks endpoint to push the scored record back and update the lifecycle stage. Same funnel, two very different customization loci — and an interviewer will expect you to know which knob you’re reaching for in each.

Dedup that survives scale: normalize → hash → fuzzy → semantic

Deduplication is the silent killer, and the senior architecture is a four-layer cascade where each layer is cheaper and catches a different class of duplicate. (1) Normalize: lowercase the email, strip dots from Gmail local-parts, normalize country codes and company suffixes — this stops trivially-different records from looking different. (2) Exact match: hash (tenant, normalized_email) with SHA-256 and dedup on collision — cheap and mandatory. (3) Fuzzy match: Damerau-Levenshtein or Jaro-Winkler on company name and domain to catch typos and “Inc.” vs “Incorporated.” (4) Semantic dedup: embed records (the OpenAI clustering recipe uses 1536-dimensional embeddings, k-means, then names clusters) for genuinely noisy input like free-text company names scraped off event badges.

The first two layers are non-negotiable and nearly free; the fuzzy layer catches the bulk of remaining accidents; the semantic layer is reserved for noisy upstreams. The trap interviewers plant: embedding-based dedup with no distance threshold — k-means will happily cluster unrelated records into one if you don’t set a cosine cutoff, so you tune the threshold on a labeled evaluation set. Octave’s warning is the design principle: “Fix the root cause, not just the symptoms.” Merging a list after an SDR pass loses assignment history and breaks SLAs, so you dedup before routing, not after.

A field-level subtlety that separates a real dedup design from a textbook one: which record survives the merge, and which fields win. When two records collapse into one, you don’t want last-write to clobber a verified email with a stale one — you want a survivorship rule: keep the highest-confidence value per field, preserve the earliest created_at and the most recent activity, and union the engagement history rather than picking one record’s. This is exactly why provenance fields (L2’s confidence, source, verified flag) earn their keep — the merge logic reads them to decide winners field-by-field. A dedup that just deletes the “newer” duplicate can throw away the better data; survivorship is the senior detail interviewers listen for.

python

1# Four-layer dedup cascade: cheap exact match first, expensive semantic last2import hashlib, re34def normalize_email(e: str) -> str:5    e = e.strip().lower()6    local, _, domain = e.partition("@")7    if domain in ("gmail.com", "googlemail.com"):8        local = local.split("+")[0].replace(".", "")   # gmail ignores dots + tags9    return f"{local}@{domain}"1011def exact_key(tenant: str, email: str) -> str:12    return hashlib.sha256(f"{tenant}|{normalize_email(email)}".encode()).hexdigest()1314def normalize_company(name: str) -> str:15    n = name.lower().strip()16    n = re.sub(r"\b(inc|incorporated|llc|ltd|corp|co)\.?\b", "", n)17    return re.sub(r"[^a-z0-9]", "", n)                  # "ACME, Inc." == "acme inc" -> "acme"1819# Layer 1-2 catch ~all obvious dupes deterministically and for free.20# Layer 3 (fuzzy on normalize_company) + Layer 4 (embed + cosine > 0.92, threshold21# tuned on a labeled set) handle typos and free-text noise. NEVER run k-means22# without a distance cutoff -- it will merge unrelated accounts silently.

Salesforce solves layers 1–2 at the platform: a matching rule “defines how duplicate records are identified in duplicate rules and duplicate jobs,” with standard rules for accounts, contacts, and leads. You configure matching rules per object and run duplicate jobs nightly. For cross-object dedup (the Lead-vs-Contact boundary), tools like Insycle handle it. The mistake is feeding the waterfall un-normalized input: “Acme Inc.” and “ACME, Inc.” then consume two enrichment credits on the same company — dedup before enrich, always.

A subtle scaling failure most teams hit: dedup that runs fine on 10k records quietly becomes O(n²) on 1M. A naive “compare every record to every other record” is 10^12 comparisons at a million rows — hours of compute and a cost spike. The production fix is blocking: first bucket records by a cheap key (normalized domain, or the first few characters of the company name), then run the expensive fuzzy/semantic comparison only within each bucket. This is the same recall/precision/cost triangle as ANN search in retrieval — you trade a tiny chance of missing a cross-bucket duplicate for a massive compute saving. Interviewers who’ve scaled a CRM will probe whether you know dedup isn’t free at volume.

Case study: Notion treats dedup as a shared data product

Notion deliberately separates three teams — RevOps for governance, a GTM AI team for pilots, a GTM innovation pod for experiments — and the mechanism that makes it work is that data hygiene never lands in one team’s lap. Each team treats the dedup logic as a shared service with SLAs, exposed as a reusable recipe rather than a one-off table transform, so the next motion inherits it for free. The implication for how you build: don’t bury dedup inside one workflow’s columns — make it a named, versioned step that every pipeline calls. A dedup rule that only one campaign benefits from is technical debt the moment a second campaign ships.

Lifecycle & normalization: where automations actually break

Normalization and lifecycle are where most automation silently fails. A record enters with lifecycle stage unknown; the waterfall decides in two passes whether it has a matching email, phone, title, and company-size; the cleanup step demotes unmatchable leads and re-routes survivors into MQL workflows. ZoomInfo defines waterfall enrichment as querying “multiple data providers to fill gaps in B2B contact and company records” — but if you feed it raw, un-normalized input, you get duplicate credits and mismatched joins. The field-mapping blueprint a strong schema answer reaches for: verified emails + job titles + signal context onto Contacts; domain + funding + tech stack onto Companies/Accounts; and provenance (lead origin, enrichment status, match scores, confidence) onto custom properties/objects.

Interview angle. “How would you connect Clay, Salesforce, and HubSpot to ensure a single source of truth for lead data?” is a verbatim Sloane prompt and the canonical schema exercise. Before answering, draw the join graph on the whiteboard: Company/Account → Person/Contact → Opportunity, and say explicitly where Clay sits (upstream enrichment, downstream routing). Then name conditional writes (don’t overwrite clean records), dedup-before-write, and provenance fields. Saying “I’d just turn on the native sync” without the join graph or provenance is the weak answer.

One more lifecycle subtlety that bites in production: a two-way sync between two CRMs that each compute lifecycle stage independently will fight — system A advances a record to SQL, the sync pushes it to system B, B’s own workflow recomputes it back to MQL, the sync pushes that to A, and the record flaps between stages forever, firing a sequence on every flip. The fix is to designate one system as the lifecycle authority and make the other read-only for that field. This is the same one-way-writes principle as enrichment write-back: exactly one writer per field, or you get write loops. The candidate who has debugged a stage-flapping loop will mention it unprompted.

HubSpot starts with people. Salesforce starts with companies. — RevBlack. Every “single source of truth” prompt is really asking which side hosts the join — and a strong answer names data-provenance fields (source, confidence, enrichment status), not just raw values.

Interview prep

The CRM-modeling round tests whether you can draw a correct join graph, choose the right CRM for the constraints, and design dedup that holds at scale. Interviewers (per RevOps Coop and Sloane) want to hear provenance, conditional writes, and a layered dedup cascade — not “the native sync handles it.” Lead with the model philosophy (person-centric vs company-centric), then the mechanism.

01“HubSpot vs Salesforce data model — when do you pick each?” → velocity-vs-leverage on deal size, RevOps headcount, customization need; HubSpot person-centric + shared DB, Salesforce Account-centric + Apex.
02“Connect Clay + Salesforce + HubSpot for one source of truth — how?” → draw Company/Account → Contact → Opp, place Clay upstream; one-way writes, dedup-before-write, provenance fields, conditional overwrites.
03“Design dedup that survives scale.” → four layers: normalize → SHA-256 exact hash → fuzzy (Jaro-Winkler on name/domain) → semantic (embed + cosine threshold); never k-means without a cutoff.
04“Where do you store enrichment output so it doesn’t corrupt the CRM?” → custom properties/objects for source, confidence, match score, enrichment status — provenance over raw value.
05“Salesforce Lead vs Contact — why does it matter for dedup?” → Leads convert into Contact+Account; dedup must span the conversion boundary or you double-count post-conversion.
06“Why dedup before enrichment, not after?” → un-normalized dupes (Acme Inc. vs ACME, Inc.) burn two credits and create mismatched joins; merging after an SDR pass loses assignment history.
07“How do you keep hygiene from rotting over time?” → matching rules + nightly duplicate jobs; treat dedup as a recurring cron and a shared, versioned recipe (Notion’s pattern), not a migration task.
08“When is semantic dedup worth the cost?” → only for noisy free-text upstreams (event badges, scraped names); for clean inbound, normalize + hash + fuzzy is enough.

To go deeper, expect: “how would you push this to HubSpot and Salesforce without breaking dedupe?” (idempotent upsert on a deterministic external ID — email + tenant UUID — covered in L3); “a lead with fit-score 80 and engagement 5 outranks fit 30 / engagement 60 — is additive scoring right?” (Octave’s flagged footgun — pure addition mis-ranks; you gate fit before summing engagement); and “model an account hierarchy for a cross-sell motion” (Account-as-join in Salesforce, parent/child Companies in HubSpot). Name the data-provenance field in every answer.

docsUnderstand Account and Contact RelationshipsSalesforce Trailhead docsUse the data model builderHubSpot Knowledge Base articleThe GTM Engineer’s Guide to DeduplicationOctave HQ docsSalesforce Matching Rules (duplicate rules & jobs)Salesforce Help

Checkpoint

You’re asked to connect Clay, Salesforce, and HubSpot into “one source of truth.” What should your answer establish first?

AEnable native bi-directional sync between all three so data is always consistent everywhereBDraw the join graph (Company/Account → Contact → Opp), place Clay upstream, and specify one-way writes with dedup-before-write and provenance fieldsCPick whichever CRM has more integrations and route everything through it

Checkpoint

A 50k-record list scraped from event badges has wildly inconsistent free-text company names. Your normalize+hash+fuzzy cascade still leaves obvious duplicates. Best next layer?

ALower the Jaro-Winkler fuzzy threshold until everything matchesBGive up on dedup for this list and let the CRM matching rules handle it post-importCAdd semantic dedup — embed the records (1536-d), cluster, and merge above a tuned cosine threshold

Checkpoint

Your Clay table is burning enrichment credits faster than expected, and you notice “Acme Inc.” and “ACME, Inc.” both got enriched. Root cause and fix?

ANormalize and dedup company names before the enrichment columns run, so one company consumes one creditBSwitch to a cheaper enrichment provider to lower the per-credit costCIncrease the credit budget so the table stops stalling

Checkpoint

A teammate proposes storing enrichment source and confidence as free-text in the contact’s Notes field. Why push back?

ANotes fields have a character limit that enrichment data will exceedBProvenance (source, confidence, match score, enrichment status) belongs in typed custom properties/objects so workflows and conditional writes can read itCNotes are visible to the whole team and that’s a privacy issue

Checkpoint

You built a great dedup rule for the Q3 outbound campaign by configuring columns inside that one Clay table. What’s the senior critique?

AThe rule should live in the CRM instead of ClayBDedup buried in one table’s columns is debt — expose it as a named, versioned shared recipe every pipeline inherits (Notion’s pattern)CIt’s fine as long as the campaign hits its numbers

Could you draw the join graph for a Clay→CRM source of truth, design a four-layer dedup cascade, and defend provenance fields in an interview?

New to itGetting thereConfident

Takeaways

Salesforce is Account-centric (objects + Apex); HubSpot is Contact-centric (properties + shared DB) — decide which side hosts the join.
Pick the CRM on change-management budget (deal size, RevOps headcount, customization), not feature lists.
Dedup in four layers: normalize → SHA-256 exact → fuzzy (Jaro-Winkler) → semantic (embed + tuned cosine cutoff); never k-means without a threshold.
Store provenance (source, confidence, match score, status) in typed custom properties — provenance over raw value.
Dedup BEFORE enrich (or burn duplicate credits) and BEFORE routing (or lose assignment history).
Treat hygiene as a shared, versioned recipe with SLAs (Notion) plus matching rules + nightly duplicate jobs — not a one-off migration fix.

Next: APIs, webhooks & auth — OAuth refresh loops, HMAC-signed webhooks, idempotency keys, and the rate limits that throttle every CRM write.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with Enzo Sign up free