— N° 02 · Function justification
An account-readiness score built on three signal tiers — a leadership change, category intent, and a category-specific negative event. Clay covers two of them natively. This is how I built the third, from both directions.
Two ways to move data between Clay and a tool it doesn’t integrate with. They point in opposite directions.
Clay reaching out. When I need something Clay doesn’t have built in natively, I write a call and go get it — Clay asking another tool for data.
Clay → tool · on-demand pullAnother tool telling Clay something happened, and the data shows up on its own. The event triggers the push back to Clay.
tool → Clay · event-driven pushI built this off my old employer, who sold ITAM / ITSM solutions into IT departments managing large asset volumes. The core question was never “does this account fit the ICP.” It was “is this account ready to talk.”
The trigger logic and tiering structure aren’t tied to ITAM / ITSM. Swap the signal sources — a leadership change, a category-specific negative event, category-specific intent — and the same three-tier framework scores any account-based motion. What has to change is the signal definitions per category, not the scoring architecture. That’s what makes it a reusable function instead of a one-off table.
// tiers rank readiness, not fit — Tier 1 is the most time-sensitive
Clay’s native integrations cover two of the three signals. Job-change tracking handles leadership changes; Bombora handles web intent. Neither covers breach events — there’s no “has this company been breached” source anywhere in Clay’s 150+ integrations. That’s where I go past the ceiling.
Clay calls a news aggregator (NewsAPI or GDELT) with a query like [company] "data breach" OR "cyberattack" and pulls back recent hits to feed the Tier 2 score. Runs when I’m actively working a list.
pull · confirms on the way into the scoreA Google Alerts–to-webhook bridge (Pipedream or Make) watches for the same breach language plus new CIO / VP announcements, and pushes straight into Clay the moment either fires.
push · matches the Tier 1 urgency thesisThe API gives on-demand pulls, the webhook gives real-time pushes. Both fill the same gap from different angles instead of duplicating each other.
n8n runs hourly, reads an active company list from a data table, fetches each company’s Google News feed for breach / cyberattack language, filters to real matches (company name and keyword together), and POSTs the matches to a Clay webhook. Clay ingests the row, then the Function runs on the domain: native leadership-change lookup, native intent lookup, and an HTTP API call to NewsAPI as a second breach check.
Inside the Function: Clay-native lookups in green, the custom breach fill in red. The webhook feeds the row in; the Function’s HTTP call is the second, on-demand check.
Tried hand-typing the input reference into Clay’s HTTP API field — {{Function inputs}}?.website. Clay doesn’t parse that as text. Fixed by using Clay’s / picker to insert a real input chip instead.
NewsAPI needs uppercase AND / OR and quoted phrases ("data breach"), or it treats the operators and multi-word phrases as loose search terms.
Started with one RSS trigger per company, which meant rebuilding the workflow for every new account. Rebuilt as a single Schedule trigger reading a Data Table — adding a company is one row now, not a new trigger.
Wanted to read the watch list straight from Clay, but that needs Clay’s Enterprise-only Tables API. Used an n8n Data Table as the workaround, noted as a known limitation.
Still debugging the webhook company data when running the new Clay Function on it.
Native integrations are a ceiling, not a wall. When the signal you need isn’t one of the 150, an API call goes and fetches it and a webhook waits and catches it — choose by whether the value is in having it now or in never missing it.
For a readiness score, that isn’t either / or. The webhook keeps the list warm between working sessions; the API call confirms the signal on the way into the score.
Build artifacts: Clay table Webhook + Function · Loom walkthrough — link coming