3 CRM Automation Problems I Fixed Using Make.com, Airtable, and OpenAI

Most automation consulting sessions don't look like the tutorials you read online. You're not building a clean workflow from scratch with perfect data and a clear spec. You're digging through someone's existing setup, figuring out why something that should work doesn't, and making judgment calls about the right fix without breaking what's already running.

I had one of those sessions recently. The client had a Make.com and HubSpot setup pulling lead data from LinkedIn, but a few things were quietly causing problems downstream. Location fields were messy enough that segments were missing leads, some contacts were arriving in HubSpot without names, and a scoring formula that worked fine in theory was silently miscategorizing leads against real data.

Each issue had a different surface cause, but the same underlying pattern. Here's what I found, how I fixed it, and what I think any automation builder should take from it.

Fix #1: How to Normalize LinkedIn Location Data in Make.com Using GPT-4.1 Mini

The Problem

LinkedIn location fields are a mess. When someone fills out their location on LinkedIn, there's no enforced format. You get things like"Greater Chicago Area,""Fort Lauderdale Metropolitan Area,""Dallas-Fort Worth Metroplex,""New York City Metropolitan Area," and a hundred variations on the same idea. If you're pulling that data into HubSpot and trying to filter, segment, or report by city, you're fighting against every person's individual interpretation of where they live.

For this client, that mattered. They were segmenting leads by market and the LinkedIn location values were inconsistent enough that their filters weren't catching everyone they should. Someone in Chicago might show up in a Chicago search or they might not, depending entirely on how they wrote their location on LinkedIn.

The Fix

I handled this inside Make.com using an OpenAI module. The idea was simple: take the raw LinkedIn location string, send it to a model, and get back a clean normalized city name.

For the model I used GPT-4.1 mini. This is exactly the kind of task where you don't need a heavyweight model. You're not asking it to reason through anything complex, you're asking it to interpret a location phrase and extract a city name. Mini handles it fine, and at the volume this client processes leads, keeping token cost low actually matters. If you're running a few dozen leads a day through this, the cost difference is negligible. If you're running thousands, it adds up. I wrote about how I think about model selection and cost as part of my broader AI tool stack as a CRM founder if you want more context on that decision-making.

For the prompt, I set a system message instructing it to act as a data normalization assistant and return only a JSON object with no additional text, explanation, or markdown. The user message passed in the raw location string. Constraining the output format in the system prompt is what makes this reliable at scale. If you leave room for the model to be conversational, it will be, and your Parse JSON module will break.

The output structure looked like this:

{
"normalized_city":"Chicago",
"normalized_state":"IL",
"normalized_country":"US"
}

After the OpenAI module, I added a Parse JSON module in Make.com, extracted the values from the response, and mapped them to the appropriate HubSpot contact fields. Clean city, state, and country from a raw LinkedIn location string. This is essentially a lightweight HubSpot contact enrichment layer built directly into the sync scenario.

Is It Worth It?

Depends on your situation. If location data drives how you segment or work leads and you're pulling from LinkedIn where the format is inconsistent by design, then yes, this is a reasonable fix. The Make.com scenario isn't complicated to build, GPT-4.1 mini is cheap for this kind of task, and you get reliable structured output you can actually use in HubSpot.

If location is just a nice-to-have field that nobody actually filters on, skip it. You're adding API calls and a small ongoing cost for something that won't move the needle. Know what your data is actually used for before you invest in cleaning it. It's the same logic that applies when you're deciding whether AI prospecting is worth the cost at all. The answer is always"it depends on what you're actually doing with the output."

Fix #2: How to Extract Names from Airtable Linked Records in Make.com

The Problem

This one was subtle. The client had an Airtable base feeding contact names into HubSpot through their Make.com scenario. Most contacts were coming through fine. But a subset was landing in HubSpot without a name, just blank first and last name fields despite the data existing in Airtable.

When I dug into the scenario, the issue became clear. The Airtable module was pulling records correctly, but it was only extracting data from the primary record being fetched. Some of the contact names were stored in a related (linked) record in Airtable, not on the primary record itself. The scenario wasn't reaching into that related record to pull the name, so whenever a contact's name lived there instead of on the main record, it came through blank.

This is easy to miss if you're building quickly. You test with a few records, they look fine, and you move on. The problem only surfaces when your data has variation, where some records have the name directly on them and others link out to a related record for the same information.

This is also why going back to the original user story matters when something breaks. The automation was built to move contact data from Airtable to HubSpot. The user story didn't distinguish between where in Airtable that data lived. When it was written, maybe all names were on the primary record. At some point the data structure changed, the user story became inaccurate, and the automation kept running without anyone noticing the gap. That's not a Make.com problem. That's a requirements drift problem.

The Fix

The fix was straightforward once the cause was clear. In Make.com, linked records from Airtable surface as arrays rather than flat fields, so you have to explicitly access them rather than assuming everything you need is at the top level of the record. Once I knew what to look for, the fix took about ten minutes.

