How to Automatically Enrich New Leads: Triggers, Matching, and Routing

Automatically enrich new leads by connecting a trusted arrival event to a controlled workflow: trigger → match → enrich → qualify → route. Preserve the source event, resolve the person and company, fill only the fields needed for the next decision, and route with current ownership and eligibility checks. Records that cannot be resolved should enter a visible exception queue instead of being guessed into completeness.

Event-driven does not mean instantaneous. API ingestion, data lookup, scheduled automation, CRM synchronization, and email sending are separate stages. This guide proposes an engineering design for those boundaries and identifies the Unify capabilities documented for each. Queues, deduplication ledgers, concurrency controls, and acceptance tests described as recommendations are responsibilities to implement or verify, not implied guarantees of the platform.

Define what “ready to route” means

Start with the decision the enriched record must support. An account-owner notification may need a reliable company match and the original request. A prospecting sequence additionally needs an eligible person, usable contact details, and outreach permissions. A record can be ready for one action while remaining incomplete for another. Do not make a missing phone number block a requested email response when phone outreach is not required.

Create a field contract covering required inputs, permitted sources, allowed updates, and unresolved behavior. Separate company attributes from person attributes and event context. An employer match does not establish someone’s title; a verified email does not establish purchase intent. Preserve what the visitor actually submitted so enrichment can be reviewed against the original request.

These are proposed operating records. Some evidence may live in your integration service rather than native CRM fields. Confirm which metadata each provider exposes; if a source does not supply a verification date, keep it unknown. The distinction between created, updated, and verified dates matters when deciding whether an existing value can be reused.

Trigger: capture the event without promising immediate completion

Use a defined source such as a submitted form, authenticated product signup, or CRM creation event. A company identified from website activity is an account signal, not proof that a particular employee visited. Keep those inputs on different branches until person identity is established. A personal email address is unresolved company evidence, not automatic proof that the lead is unsuitable or that a work identity can be recovered.

For a custom receiver, authenticate the source using its supported mechanism, validate the payload, and persist an accepted event before acknowledging receipt. Record event occurrence separately from processing time. Use a durable queue so downstream delays do not require the source system to remain connected. Define retention and access for the stored payload, keeping only information your workflow needs.

Unify’s custom events API records named website or application actions. Its identify events API associates a visitor with a known person and company; consistent visitor IDs connect the event types. These analytics APIs are distinct from the Data API, which creates, queries, and modifies records. Successful ingestion alone does not establish that enrichment, qualification, or routing has finished.

Check the actual trigger timing. Unify’s Play triggers documentation says most automated triggers use recurring checks, with record-match and audience triggers evaluated about every 15 minutes. That is a documented evaluation cadence, not an end-to-end latency guarantee. If your required acknowledgment is faster, handle that acknowledgment separately and test the downstream architecture against the deadline; do not describe a scheduled audience trigger as an immediate webhook.

Match: resolve identity before creating another record

Keep event identity separate from entity identity. A source event ID identifies a submission or occurrence. A CRM ID, verified email, or explicitly unique external identifier identifies a record under defined rules. Repeated submissions from the same person can be legitimate new events without requiring new person records. Conversely, different people at the same domain must not collapse into one contact.

Unify’s Find unique record endpoint requires at least one unique attribute and returns a record or null when no record matches. Additional criteria narrow the match. Treat a null result as “no record matched this query,” not proof that the person is absent under every possible identifier. Extra stale criteria can prevent an otherwise expected match.

The Upsert record endpoint creates or updates according to unique matching values. Its request supports overwrite and fill-if-empty behaviors; the documentation defines empty as null. Choose those semantics deliberately. An empty-looking placeholder string is not necessarily null, and an upsert does not validate the underlying identity or guarantee that unrelated downstream actions happen once.

Preserve returned IDs for subsequent actions. When identity changes, reconcile the previous and current identifiers rather than blindly creating a second record. Hold conflicting matches for review, and distinguish a validation failure from a genuine no-match result. Do not interpret a timeout or permission error as permission to create a fresh contact.

Enrich: request useful fields and preserve uncertainty

