SQL Definition via HubSpot Segments Pattern

Overview

When building HubSpot automations around Sales Qualified Leads (SQLs), the instinct is often to embed qualification logic directly inside a workflow. A cleaner, more maintainable approach is to separate audience definition from automation actions using HubSpot's dynamic segments.

The core principle: segments define who, workflows define what.

This pattern emerged from work with ^[1], where a 13-criteria SQL definition was being wired into workflow logic — an approach that would have been brittle and hard to iterate on.

The Pattern

1. Define the Audience in a Dynamic Segment

Create a dynamic contact segment (formerly called "lists" in HubSpot) that encodes all SQL qualification criteria as filters. A dynamic segment:

• Automatically adds contacts when they meet all defined criteria
• Automatically removes contacts when they no longer qualify
• Provides a live, always-accurate view of who is SQL-ready

Each SQL criterion becomes a filter condition (e.g., "Are you already juicing?" = any "yes" value).

2. Trigger the Workflow from Segment Membership

Build a simple workflow with a single enrollment trigger: contact joins the segment. All downstream actions (notifications, task creation, deal creation, handoff emails) live in the workflow.

[Dynamic Segment: SQL Criteria] → [Workflow: SQL Actions]
         ↑ who                              ↑ what

Why This Separation Matters

Keeping logic in the segment means you can update qualification criteria in one place without touching workflow logic. Multiple workflows can also trigger off the same segment.

Validate Criteria Before Building

A common failure mode: building a segment with strict criteria against a database where those fields are sparsely populated — resulting in zero contacts qualifying.

Before building the segment, run a quick data audit:

1. For each SQL criterion, apply it as a filter in the HubSpot contacts view
2. Record how many contacts match
3. Compile results into a simple spreadsheet

Expected output often looks like:

If most criteria return zero matches, the full segment will return zero SQLs — making the automation pointless until data quality improves.

Citrus example: The "Are you already juicing?" field had zero matches across ~10,000 contacts. Implementing all 13 criteria as-is would have produced an empty SQL list.

Phased Rollout Strategy

When the full criteria set can't be met due to data gaps, propose a phased approach to the client:

1. Show the data. Present the per-criterion count spreadsheet so the client understands why the full criteria won't work yet.
2. Start with a viable subset. Identify 3–5 criteria that have meaningful data coverage and represent genuine sales readiness signals.
3. Build and run the simplified segment. Get the automation live and generating value.
4. Iterate. As data quality improves (e.g., sales reps logging call outcomes), add criteria back in.

This avoids the trap of waiting for a "perfect" implementation that never ships.

Criteria Design Considerations

Some SQL criteria are better suited for human conversation than automated data capture. Watch for:

• Overly specific data fields — e.g., exact countertop dimensions. The real qualifying question is simpler: "Do you have space for it?" Simplify the criterion to match what can realistically be captured.
• Fields populated only through sales calls — criteria like juicing method or space availability are typically gathered during MQL → SQL qualification calls, not web forms. The workflow should support logging these answers, not assume they pre-exist.

The segment/workflow pattern works best when criteria are designed around data that can actually be collected at scale.

Related

• ^[2]
• ^[3] (if created)
• ^[4] (if created)