A field was renamed and the integration broke: where to look
Someone renamed a field last week. Nothing threw an error. Leads still arrive. But the sales team says the product-interest answer is blank on half the new records, and a report that was fine on Monday now shows zero.
That is the usual shape of a renamed-field break. It is rarely loud. A rename is a small, reasonable change in one tool, and other places that referred to the old definition can keep pointing at it.
This guide lists the places a field name hides, a quick test that finds the break, and what to change so the next rename does not repeat it.
Why a rename does not raise an error
Some connections between tools record a field's name and type once, when they first sync it. One marketing tool's own support article says it plainly: after a field is changed in the CRM, the marketing tool keeps the original properties and needs a manual change. Until someone makes that change, the connection is aimed at a field that no longer means what it did.
What you see depends on where the stale reference sits. In one public forum thread, a form step skipped three renamed fields with no sync error while three unchanged fields kept syncing; the cause was never confirmed there. That mix of "mostly working" and "quietly wrong" is why these breaks can last for weeks.
Which changes actually break things
Not every change breaks the same way, and it differs by tool (our reading; check yours):
- A label-only rename often breaks nothing, because many tools point at a field by an internal name or id and only the display name changes.
- A type change, or deleting and recreating a field, is the usual culprit: the connection still holds the old definition. The source quoted above covers a change of name and type together.
- Renaming a list value (say "EMEA" to "Europe") quietly breaks every rule, filter and mapping that tests for the old value.
- A permission gap can look identical: the connection's login may not be allowed to write a newly created field, so values are silently not written.
So the useful question is not "was something renamed?" but "what changed in the definition of this field or its values, and who refers to it?".
The places a field name hides
When a field is renamed, retyped, merged or deleted, check each of these. They are the same in most revenue stacks, whatever the tools are called.
- The connection between two tools. The field mapping in the sync or integration. This is the first place to look.
- Forms. The form field that fills it, and any hidden fields that carry a campaign or source value.
- Routing and assignment rules. Conditions such as "region equals" or "company size is".
- Automation and workflow filters. Any "if this field is" step, including enrolment criteria for a sequence.
- Scoring and qualification formulas. A renamed value can quietly give every lead a score of zero.
- Reports, dashboards and exports. Filters and columns that name the field.
- Email and message templates. Merge fields that insert the value into text.
- Spreadsheets, BI tools and warehouse jobs that read an export by column name.
The quick test
You do not need to read configuration to find out whether a rename broke something. Test the path the way a lead takes it.
- Pick the five fields your forms fill most: for example source, campaign, product interest, phone and country.
- Submit one test lead and give each of those fields a distinctive value, such as "ZZ-test-interest".
- Wait for one full sync cycle (often 5 to 15 minutes; check your connection's schedule), then open the new record in the CRM and in your sales tool.
- Note every value that is missing or sitting in a different field.
A field that is blank on the test lead and blank on last week's real leads is your break. If the test value shows up in the CRM but not in the sales tool, the break is in the second hand-off, not the first.
Then do the paper check. Ask the person who administers each tool for the list of fields changed in the last 90 days, and lay it beside your field mapping. Every changed field that appears in the mapping needs an answer.
Count the blanks, not the records
Record counts will not show this break, because the records still arrive. Count the share of new records where each important field is empty, week by week.
If product interest was empty on 4% of new leads for two months and is empty on 47% this week, you have found the week it broke, and you can usually find the change that caused it. This is cheap to do by hand once, and tedious to repeat, which is why it tends not to get repeated.
How to make the next rename boring
- Name an owner for each shared field. The person who can rename it should know who else depends on it.
- List the references before the change. The eight places above work as a checklist. If you cannot say where a field is used, find out first.
- Test in a sandbox where you have one, and run the five-field test lead after the change in production.
- Announce the rename to the owners of the forms, the routing rules and the reports before it happens, not after.
- Watch the blank rate of your five most important fields for two weeks after any change.
Watching this all the time
Navceed is being built to watch hand-offs like this continuously: follow each record through every step, notice when one breaks, show the cause in plain words and prepare the fix for the data owner to approve. Today it works on an example company; connecting your own tools is coming next. Take the workflow break check on your own setup.