From company domain to outbound sequence
A Clay workflow qualifies companies, finds a usable email, prepares relevant copy, and connects the record to CRM enrollment.
Each step has a clear job. Recovery paths handle rate limits, fresh CRM records, and provider outages.
- Find the companyDomain and qualification
- Find the contactEnrichment and validation
- Prepare the messageContext and copy
- Route and recordCRM, sequence, outcome
Eight stages turn a domain into a sendable record
These functional stages organize a documented 42-node Clay workflow. Open a stage to see its inputs, decisions, and next step.
Source and intakeStart with a domain. Add names and owner details when available.
Source-specific seeders and manual or API batches feed a persistent queue. They share the same entry contract: the company domain is required; owner and first-name fields are optional.
Domain resolution and a CRM relationship check screen records before dispatch. Existing customers, open opportunities, and duplicate domains are held out. If the CRM check fails, the record stays unqueued for a later source run.
The dispatcher picks eligible queue rows, stores each run ID, and starts one Clay routine per record.
Company qualificationApply suppression and business-fit rules before costly enrichment.
Company lookup and suppression come first. Revenue and growth data are normalized before the qualification rule runs.
Known values below the configured floor exit. A no-data result follows the workflow’s explicit pass-through policy, so missing data has a defined path.
Optional hiring contextUse fresh hiring activity when it is available.
A separate Clay-managed jobs routine checks hiring context at dispatch time. The main routine can use the result as a message hook.
Errors, timeout, or no fresh jobs produce a no-signal fallback. The record can continue without hiring context. An association replay reuses the resolved hiring result.
This lookup fails open: optional context never becomes a required input.
Contact contextUse the person data on hand without blocking ownerless records.
Known owner, name, and decision-maker fields add context. Records without a first name or owner can still use the domain and business-inbox paths.
Missing fields stay missing. The next stage seeks a deliverable address through a defined enrichment order.
Email enrichment waterfallTry the owner email, then FullEnrich, then the business inbox.
- Supplied owner email
- FullEnrich
- Business inbox
The waterfall moves to the next source when a path cannot supply a usable address. Off-company-domain candidates are rejected unless the address exactly matches the supplied business email.
A fallback changes the source. A retry repeats a failed request.
Verification and sendabilityValidate the candidate and stop when no acceptable email remains.
The workflow accepts valid addresses or filtered catch-all results. It blocks hard-junk and placeholder addresses while allowing role inboxes.
Validation uses exact status equality. That prevents an “invalid” result from passing a loose “contains valid” check.
If the waterfall runs out of acceptable addresses, the record exits before sequence enrollment.
Copy preparationTurn approved context into relevant copy.
The workflow merges fields, maps allowed CRM bands, labels the signal, and uses Gemini to prepare copy. Unknown bands are omitted.
Date and meeting values are computed outside the model. Raw source evidence stays outside the copy inputs.
CRM, enrollment, and feedbackResolve records, check eligibility, enroll, and record the outcome.
Company and contact lookups support create-or-update paths. ID re-lookups, a Clay Signal record, and CRM associations connect the records.
An enrollment-status precheck and eligibility check lead to sequence enrollment. An outcome stamp follows, with optional mobile enrichment and writeback at the tail.
The Clay Signal record carries enrollment status. The workflow’s completion state tracks the routine’s progress.
Match recovery to the failure
A rate-limited request, a run still in progress, and a failed routine need different responses. Each path has its own scope and retry budget.
Clay API returns HTTP 429Wait, then retry the request once
The HTTP wrapper waits for the integer Retry-After value, or 30 seconds when the header is absent. It repeats the same request once, for at most two HTTP calls in that wrapper invocation.
Each request has a 60-second timeout. An error on the second response is raised. This wrapper’s retry policy is specific to HTTP 429.
The routine is still runningPoll the same run ID
Polling observes a submitted routine. It does not submit another one. The core loop waits 20 seconds per iteration, up to 60 iterations, and reads the first result when the routine completes.
That is up to 20 minutes of scheduled waits, plus request and processing time. The loop budget is shared across active runs in the invocation. A fresh association replay uses the remaining budget.
The optional hiring routine has a separate limit: eight waits of 12 seconds. Exhaustion or an exception returns no-signal context.
If core polling expires, the local record becomes poll_timeout. The remote run is not canceled; its outcome can be reconciled before any manual replay.
A fresh CRM association failsReplay the full routine once
A failed run whose note contains Associate or results[0] can trigger one immediate whole-record replay per dispatcher invocation.
This handles the race between creating CRM objects and finding them through the search index. The new run can use the existing-record path. Its run ID replaces the first, while the first error is retained.
The dispatcher reuses the hiring result. The rest of the routine runs again, rather than resuming from a saved node. The one-replay guard lives in memory for that invocation.
A provider reports an outageRequeue for a later dispatch slot
A failed run with “service unavailable” or “temporarily unavailable” in its error text can return to the queue. Matching is case-insensitive.
The dispatcher increments a persisted retry counter, clears the outcome, records the reason, and releases the run from active polling. The ordinary schedule and queue priority pick it up again.
The budget is the initial attempt plus up to two later-slot replays. A further matching failure becomes terminal. The association replay uses a separate guard.
The retry decision matches error text. Enrollment status remains a separate record to check when reconciling a failed run.
A seed-time CRM check gets 429 or 5xxUse bounded backoff with jitter
The seed-time CRM helper allows six retries after the initial request, for seven calls at most. Each request has a 30-second timeout.
A numeric Retry-After value is capped at 30 seconds. Without one, waits grow through 1.5, 3, 6, 12, 24, and 30 seconds. Each wait adds a random 0 to 0.5 seconds of jitter.
Other HTTP errors raise immediately. This helper does not catch network exceptions. If the check cannot finish, the seeder leaves the row unqueued for a later source run.
This policy belongs to the seed-time CRM helper.
Retry budgets stay local to their layer
Request retries, routine replays, and polling have separate counters. This keeps the response to each failure explicit and makes the next operational action clear.
Give every record a clear next action
Queue state, routine outcome, and enrollment status answer different questions. Keeping them separate makes failures and successful handoffs easier to act on.
- Intentional exit
- Below-floor, suppressed, and no-email outcomes end the path by design. They do not enter the transient-error retry path.
- Temporary outage
- The record returns to the queue while its persisted replay budget remains. Its reason and retry count travel with it.
- Terminal failure
- Malformed inputs and exhausted provider replays remain failed. A failed run or polling timeout trips the job’s outcome gate and triggers the configured failure email.
- Completed routine
- The routine reached a recognized terminal shape. The Clay Signal record supplies the enrollment result, so completion and enrollment can be read independently.
- Polling timeout
- The local wait ended. Check the remote run and enrollment record before deciding whether to replay it.
How the queue supports the workflow
Domain deduplication runs during resolution and again at dispatch. A previously touched row wins; otherwise the earliest queued row wins. Queue IDs provide a stable writeback key.
An enable gate, dispatch window, persisted hourly guard, and batch budget control when records move. Source priority and age determine which eligible rows go first.
Successful writes, intentional exits, transient requeues, and failures retain distinct states. Operators can correct inputs, investigate failed runs, and reconcile uncertain enrollment before replaying work.
The design connects useful context to action, with a defined path for the failures that happen between them.
Extended review of a documented Clay workflow · 15 October 2026
Explore the marketing operations work