Clay Custom Signals: Advanced Use Cases and Implementation

A useful account signal gives your team a reason to investigate a specific company, with evidence and an accountable next step. A monitoring table becomes expensive noise when the same observation creates another alert, a failed fetch becomes a negative answer, or an AI summary becomes a CRM fact.

This guide designs an advanced Clay Custom Signals workflow for B2B teams. It covers recurring observations, change detection, evidence review, duplicate-alert prevention and four implementation examples. Examples in this guide use fictional accounts, and the schemas, formulas and acceptance cases are a reference design that has not been run in a Clay workspace.

Clay Signals watch a list of companies or people on a schedule and add a new row when something changes, such as a job change, company news or a condition you define with Custom Signals. Each change can then start research, scoring or a CRM handoff for the account owner.

Which Clay signals should you track?

Begin with a business question. For an integration service, a relevant question might be: has an existing target account announced a product integration that creates an implementation or data-operations question? The useful output is a short, reviewable account brief. It is not automatic proof that the company needs your service.

Write a signal definition before configuring columns. Specify the target population, source, qualifying observation, evidence that would invalidate it, freshness rule, review owner and permitted action. If the next step would be identical without the observation, the monitoring probably adds little value.

On smaller screens, scroll to compare all columns.

Choose one signal for the pilot. A narrow design makes false positives explainable. A combined score can come later, once individual observations are reliable. Our account-targeting and signal-scoring guide covers the separate decision of how to prioritize fit and timing.

How do Clay Custom Signals work?

Clay documents Custom Signals as scheduled monitoring of selected sources. You choose a source, configuration and frequency; some sources need your own connected account. Clay also documents turning an enrichment into a signal through source, run-history, lookup and signal tables. Clay Custom Signals documentation.

Use the direct mechanism when its output answers your question. Use retained observations when you need to explain what changed between runs. The second approach is useful for distinguishing a newly published integration from a page that has described the integration for months.

Separate three questions: can the source observe the fact, can your comparison identify a change, and does the change justify action? A provider that reliably returns a technology name might still be unsuitable for detecting its deployment date. An AI comparison might identify a wording change without establishing a new business event.

Custom signal triggers are configured in the Clay web app. Their events can be accessed through Audiences; the developer documentation distinguishes this from the signal types supported for CLI configuration. Do not assume every signal can be created through a command-line workflow. Clay developer Signals documentation.

The reference flow keeps account identity, individual observations, comparisons and accepted events separate. An observation moves toward an action only after evidence, novelty and routing checks.

Define the account, observation and event contract

Keep an account identity stable even when its name changes. In this reference, account_id is your internal identifier, while normalized_domain helps lookups. A domain is only a matching aid: subsidiaries, acquired businesses and multiple products can share or change domains. Ambiguous identity belongs in review.

The contract below separates source facts from workflow state. Each observation is immutable after capture; a correction creates a later observation. That preserves the evidence behind a previous decision.

On smaller screens, scroll to compare all columns.

Do not collapse all dates into one timestamp. source_event_at is the event date explicitly stated by the source, or null. observed_at is when the workflow captured the evidence. detected_at is when comparison proposed a qualifying change. confirmed_at is when a reviewer or approved deterministic rule accepted it. A detection today does not mean the business event happened today.

Also retain source_published_at when available, because publication can follow an event. A careers page without a publication date cannot substantiate “posted this week.” A trust-center update time does not necessarily establish when a certification was awarded.

Define an event key from the account, signal type and normalized business fact. For a new executive, the fact might combine the identified person, role and supported start date. For an integration announcement, it might identify the integration and announced release. Do not hash the entire page: navigation changes and punctuation would make unrelated edits look like new events.

How do you set up a Clay Custom Signals workflow?

The documented enrichment-to-signal recipe schedules an enrichment, sends each result to history with an account identifier, retains separate rows by disabling Update existing rows on re-run, retrieves history through Lookup Multiple Rows in Other Table, compares recent outputs and sends qualifying differences to a signal table. Created At supports chronology. Clay’s four-table recipe.

Table 1: accounts and observation work

