CRM field mapping is unglamorous and non-negotiable
Inconsistent field naming across Clay, n8n, HubSpot, and Salesforce creates silent failures that take weeks to debug.
Nobody talks about field mapping because it’s boring. It’s also the thing that breaks most GTM automation builds three months after they go live.
The pattern: Clay enriches a record and outputs company_industry. The n8n node that writes to HubSpot is looking for industry. HubSpot stores it as hs_industry. The write fails silently because n8n can’t find a matching field. The CRM record never gets updated. Nobody notices for six weeks because the workflow shows green.
A field mapping standard that I apply to every build before writing a single automation:
Establish a canonical field name. Pick one naming convention (I use snake_case) and apply it everywhere. The Clay column, the n8n variable, the CRM internal name, and the display label all reference the same canonical name. company_employee_count everywhere, not Employee Count in HubSpot and num_employees in Clay and headcount in the n8n variable.
Document the field map before building. A simple spreadsheet: canonical name, Clay column name, HubSpot internal name, Salesforce API name, data type, source of truth. Takes an hour upfront. Saves days of debugging.
Treat data type mismatches as bugs. Clay stores employee count as a string. HubSpot expects a number. The write will fail or produce garbage data. Explicitly cast types in your n8n transformation nodes before writing to CRM.
Version control your field map. When you add a new enrichment source or change a scoring methodology, the field map changes. Treat it like a schema migration. Document what changed and when.
This is not the interesting part of GTM engineering. It’s the part that determines whether the interesting parts actually work.