Data normalization
Clean incoming values once — lowercase emails, reformat phones, translate values — before anything else runs.
Normalization rewrites a field's value on arrival. Open the Normalize step on the pipeline canvas, add a rule per field, save.
It runs at intake, before validation, deduplication, scoring and distribution — so every buyer receives the cleaned value, and dedup compares cleaned values (lowercase the email once and John@X.com stops slipping past john@x.com). It applies to every lead in the pipeline, whatever source it came from, including CSV imports.
Available transforms
| Transform | What it does |
|---|---|
| Map values | Translate one value into another: sedan → car, Y → yes. Case-insensitive by default; unmatched values can pass through, be emptied, or fall back to a fixed value. |
| Text case | UPPERCASE, lowercase, or Title Case. |
| Phone format | E.164 (+15551234567), national ((555) 123-4567), international, or digits only. |
| Date format | Auto-detect the incoming format (or state it), output MM/DD/YYYY, DD/MM/YYYY, YYYY-MM-DD, MM-DD-YYYY, Unix or ISO. |
| Number format | Fixed decimals, optional thousands separator. |
| Fixed value | Always send the same value, whatever arrived. |
Every rule also has two options behind Options — trim & empty default: Trim spaces, and If empty, send a fallback value.
Two behaviors worth knowing: a rule only fires when the field is actually present (it never invents a field), and a value that can't be converted — an unparseable date or phone — is left unchanged rather than blanked. The editor shows a live example of the result as you configure it.
A phone number typed without its country code (0412345678) is read in the lead's own country field when it has one, otherwise in the pipeline's default country, then the visitor's country, then the United States. Set the default country on a non-US pipeline and Phone format writes +61412345678, not a number read as American. A buyer's own phone format and a {phone|phone:e164} merge code read the same country.
Normalization or source mapping?
| Your problem | Where to fix it |
|---|---|
A supplier calls it email_address, you call it email | Source field mapping — per supplier |
Values arrive messy: mixed case, spaces, (555) 123-4567 vs +1555… | Normalize — once, for the whole pipeline |
One buyer wants dates as DD/MM/YYYY while others want ISO | The buyer's delivery format — per buyer |
Rule of thumb: mapping decides which field, normalization decides what the value looks like, delivery formatting decides what one buyer sees.
Common questions
Does the lead keep its original value? No — the lead is stored normalized. If you need to see exactly what a supplier sent, keep the transform narrow, or check the spam filter's stored matches (those are captured on the raw values).
Does the spam filter see cleaned or raw values? Raw. It runs on reception, before normalization, so your conditions are written against what suppliers actually send. See Spam filtering.
Can I normalize a field that isn't in my canonical fields? The picker suggests your canonical fields, but any field name works. It only fires when a lead carries that field.
Why isn't my phone transform doing anything? The value probably couldn't be parsed as a phone number, so it passed through untouched. Check the live example in the rule with a real value from a lead.
My phones are Australian but come out as US numbers (or unchanged).
They arrive without +61 and the pipeline has no default country, so they're read as American. Set Default country in the pipeline's settings, or have the supplier send a country field.
Does this affect leads already in the system? No. Rules apply to leads arriving after you save.