UAE/GCC
Most HubSpot data enrichment failures don't announce themselves. Workflows run, records update, and your CRM looks populated, until you realise the data is incomplete, misattributed, or quietly timed out before it ever wrote back. When Oxygen built an LLM-based enrichment stack for ABM targeting inside HubSpot, we hit all three of the most common failure modes before landing on an architecture that actually works.
This is what we learned.
Mistake 1: Calling the LLM Directly from a HubSpot Workflow
Image: Workflow errors out after hitting HubSpot's 20-second runtime limit.
The most natural-seeming approach is the most dangerous one. You open a custom code action inside a HubSpot workflow, write a Python or JavaScript block that calls your LLM API, and expect the result to write back to a property. For simple, fast API calls, this works. For LLM queries that involve web crawling, like researching whether a company is hiring for a specific role, it routinely fails.
HubSpot's developer documentation is clear: custom code actions must complete within 20 seconds and are capped at 128MB of memory. Exceeding either limit throws an error. The problem is that a web-crawl-backed LLM query (the kind you need for meaningful enrichment signals), can easily take 30, 45, or 90 seconds depending on the model, the query complexity, and what it's retrieving. The workflow errors out, nothing writes to the record, and unless you have solid logging in place, you may not catch it for days. Practitioners in the HubSpot community have documented exactly this pattern: the workflow fails silently, without clear diagnostic feedback, making it one of the harder failure modes to diagnose.
Mistake 2: Writing One Giant Prompt to Qualify a Company
Image: One prompt, multiple properties. A maintenance problem waiting to happen.
The second failure is conceptual rather than technical, though the consequences are just as damaging to your HubSpot lead data. Teams trying to enrich quickly will write a single, comprehensive prompt: "Given this company, tell me whether they're hiring in marketing, whether they use a CRM, whether they have a content team, what their funding stage is, and whether they show intent to buy." The model responds with a long, loosely structured output. You parse it, try to map each answer back to a different HubSpot property, and discover the model frequently conflated questions, skipped signals, or gave you a response that doesn't parse cleanly into a field value.
The deeper problem is context dilution. LLMs handle single, well-scoped tasks more accurately than compound ones. When you ask the model to evaluate ten signals simultaneously, the output quality of each individual signal degrades. You also make it structurally harder to maintain: if you want to change your hiring signal logic, you're editing the same prompt that controls your technology detection, your content freshness check, and your lead capture quality score. One edit can break three things at once.
Oxygen's solution was to build one function per signal. The enrichment stack we landed on includes separate prompts, and separate workflow triggers for marketing hire intent, sales hire intent, AI role hiring, systems integrator search, content freshness, lead capture quality, sales friction, and self-service intent. Each function maps cleanly to a single HubSpot property. This makes outputs reliable enough to act on, debugging straightforward, and prompt iteration surgical rather than risky.
Mistake 3: Relying on LinkedIn for Hiring Signal Data
If you want to know whether a company is actively hiring for a revenue operations manager or a marketing automation specialist, LinkedIn seems like the obvious data source. It is also, in practice, nearly useless for LLM-based enrichment. LinkedIn aggressively blocks automated requests, and most LLM web-crawl queries against LinkedIn listings will return an error or no usable data.
Image: LinkedIn blocks automated requests, making it useless for enrichment pipelines.
LinkedIn Recruiter theoretically unlocks structured access to this data, but at approximately $1,500 per month it's not a realistic option for most enrichment pipelines, particularly when hiring signal is just one of a dozen data points you're trying to populate.
The practical answer is to use open job boards (Jobs DB, Robert Walters, Michael Page) and to cross-reference LLM outputs against those sources manually before trusting the data at scale. The model will tell you a role exists. It's your responsibility to verify that it does before you act on that signal in a workflow or scoring model.
The Fix: Middleware as the Architectural Foundation
All three failure modes share a common fix: route enrichment calls through a middleware layer rather than executing them directly inside HubSpot. Oxygen uses Google Cloud Functions for this, but the same architecture works with Make, Zapier, n8n, Azure Functions, or regional equivalents like Tencent Cloud Functions or Alibaba Function Compute for teams operating in mainland China.
The reason this works is straightforward. When HubSpot's workflow triggers an enrichment action, instead of executing the LLM call inline, it fires a request to the middleware endpoint and moves on. The middleware handles the LLM call on its own compute, with no timeout ceiling imposed by HubSpot's runtime. When the result is ready (whether that takes 20 seconds or two minutes), it writes back to the HubSpot property via API. This is also the pattern recommended by practitioners dealing with rate limiting in HubSpot workflow custom code actions: decouple the execution from HubSpot's constraint environment entirely.
The second advantage of middleware is model flexibility. Because the calls are routed through a layer you control, you can match different LLMs to different signal types based on actual capability rather than API convenience. Gareth's team uses Gemini for web-search-heavy tasks like hiring signals, DeepSeek for China-specific company data (particularly valuable given Oxygen's focus on APAC markets — if you're working with Chinese company data inside HubSpot, see our notes on using HubSpot in China), Claude or GPT for other enrichment types. No single model is best at everything. Middleware lets you stop pretending otherwise.
How to Run This Without Breaking Your Database
Architecture aside, the process discipline matters as much as the technical setup. Before a single prompt goes into a workflow, test it directly inside the model. Get the output format, the logic, and the edge case handling right in the model's native interface first. Only once the prompt is behaving consistently should you move it into the automation layer. This sounds obvious, but most teams skip it and spend hours debugging failures that were always prompt problems, not infrastructure problems.
When you do run enrichment through the workflow, start with a sample of 10 to 30 companies, not your full database. LLM outputs have variance, and until you've validated that a given prompt produces clean, mappable results at small scale, you have no business running it across thousands of records. The data quality risks of running untested enrichment at volume (writing bad values, overwriting good ones, corrupting scoring models) are significant. Building solid HubSpot contact management practices means treating enrichment data with the same governance rigour you'd apply to any data import. A well-considered global CRM strategy accounts for data integrity from the start, not as an afterthought.
Once enrichment is running at scale, the verification discipline doesn't stop. Cross-reference hiring signal outputs against real job boards before using them to trigger outreach, score accounts, or feed into lead assignment rules. The model can hallucinate a job posting with complete confidence. A quick manual check against Jobs DB or a specialist recruiter site like Robert Walters takes two minutes and can save you from building a segment on data that doesn't exist.
What This Looks Like in Practice
Image: Middleware handles async execution, removing LLM calls from HubSpot entirely.
Oxygen's production enrichment stack, as it now stands, runs eight independent signal functions through a middleware layer, each mapping to a discrete HubSpot company property. Marketing hire intent, sales hire intent, AI role hiring, systems integrator search, content freshness, lead capture quality assessment, sales friction indicators, and self-service intent all run independently, trigger on different criteria, and write to separate fields. Nothing is coupled. A change to the AI role hiring prompt affects nothing else. A failure in the content freshness function doesn't cascade. Each signal can be monitored, refined, and re-run without touching anything adjacent.
This architecture also makes the enrichment commercially legible to the people who use the data. A sales rep looking at a company record can see that "marketing hire intent: high" is a specific, sourced signal — not a black-box score derived from a prompt that nobody can fully explain. That legibility matters for adoption. CRM data only creates value when people trust it enough to act on it.
If you're building or rebuilding an enrichment pipeline inside HubSpot and want to avoid the architecture mistakes that take weeks to diagnose, Oxygen's HubSpot implementation team works with mid-to-large enterprises across APAC and the GCC. The systems we build are designed to be maintainable and explainable — not just functional on the day they launch.
Learn more about how we approach HubSpot onboarding and implementation for complex, multi-market organisations.