Start from a reviewed account population. Add a source-specific observation column, a fetch-state column and the signal-policy version. In this reference, a successful result must include enough evidence to identify the fact; an empty result is not automatically a negative finding. Keep source retrieval separate from the final eligibility decision.

Before research, look up account suppression and existing relationship status. Existing customers may need an account-management action. If the relationship data is stale, stop the action and refresh it. Spending more on web research cannot resolve uncertain CRM ownership.

Table 2: append-only observation history

Store a row for each attempted observation, including unsuccessful access. Preserve the source URL, result state and reason. A blocked page and a successful page with no matching fact must remain different states. Retain the observation ID so reviewers can reproduce which input supported a later event.

Use an explicit retention policy for captured pages. Keep only the evidence necessary for the business decision, respect source access rules, and decide who can view personal information. The reference contract is a data-minimization design choice; it does not establish your legal basis.

Table 3: comparison and review candidates

Clay lookups retrieve matching data without changing the source table. Normalize both sides of the key and prefer exact matching where identity requires it. Multiple-row results include a match count; the interface displays a sample of up to ten matched rows. That sample is not a guarantee that all history is visible. Clay Lookup Rows documentation.

For this design, select the current observation and the latest comparable successful baseline explicitly. Do not rely on whichever row happens to appear first. “Comparable” means the same account, signal definition, source scope and material rule version. A prompt change that alters extraction may require a new baseline, because the changed output comes from your workflow.

Table 4: qualified events

Send accepted candidates to a separate event table. Clay’s Send table data documentation distinguishes pushing rows into another table from pulling reference data with lookups. Preserve evidence IDs and rejection reasons even when the destination action is skipped.

Add a downstream processing log that records each action if repeated actions would matter. A table lookup is useful for screening, but this reference does not assume that checking for an event and creating an action are an atomic operation. Concurrent runs can both pass a check. An external service must enforce a unique action key if your delivery requirement includes durable duplicate protection.

Handle first observations, contradictions and repeated evidence

A boolean “changed” column is insufficient. The following decision states explain when the system can proceed and when it needs another observation or a person. They are proposed operational rules that you configure yourself.

On smaller screens, scroll to compare all columns.

An explicit bootstrap policy can permit review of a useful fact found on the first run. Label it “discovered during initial research,” preserve its stated event date, and keep it separate from later change detection. This allows useful research without misrepresenting the system’s historical knowledge.

Compare business facts before asking AI to interpret them

A robust detector first normalizes the facts it already understands. For an integration directory, represent a capability as a set of named integration and scope pairs. Sort that set and compare it with the comparable baseline. A page that reorders the same pairs has no new capability. A new pair becomes a candidate, while a missing pair requires a separate removal policy.

Removal is harder than addition. A page might be truncated, paginated or temporarily inaccessible. Require a complete observation of the same scope before proposing that a capability disappeared. If the retrieval process cannot establish that completeness, retain the previous fact and mark the current state unresolved. Do not convert an extraction limitation into a business announcement.

# Illustrative logic outside Clay; adapt to your actual field contract.
if current.fetch_state != "complete":
    decision = "unresolved"
elif baseline is None or current.policy_version != baseline.policy_version:
    decision = "baseline"
elif evidence_conflicts(current, baseline):
    decision = "contradictory"
else:
    new_facts = normalized_facts(current) - normalized_facts(baseline)
    candidates = [fact for fact in new_facts if qualifies(fact)]
    decision = "candidate" if candidates else "unchanged"

# Identity and receipt checks still precede any external action.
# A missing fact is not handled as removal by this addition-only detector.

Use an AI comparison when the evidence is narrative, such as different descriptions of a role’s responsibilities. Give it the two observations and ask for a proposed factual difference. It should not research a new source, select an account owner or dispatch an action inside the comparison step. Those are different responsibilities with different acceptance rules.

Compare only the supplied baseline and current observations.
Return: decision, normalized_fact, baseline_evidence,
current_evidence, source_urls, reason, unresolved_questions.
Allowed decisions: unchanged, candidate, contradictory, unresolved.
Treat rewording, navigation changes and duplicate listings as unchanged.
Never infer budget, purchase intent or an unstated event date.
If either observation is incomplete, explain the uncertainty.
Quote supporting text from the inputs. Do not invent a source.
This output proposes a review decision; it does not approve an action.

