Building a compliance screening workflow with n8n and OpenAI

Adverse media screening is the kind of check that's easy to skip when everyone is busy closing deals, and the cost of skipping it only shows up later, when it's expensive. We built a workflow inside the client's HubSpot that screens 100% of qualified companies automatically, posts findings straight to the relevant deal record, and keeps a date-stamped audit trail on every company it checks, so there's no gap between a new deal appearing and it actually getting screened.

Why manual compliance screening falls apart

Manual screening depends on someone remembering to run it, every time, for every qualifying deal, and remembering doesn't scale with volume. When deal flow is light, screening happens reliably. When it picks up, screening is the first thing to slip, because it feels less urgent than moving the deal forward. The result is a compliance process that exists on paper but runs inconsistently in practice, with new deals sometimes going unscreened for days.

How does the workflow decide a company should be screened?

The workflow triggers automatically on new HubSpot deals that meet the client's qualifying criteria, no one has to flag a deal for review. From there it runs an adverse media search through the Serper API, hands the raw results to OpenAI's model to summarize what actually matters, and posts a structured report to the relevant Slack channel and the deal record itself. Flags typically land in under two minutes from the moment a qualifying deal is created.

Exact-phrase matching for a deterministic 'clean' result

A screening result that says 'clean' has to actually mean clean, consistently, not just whatever the model felt like that day. That's why the matching logic behind a clean determination is built around exact-phrase matching against known risk terms, rather than leaving the call entirely to a model's loose judgment on ambiguous search results. The model summarizes and explains what it found, but the underlying decision of whether something counts as a flag follows deterministic rules, which is what makes the audit trail defensible later.

Why Serper API search feeds OpenAI, not the other way around

The order of operations matters here. Serper API runs the actual web search first, returning real, current results tied to a specific company name, and only then does the model see and summarize what came back. Asking a model to generate risk findings from its own training data instead of a live search would produce answers that sound confident and could easily be outdated or entirely wrong. Grounding the model in real search results first, and restricting its job to summarizing what's actually there, is what keeps the output trustworthy enough to act on.

Auto re-screening when a check gets stale

A clean result from six months ago isn't a clean result today. The workflow checks the date stamp on each company's last screen and automatically re-runs the check once it's older than 30 days, without anyone needing to track screening dates on a spreadsheet. That single rule is what turns a one-time check into an ongoing compliance posture instead of a snapshot that quietly goes out of date.

What the audit trail actually looks like

• >Every screen is time-stamped and tied to the specific deal record
• >Findings post to Slack for immediate visibility and to HubSpot for the permanent record
• >Re-screens trigger automatically past the 30-day mark, no manual tracking
• >Exact-phrase matching keeps 'clean' results consistent and explainable later

What findings actually get posted, and to whom

A screening result is only useful if it reaches someone who can act on it, quickly and without digging. The report that lands in Slack summarizes what the search actually found in plain language, not a raw dump of search results someone has to interpret themselves, and it links back to the underlying source so a compliance reviewer can verify the finding directly rather than trusting the summary blind. The same summary writes to the deal record in HubSpot, so the finding stays attached to the deal permanently, not just visible in a channel that scrolls away within a day.

Before vs after

mkdir builds this kind of screening workflow directly inside the CRM you already run, so compliance stops depending on someone remembering to run a check.