Select enrichment fields according to the routing contract. Avoid buying phone data when the workflow only needs company ownership and email follow-up. Before requesting a value, check whether the existing value meets the required source, freshness, and quality rules. Those rules should be field-specific: a recent record update does not certify every attribute.

Unify’s company and contact data product documents multi-source email and phone enrichment. That describes available data capabilities, not guaranteed completeness for every new record. The account and contact maintenance motion emphasizes filling verifiable gaps and leaving unresolved values empty. Apply the same discipline to incoming leads instead of substituting invented values to satisfy a required field.

Store outcomes separately: found, no match, conflicting evidence, invalid input, temporarily unavailable, or not requested. A provider response can be technically successful while returning no usable value. A failed request is different from a completed search with no result. Preserving that distinction prevents both futile retries and premature rejection of leads.

A waterfall can consult another source when the previous source lacks an acceptable result. Define stopping conditions, permitted sources, and a spending limit in your design. Do not assume that importing a record through the Data API automatically runs an arbitrary enrichment waterfall. Confirm the supported enrichment action or configured workflow for your particular fields before connecting it to routing.

Qualify: evaluate fit without converting unknowns into facts

Separate identity confidence, company fit, person fit, and requested action. Each answers a different question. Keep qualification rules versioned and retain the reason for the decision. If company size is required but unavailable, the result is unresolved under that rule, not a silently assumed size or an unexplained negative score.

Use deterministic fields for explicit business rules, and use research when a question requires evidence beyond structured attributes. Unify’s Play actions reference documents research-agent qualification and conditional branches. Review what the agent actually established before making a consequential route depend on its answer. A generated answer does not make a missing supporting fact certain.

Qualification should preserve the context of inbound requests. An existing customer asking for help belongs with the relevant owner or support process, not automatically in a new-business sequence. An open opportunity may require the deal owner’s attention. The inbound qualification and routing motion is useful for designing these branches; its illustrative walkthrough is not evidence of your own results or a universal routing implementation.

Route and write back with explicit field ownership

Choose an authoritative source for each controlled field. CRM ownership, lifecycle state, and opt-out status should not be casually overwritten by an enrichment response. Assign a writer and an overwrite policy to each mapped attribute, and distinguish a blank-field fill from a correction to an existing value. Save enough history to explain the change and support an approved rollback.

Unify’s Salesforce field mappings and HubSpot field mappings configure read and write behavior separately. Mapping availability depends on supported types and the connected account’s access. Incoming mapping changes can cause background reprocessing; outgoing changes apply to subsequent syncs. Review the actual sync result rather than assuming a value visible in Unify has reached the CRM.

Make the route explicit: existing owner, qualified new-business queue, appropriate non-sales handler, or unresolved review. An ownership notification and sequence enrollment are different side effects. If routing changes during processing, reconsider the pending action using the current owner and restrictions before committing it.

The Create enrollment API documents enrollment into published template sequences, with eligibility controlled by the ruleset. Agentic sequences use a separate generated-draft flow. Save the returned enrollment ID; a successful enrollment is not proof of an immediate email send. Do not bypass a conflict by inventing approval for concurrent sequences.

Handle retries, duplicates, and changes during processing

Deduplicate the event and protect each side effect

In a custom integration, use a durable event ledger keyed by the source and source event ID. Record the payload version, processing state, and completed actions. If the source lacks a dependable event ID, define and test a deduplication key rather than assuming a timestamp alone is unique. Keep legitimate later submissions distinguishable from redelivery.

Use a separate business-action key for each intended downstream effect, such as a particular routing decision or enrollment request. A deduplicated intake does not prevent duplicates caused by retries later in the workflow. Where supported, use destination idempotency features; otherwise reconcile the destination state and saved action IDs before retrying an uncertain operation. A local ledger alone cannot guarantee exactly-once effects across a remote service.

Retry recoverable failures, investigate ambiguous outcomes

Separate transport failures and documented transient responses from invalid fields, missing permissions, and policy conflicts. Use bounded backoff, respect published rate limits, and honor a retry delay when the receiving service provides one. Move exhausted attempts to a monitored exception queue. Replaying the whole workflow after a late failure can repeat previously successful writes or outreach.