Version the normalization and prompt together. A useful review asks whether the same source evidence produces the same material fact and the same decision. If that relationship changes, inspect the policy revision before concluding that the account changed. This makes debugging possible without depending on an AI explanation after the fact.

For numerical or structured facts, compare normalized values deterministically. For narrative evidence, ask AI to return a proposed fact and its supporting excerpt, then validate the shape and source. Keep the extracted evidence separate from an inference such as “probably buying.” The latter may help a reviewer frame a question; it should not become a verified CRM property.

Clay’s conditional runs execute an action only when its condition evaluates true. Configure a run condition in the action’s run settings, reference the relevant columns, and review generated sample outputs before relying on it. Clay Conditional runs documentation. A condition that admits missing evidence is a policy bug even if its formula runs successfully.

Baseline, unresolved, unchanged and reviewable change states stay separate. Only a candidate that also passes account eligibility, event-identity and action checks can proceed.

Four advanced implementation use cases

These examples specify what to observe and what decision it could support. Select sources that your team is permitted to access and can verify within its review capacity.

1. A new executive joins an account with a relevant operational project

The business question is whether a new leader has responsibility for a problem your service can address. Observe a supported role change, then research company context independently. A new chief revenue officer plus a public plan to consolidate commercial systems may justify a brief about data ownership and handoffs. A title change alone does not establish that project.

Keep the role event and project evidence as separate observations. Require identity, employer and role to agree. Record a start date only when a source states it. Reject a biography for a former executive, an announcement concerning a subsidiary outside scope, or a result whose employer cannot be resolved.

The output should contain two verified facts and one cautious question: the supported appointment, the separately supported operational context, and a question about the leader’s priorities. Use the new-executive-hire use case for the wider outreach path. This monitoring design owns the history and evidence boundary.

2. A company announces a relevant technology integration

Monitor a specific integration directory, release note or product-documentation page. The decision is whether the new capability raises a relevant implementation question, such as synchronizing customer identifiers across systems. An official integration announcement supports the announcement. It does not prove the company uses the software internally.

Normalize the fact as the named integration and its documented scope. Separate a newly listed connector from a renamed existing connector. Review whether “coming soon” became “available,” because that transition may matter more than the connector’s first mention. Keep availability, deployment and intent as different fields.

The proposed action is a technical brief for the account owner. Include the source, stated release scope, integration question and exclusions. Do not populate a “technology installed” property from a marketing integration page. If installed-base evidence is required, choose and validate a source that actually supports that claim.

3. Hiring patterns suggest a defined systems responsibility

For a team offering revenue-systems implementation, a combination of role requirements may be more useful than any single job opening. Define the relevant pattern before research, for example explicit CRM administration and integration ownership across two distinct, active postings. The pattern is a hypothesis to evaluate before treating it as a buying indicator.

Deduplicate mirrored listings by requisition or normalized role and location. A syndicated copy of the same vacancy should not increase the count. Preserve required skills and reporting scope as evidence; do not infer an approved external budget from hiring activity. An expired listing remains historical context only.

The review brief should explain what the job descriptions actually ask someone to own, where that responsibility spans tools, and what remains unknown. A useful next step may be a question about implementation support. If the company is deliberately building an internal team, the correct decision may be to keep monitoring it.

4. Trust-center changes affect an account conversation

A changed trust center can identify an assurance or infrastructure question relevant to an existing sales process. Monitor a named page and the specific statement your team needs, such as a newly published audit period, subprocessors list or availability of a report to authorized reviewers.

Store the statement as a claim made by the company. A badge does not independently validate certification, report scope or your customer’s requirements. Do not translate “SOC 2 report available” into “all products comply with every buyer policy.” A procurement owner may need to inspect the actual report through its permitted access process.

Route the event to an existing opportunity or account owner when appropriate. The brief should distinguish the changed statement, its source, its scope and the document still required for evaluation. An AI researcher should not bypass a gated report or invent a control assessment from a public page.

