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.
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.
Does this affect leads already in the system? No. Rules apply to leads arriving after you save.