Building a compliance screening workflow with n8n and OpenAI

Compliance screening for adverse media is easy to skip when everyone is busy closing deals. The cost of skipping it shows up later, when it's expensive. We built a workflow inside the client's HubSpot that screens 100% of qualified companies automatically. It posts findings straight to the relevant deal record and keeps a date-stamped audit trail on every company it checks, so no new deal sits waiting to be screened.

Why manual compliance screening falls apart

Manual screening depends on someone remembering to run it 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. You end up with a compliance process that exists on paper and runs inconsistently, with new deals sometimes going unscreened for days.

How does the workflow decide a company should be screened?

It runs as an n8n workflow in the client's stack and triggers on new HubSpot deals that meet the client's qualifying criteria, so nobody has to flag a deal for review. It runs an adverse media search through the Serper API, hands the raw results to OpenAI's model to summarize what matters, and posts a structured report to the relevant Slack channel and to the deal record.

Exact-phrase matching for a deterministic 'clean' result

A screening result that says 'clean' has to mean clean every time, whatever the model felt like that day. So a clean determination rests on exact-phrase matching against known risk terms. The model summarizes and explains what it found, but whether something counts as a flag follows deterministic rules. That makes the audit trail defensible later.

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

The order of operations matters here. The Serper API runs the web search first and returns real, current results tied to a specific company name. Only then does the model see and summarize what came back. A model asked to generate risk findings from its own training data would produce answers that sound confident and could easily be outdated or entirely wrong. We ground the model in real search results and restrict its job to summarizing what's there. That 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 re-runs the check automatically once it's older than 30 days. Nobody tracks screening dates on a spreadsheet. That one rule turns a one-time check into ongoing compliance.

What the audit trail 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 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 found in plain language. Nobody has to interpret a raw dump of search results. It links back to the underlying source, so a compliance reviewer can verify the finding directly and doesn't have to trust the summary blind.

The same summary writes to the deal record in HubSpot, where the finding stays attached to the deal permanently. A channel message 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.