The four patterns use the same evidence and event contract but answer different questions: leadership responsibility, integration capability, hiring scope and assurance information. Their review requirements differ, so one universal “high intent” label would lose useful context.

Follow a synthetic account from baseline to correction

Consider the fictional account acct_demo_042 at example.com. Run A observes a product page with an existing CRM connector. Run B observes a release announcement adding a new synchronization capability. The reference detector compares normalized facts and ignores page length or rewritten headlines.

{
  "account_id": "acct_demo_042",
  "signal_type": "integration_capability_change",
  "baseline_observation_id": "obs_demo_a",
  "current_observation_id": "obs_demo_b",
  "source_url": "https://example.com/releases/demo",
  "source_event_at": null,
  "evidence": "Fictional fixture: new synchronization capability announced.",
  "detected_at": "2026-10-04T08:00:00Z",
  "confirmed_at": null,
  "event_key": "acct_demo_042:integration_capability_change:capability_demo_v1",
  "decision": "candidate",
  "action_state": "not_dispatched"
}

The null event date means this test case does not establish when the capability launched. The candidate is not confirmed. Before acceptance, the reviewer checks that both observations belong to the same account, the source supports the capability, and the release is relevant to the approved account play.

Run C repeats the same capability in a rewritten page. Its wording differs, but its event key is unchanged. Attach the new observation to the existing event; do not create another task. If Run D says the capability was withdrawn, treat that as a distinct reviewed correction with its own evidence and relationship to the original event.

This lifecycle prevents two common errors: repeated messaging about the same announcement, and stale briefs that continue to present a withdrawn capability as current. It also preserves enough history to explain what the workflow knew at each decision.

How often should a signal run, and what does it cost?

For its documented history recipe, Clay describes scheduled runs recurring every 24 hours from initial scheduling, with no selectable exact time and a short delay between dependent schedules. Custom Signals schedule note. Treat that recipe as periodic observation; it does not guarantee real-time delivery.

Choose cadence from the action’s useful lifetime and the source’s freshness. A short-lived event with slow source updates may need another monitoring approach. Faster reruns of cached or inaccessible content can increase spend without producing earlier information. Observe the elapsed time from source publication to capture during the pilot to learn the actual detection latency.

Modern Clay usage separates Actions, which meter orchestration, from Data Credits spent on data or AI. Enrichment and AI work consume Actions; bringing your own provider key can avoid Clay Data Credit charges for that provider while leaving Actions and the provider’s own bill. Formulas, Send Table Data and both single-row and multiple-row lookups between Clay tables are listed as operations that do not consume Actions. Confirm the configured operations and account terms when budgeting. Clay Actions and Data Credits.

Use the following model with measured pilot inputs. It deliberately avoids assuming a universal price per account or a conversion rate.

observations = eligible_accounts * scheduled_observations_per_period
candidate_reviews = observations * measured_candidate_share
operating_cost = Clay_plan_cost + incremental_Clay_usage_cost
               + external_provider_spend + review_hours * internal_hourly_cost
cost_per_accepted_event = operating_cost / accepted_events
cost_per_reviewed_action = operating_cost / completed_reviewed_actions

Incremental Clay usage means charges beyond the included plan allowance. Keep Actions, Data Credits and external invoices separate, and do not charge an included allowance twice. The Clay implementation budgeting guide covers the wider build, software and operating commitment.

If accepted events or completed reviewed actions are zero, report the cost and that zero count separately. Do not divide by zero. Also record unchanged observations, unresolved access attempts, false candidates and useful actions. A cheap event stream still fails as an acquisition system when nobody reviews it.

A workload example: daily monitoring can move the bottleneck to review

The following workload inputs are hypothetical and do not predict Clay performance or conversion rates. Assume 400 eligible accounts, one observation per account per run, a 5% candidate rate, six minutes of review per candidate and 50% acceptance after review. Four runs in a four-week planning period produce 1 600 observations, 80 candidates, eight review hours and 40 accepted events.

If the same assumptions held across 28 daily runs, the workload would become 11 200 observations, 560 candidates, 56 review hours and 280 accepted events. That arithmetic exposes capacity risk; it does not predict seven times more useful events. Real observations repeat, changes are uneven and candidate quality can decline as sources grow. Measure new event identities to see how much incremental opportunity the candidates represent.