A timeout after sending a request is ambiguous: the destination may have completed the action. Check its observable state before repeating it. If the destination offers no dependable reconciliation or deduplication mechanism, hold the action for review rather than claim a safe automatic retry. Preserve the last error and attempted operation so recovery does not require reconstructing the event from memory.

Unify’s webhook action exposes a configurable retry policy, while Play rerun settings control whether the same record can enter the same automated play again after a cooldown. These are different controls. Neither description establishes transaction-wide deduplication across every connected service. Test your receiving endpoint and repeat-run behavior separately.

Recheck current state before enrollment or assignment

A lead can become a customer, gain an owner, opt out, or be merged while enrichment runs. Re-read authoritative eligibility and identity before the final action. In systems you control, use transactional checks or version-aware writes where supported. A read followed by a write can still race; do not assume a destination provides atomic conditional updates unless its interface documents them.

Unify’s sequence exclusions documentation explains that applicable exclusions are checked at enrollment and for active enrollments, but CRM changes must first reach Unify. Test that propagation boundary. When the required authoritative state is unavailable or demonstrably stale, hold automated outreach and keep the inbound request visible to its operational owner.

Monitor completion and unresolved work separately

Track stage transitions and reasons, not just successful API responses. Measure receipt, match, enrichment completion, qualification, route acknowledgment, and actual outreach as distinct events. A queued record, an excluded person, and a failed integration are different operational states and should not share a generic “done” label.

For a proposed routing-completion measure, define the population as unique accepted lead-arrival events in a stated intake window, deduplicated by source event identity. Freeze a reporting snapshot and rule version. The denominator is that population; the numerator is events with an acknowledged destination route by the snapshot. Report unresolved and pending events separately while retaining them in the denominator. With no accepted events, report not applicable rather than zero or perfect completion.

Measure elapsed time from receipt to acknowledged routing for completed events, and report pending-event age alongside it. State the completed-event count and the population excluded from the timing calculation. A fast completed subset can hide an old unresolved backlog. Set service objectives from the actual business requirement and observed architecture, not an unsupported universal speed-to-lead conversion claim.

Watch usage as well as failures. The credits and usage documentation notes that credit-dependent actions can stop when allocation is exhausted and may require recovery checks afterward. Review plan capabilities for API access, automated Plays, and CRM write access before committing to the design. A working trial does not establish the same behavior under a different package.

Validate the workflow before expanding it

Use a bounded test with records and controlled recipients your team is authorized to process. Save the configuration and rule version, expected behavior, observed result, and evidence location. The following is a blank acceptance worksheet, not a report of successful tests or a claimed native feature set.

Build custom orchestration when you need control the configured workflow cannot provide and have an owner for ongoing operation. Use supported platform actions when their behavior and timing satisfy the requirement. A hybrid can capture arrivals in your service while using Unify for records, research, routing actions, or sequencing. Approve that boundary only after exceptions and recovery work as clearly as the successful path.

Frequently asked questions

How do I automatically enrich new leads as they arrive?

Capture a trusted arrival event, match it to the correct person and company, request the fields needed for the next decision, qualify with explicit rules, and route using current ownership and eligibility. Preserve unresolved records with reasons and an owner for review.

Does automatic enrichment mean the lead is processed instantly?

No. Ingestion, enrichment, automation evaluation, CRM sync, and sending can have separate delays. Unify documents recurring checks for most automated Play triggers, including approximately 15-minute checks for record-match and audience triggers. Measure the complete path against your requirement.

Does writing a record through the Unify Data API automatically enrich it?

The Data API documents record creation and updates; that alone does not establish that an arbitrary enrichment workflow runs. Configure and verify the supported enrichment path, required inputs, plan access, and downstream action before relying on automatic processing.

How should I handle failed enrichment requests and duplicate events?

Keep durable event and action records, distinguish unresolved data from technical failures, and use bounded retries for recoverable errors. Reconcile ambiguous destination outcomes before retrying writes or enrollments. Play rerun settings and webhook retries are not a universal exactly-once guarantee.

Should a lead wait until every field is filled before routing?

No. Define the fields required for each action. A valid inbound request can be directed to its existing owner while optional enrichment remains unresolved. Hold actions that depend on missing identity, eligibility, or contact evidence, and make that hold visible.