I updated the field mapping to pull from the related record when the name fields on the primary record were empty, added a fallback so it didn't error on records that had no linked record at all, and tested against the contacts that had previously come through blank. Names started populating correctly.

Is It Worth It?

This isn't a"worth it" question. It's a bug. If contacts are landing in your CRM without names, you fix it. But the lesson worth taking is that when you're building Make.com scenarios that pull from Airtable, you need to understand your data structure before you build, not after you find missing data in HubSpot. Audit the schema, identify which fields live on linked records, and handle them explicitly. It's the same principle I ran into building the fax automation workflow: the edge cases you don't test for are the ones that show up in production.

Fix #3: Airtable Lead Scoring Formula Breaks on Job Title Variations

The Problem

The client had a lead scoring formula in Airtable that assigned scores based partly on job titles. The logic was looking for specific phrases in a person's title to determine whether they were likely a decision-maker or influencer. In theory, solid approach. In practice, the formula was brittle.

Job titles in the real world are inconsistent in the same way LinkedIn locations are. If your formula is checking for the word"Director" and someone's title is"Dir. of Operations," they don't get scored correctly. If you're looking for"VP" but someone's title says"Vice President," same problem. The formula was written against a narrow set of expected strings. It was quietly miscategorizing leads whose titles didn't match exactly.

This kind of scoring error is dangerous because it's invisible. The formula runs, it produces a score, everything looks like it's working. But the scores are wrong for a meaningful percentage of your leads. You don't find out until someone notices a good lead got buried or a weak one got too much attention.

The Fix

I expanded the Airtable lead scoring formula to cover a broader set of terms, abbreviations, and synonyms for each scoring tier. For titles that should score as senior decision-makers, I added variations like"VP,""Vice President,""V.P.,""Dir,""Director,""Dir.,""Head of,""Chief," and the relevant C-suite abbreviations. Same treatment for the other tiers.

Airtable's OR() and FIND() formula combination handles this well. You check whether any of the qualifying strings appear anywhere in the title field. The formula gets more verbose but it's dramatically more reliable. I also added a few industry-specific terms this client's target market uses for roles that don't map neatly to standard corporate titles. Generic scoring logic misses these consistently.

One broader note on this: when you're building scoring or filtering logic that touches your data, put it in Airtable formulas rather than Make.com conditions and filters. Make.com conditions work, but they live in the automation layer. If you ever swap platforms, migrate scenarios, or hand the system off to someone else, that logic disappears. Airtable formulas stay with your data. Your source of truth should live at the source, not inside whichever automation tool you happen to be using today.

Is It Worth It?

Yes, and it should have been built this way from the start. Scoring logic that's brittle isn't really scoring logic. It's a formula that works for some leads and silently fails for others. If the formula is inconsistently applying that logic, you're better off without it than with a false sense of confidence in what the scores mean.

If you have scoring logic in your CRM or your data layer, audit it with real data. In my experience, ten minutes of spot-checking against actual records finds more gaps than an hour of reviewing the formula in isolation.

The Bigger Pattern: Why Automations Break the Same Way Regardless of Platform

Looking at these issues together, there's something worth saying about how automation actually fails in practice.

All automations, at their core, handle something a human no longer wanted to do. When they break, the fastest way to diagnose the problem is usually to go back to the original user story and figure out where reality diverged from what the automation was built to handle. In this session, every issue traced back to something that had drifted from the original intent: location data that was never standardized, a data structure that had evolved, scoring logic that was written against a hypothetical title format instead of real ones.

It's also worth saying that Power Automate, Make.com, UiPath and others all look different on the surface, but they break for most of the same reasons. Either a source data problem is preventing a trigger from firing, data mapping is wrong somewhere in the flow, or the underlying business process has changed and nobody updated the automation to match. The tools are different. The failure modes aren't.

The other thing that would have caught most of these issues earlier is iterative development with early user feedback rather than building in a silo and releasing all at once. If someone had been reviewing the HubSpot contacts coming in during the build, the blank name fields would have surfaced in week one. Instead they accumulated quietly for however long the scenario had been running. Soliciting feedback on whether the data looks right while you're building is worth more than any QA pass after the fact.

The LinkedIn location field worked fine until you noticed LinkedIn has no format standard and every user fills it in differently. The Airtable extraction held up until a contact had their name in a linked record instead of directly on the primary one. The scoring formula ran correctly until a lead's title used an abbreviation the formula didn't account for. The logic wasn't wrong. The data just didn't cooperate the way the builder assumed it would.

If you have a Make.com scenario pulling CRM data from LinkedIn or Airtable, do a spot check. Pull some records and manually compare what came into HubSpot against what was in the source. Start with the fields your team actually filters on. If those are coming from a third-party source like LinkedIn, I'd bet they're not as clean as you think.

Frequently Asked Questions