Enrichment eligibility and moment-of-use enrichment

A nightly job that enriches every record in the database will happily spend credits refreshing disqualified leads, closed-lost contacts, and records nobody is going to call this quarter or ever. Enrichment spend scales with database size instead of with actual sales activity, which is exactly backwards: the records worth paying to keep fresh are the small, changing set someone is about to act on, not the entire population sitting quietly in the CRM.

Two decisions fix this: who is eligible for enrichment at all, and when an eligible record should actually be enriched.

Enrichment is not the same problem as accuracy

Before eligibility rules: enrichment fills gaps and refreshes stale fields. It doesn't validate what's already there, resolve which of two conflicting values is correct, or prove a record is otherwise trustworthy. A record can be fully enriched and still be a duplicate, still have the wrong lifecycle stage, still be reachable on a channel it shouldn't be. Treating "we enrich our data" as a data-quality strategy on its own conflates enrichment with the much larger set of problems this guide's other pages cover.

Eligibility needs an explicit answer for every segment, not a default

A blanket "enrich everything unless excluded" policy quietly enriches every new segment that shows up later and nobody thought to exclude. Require every segment to carry an explicit eligible: true or eligible: false, with a stated reason for exclusions:

Segment	Eligible	Reason
Active pipeline, open Opportunity	Yes	Directly supports an active sales motion
Recently handed off from Marketing	Yes	Fresh data matters most at the moment of first sales engagement
Disqualified or closed-lost	No	No planned future contact; enrichment spend produces no return
Long-dormant, no engagement in the defined window	No, until re-engagement	Refreshing a record nobody will act on is spend without purpose

An "eligible unless excluded" default inverts this: it enriches the dormant and disqualified segments by default and requires someone to notice and add an exclusion after the fact, by which point the spend already happened.

Moment-of-use beats a blanket schedule

A record's data is freshest exactly when someone is about to use it, not on whatever fixed interval a nightly job runs. Trigger enrichment at the moments that actually matter:

• On creation: a new record enters the pipeline and needs baseline enrichment before anyone works it.
• On handoff: a record moves from one team to another (Marketing to Sales, for example) and the receiving team needs current data at that exact moment.
• On a specific action: a rep opens a record to work it, or adds it to a sequence, and enrichment runs just ahead of that action.
• Scheduled sweep, scoped to eligible segments only: a periodic refresh, but run only against the population already marked eligible, not the whole database.

This is the difference between "key records are always fresh when they're used" and "the whole database gets refreshed on a schedule regardless of whether anyone needs it." The first scales with sales activity. The second scales with database size.

Write behavior needs its own rule, separate from eligibility

Being eligible for enrichment doesn't mean an enrichment provider's value should overwrite whatever's already on the record. Enrichment should be allowed to fill genuinely empty fields automatically. A field with an existing value, especially one entered by a person, needs a separate conflict-resolution decision before enrichment is allowed to touch it. See conflict resolution and overwrite policy for that rule; this page only covers whether enrichment should run at all, not what it's allowed to write once it does.

GTM Lab: two records, one enrichment job

GTM Lab, a fictional B2B software company, has a nightly job proposed to enrich its full Contact population. Two records make the eligibility case concrete.

Eligible: a Ferrow Industrial contact newly handed off to Sales. The record was just accepted by Sales after Marketing's handoff, has no enrichment history, and is about to be worked. Under the eligibility rule, this segment (recently handed off) is eligible, and the trigger is on-handoff. Enrichment runs at the moment Sales picks it up, so the fields Sales actually looks at are current the moment they matter.

Ineligible: a batch of disqualified leads from a prior campaign. These records were disqualified months ago with no planned future contact. Under the eligibility rule, this segment is explicitly eligible: false, with the stated reason "no planned future contact." The nightly job excludes them entirely; zero credits are spent refreshing data nobody will look at.

Applying eligibility and moment-of-use triggers instead of a blanket nightly refresh is the same design decision I made in a production system, where it cut predicted enrichment credit use by more than 80%, from more than 50,000 to under 10,000 credits a month, while keeping the records that mattered fresh at the moment they were used. That is one company's measured result against its own prior baseline, not a guaranteed outcome of following this pattern.

This is otherwise a worked example. GTM Lab's specific segments and trigger choices are operating decisions, not a universal eligibility model.

Salesforce and HubSpot: what changes, what doesn't

Neither platform's native enrichment tooling ships a segment-eligibility model or moment-of-use triggers out of the box; most native and third-party enrichment integrations default toward either manual, on-demand enrichment or a broad scheduled sync. Building eligibility rules and trigger points on top of whichever enrichment provider you use, whether through platform automation (Salesforce Flow, HubSpot workflows) or a purpose-built rule layer, is the design work this page describes; check your specific provider's current documentation for what trigger granularity it natively supports before assuming you need custom automation to get moment-of-use behavior.

Enrichment eligibility checklist

• Every population segment has an explicit eligible value, not an implicit default.
• Every ineligible segment has a stated reason.
• Enrichment triggers at meaningful moments (creation, handoff, specific action, or a sweep scoped to eligible segments only), not a blanket schedule against the whole population.
• Enrichment is treated as a spend-and-freshness control, not a data-accuracy guarantee.
• Write behavior for enrichment results is governed by a separate overwrite policy, not assumed from eligibility alone.

Where this connects

The spend side of this decision (caps, approval queues, kill switches) is covered in enrichment cost controls and approval queues. The write-conflict side is covered in conflict resolution and overwrite policy. Generated or AI-derived enrichment fields specifically carry additional risk covered in AI-generated CRM fields are not a source of truth.