Final Outcome Overview

Every contact entering the CRM now follows one deterministic path: enrichment, customer detection, ownership assignment by traffic source, then segmentation. The full ingestion phase resolves in under five minutes, and a single Master Workflow owns the contact from creation to routing. It replaced what used to be three or four workflows running in parallel.

The practical result is that every downstream campaign workflow can finally assume it's working with complete, classified data. Existing customers never accidentally enter marketing nurture paths, because customer detection happens before routing rather than as an afterthought. And because the workflow drops contacts into a static segment at every decision point, there's a clear audit trail for any contact's journey through the system.

Pain Point to Solve

A contact entering the CRM should be a simple event. In practice, it triggered a small explosion. One workflow tried to set the lifecycle stage, another tried to enrich, another handled segmentation, and another was tied to the specific form that captured the contact. None of these workflows knew about each other. They didn't share state, they had no defined order of operations, and they'd been added over time by different people solving different problems.

The consequences were predictable. Lifecycle stages got set before enrichment finished, so they were based on incomplete data. Contacts got assigned to owners before anyone knew whether they were customers or prospects. Marketing automation enrolled contacts that should have been excluded. And because the workflows were independent, there was no single place to debug when something went wrong.

The underlying problem wasn't enrichment quality or routing logic. It was that nothing owned the contact during the moment when its identity should have been established.

Approach

Before building anything, I mapped the entire intended flow in FigJam: every branch, every condition, every state transition. This forced me to resolve ambiguity before implementation and gave me an artifact I could walk colleagues through. Building the diagram first surfaced edge cases I'd otherwise have hit in production.

The design came down to a few decisions:

• One workflow owns ingestion. Everything else (campaign workflows, nurture sequences, sales notifications) became a downstream consumer that runs only after the Master Workflow finishes. This eliminated the race conditions that came from parallel workflows.
• Customer detection comes first. Before routing or ownership, the workflow checks whether the contact belongs to an existing customer. Putting this before routing means existing customers never accidentally get marketed to, instead of catching them with a downstream filter after the damage is done.
• Traffic source drives ownership. Different acquisition channels map to different sales motions, so owner assignment mirrors where the contact came from. This replaced ad-hoc assignment rules that had accumulated in form-specific workflows over time.
• Enrichment is a state, not a step. Rather than proceeding on a fixed timer and hoping enrichment finished, the workflow treats enrichment as a tracked state it can wait on. This is the load-bearing decision of the whole system.
• Segment at every step. Each decision point adds the contact to a static segment, mostly for observability. When something goes wrong, the segments are the audit trail.
• AI classification where rules get brittle. Some classification problems have too many edge cases to solve with hardcoded lists, so they're handled by lightweight AI with strict prompts. Everywhere else, deterministic logic.

Implementation

When a contact is created, the Master Workflow takes ownership immediately. It adds the contact to an initial segment, sets lead status to New and lifecycle stage to Lead, then sends a webhook to Clay carrying the contact's data. The workflow then holds on a short delay, which gives HubSpot time to resolve company associations and existing deal links before any branching logic runs.

Clay enriches asynchronously and writes back to the contact record, populating person and company fields along with two AI-driven classifications: personal versus business email (too many regional domain variations to enumerate by hand), and a mapping from Clay's open industry taxonomy onto HubSpot's fixed dropdown of roughly 150 options. A custom property, GTM Enrichment Status, records where the contact sits in the pipeline as pending, complete, or failed, so the state is visible directly on the record without digging into workflow history.

After the delay, the first branch checks whether the contact belongs to an existing customer. If it does, the contact bypasses the marketing path entirely: lifecycle stage is set to Customer, lead status to Closed, and marketing contact status is removed, since there's no reason to market to an existing customer. If the contact is not a customer, the workflow assigns contact and company owner based on traffic source, then hands the contact off to whichever campaign workflow matches what they actually did, such as downloading an ebook or submitting a contact form.

HubSpot and Clay are connected directly, with no middleware between them. Most contacts are fully enriched within five minutes, depending on how long Clay takes to return data.

HubSpot's Master Workflow

Tech Stack

HubSpot is the system of record and the orchestration layer. The Master Workflow, the lifecycle and lead-status logic, the segmentation, and the custom enrichment-state property all live there.

Clay handles enrichment: HubSpot sends a new contact's data to Clay, which returns enriched person and company fields plus the AI classifications, then writes back to the contact record. The two are wired together directly, without an intermediary automation tool.