A team with eight review hours should therefore investigate its source freshness and event lifetime before increasing cadence. It might keep slower-moving integration changes weekly where the selected source supports that cadence, reserve faster observation for a smaller priority account cohort, and suppress already reviewed event identities before assigning new work. Repeating the same research more often is only justified when earlier information changes a real decision.

Separate the research budget from the action budget. A narrow pilot can cap reviewed accounts, observations, provider spend and unresolved retries, while an owner decides how many briefs the team can act on. Track an accepted-event-to-reviewed-action ratio alongside spend. If that ratio is low, improving dispatch and ownership may contribute more than buying another source.

Clay’s usage tools provide table-level views by time, column and run, with downloadable data. Use these to reconcile actual spending with the worksheet. Clay Credit usage documentation. Attribute costs to the specific source and policy version so you can explain whether retrieval, comparison or review dominates.

How should a Clay signal reach HubSpot?

For a native HubSpot destination, configure confirmed object IDs and approved properties with the Clay HubSpot integration setup guide. The monitoring workflow below still owns whether the event is new, relevant and ready for an action.

Maintain separate event and action identities. An event can support a technical brief, an account-management note or an opportunity review. Changing the destination action should not pretend a new company event occurred. Conversely, two distinct events may support a single combined account brief.

The action ledger should record event key, action type, destination object, owner, requested time, receipt state and any returned destination identifier. “Requested” means dispatch was attempted. “Accepted” means the destination acknowledged intake. “Completed” requires evidence of the intended business operation, such as the created task identifier and correct owner.

Do not retry an uncertain write blindly. Check the destination receipt or unique action key first. The implementation may require middleware or another durable store; this article does not claim Clay lookups alone guarantee exactly-once delivery. Our Clay API integration reference explains the adjacent orchestration decision.

Keep personalization downstream of confirmed evidence. The Claygent research guide covers source-backed briefs and message review. A research result should help the owner ask a relevant question, without turning an inferred budget, initiative or personal motive into a statement of fact.

Test the decision boundary before rollout

Build these acceptance test cases in a controlled workspace before connecting live actions. Judge the observable final outcome, including whether an action was suppressed and why.

On smaller screens, scroll to compare all columns.

Clay’s sandbox copies sample rows and disables automatic outbound actions, but recurring sources and scheduled runs continue. Individual outbound cells can still be run manually. Clay Sandbox mode documentation. Sandbox entry is therefore not a substitute for explicitly controlling live dispatch.

Map triggers and outputs before rollout. Clay documents loops caused by webhook re-entry, circular references and bidirectional sync, and recommends status conditions, separate trigger fields and one-way data flows. Clay Infinite loops documentation. In this reference, a downstream acknowledgment updates only the ledger, so it cannot restart the same research through the observation input.

Expand only after reviewers can explain the accepted and rejected pilot cases. Keep the old policy version and evidence when making a change. To stop a faulty release, pause new action dispatch first, preserve pending records, reconcile uncertain destination writes, then correct the retrieval or comparison rule. Deleting history would remove the information needed to understand the problem.

When is signal monitoring the wrong investment?

Custom monitoring needs a source that can observe the fact, a buyer hypothesis your team can challenge, and review capacity. It is a poor fit when your account list is still undefined, source access is inconsistent, ownership is unresolved, or there is no useful action after detection. Address those foundations before adding more signals.

After launch, review whether accepted events actually help account owners make better decisions. Track relevant briefs reviewed, actions completed, false-positive reasons and qualified conversations separately. Do not attribute every later opportunity to monitoring or convert an accepted signal into a revenue claim.

If your team needs help designing this boundary, AGI Technologies’ account-based and signal-triggered campaign service can scope the account policy, evidence contract, Clay workflow, CRM ownership and release tests. Bring a small reviewed account sample, the signal you want to detect and the action it should support.

Book a 30-minute call or send an inquiry to discuss the signal you want to monitor.

Sources: the linked Clay documentation, as of 12 October 2026.