Outcome. State and province entries such as "California", "calif.", and "CA" all collapse into one standard two-letter code, so territory routing and address-based reports read the same value.
flowchart TD
A[State and country known, not yet normalized] --> B[Custom code: lookup table match by country]
B --> C{Match found?}
C -->|yes| D[Set two-letter code, status = Normalized]
C -->|no| E[Status = Needs manual review]
E --> F[Add to review list + create task]

When to use it, when not to
- UseUse it when
State/Regionis, or was, free text, and existing data has many spellings for the same state or province. - UseUse it before territory-based lead routing that filters on state, since inconsistent spellings silently miss records that should match.
- SkipDo not use it on portals operating only outside the United States and Canada, where "state" is not the relevant administrative unit. Adapt the lookup table to the country's actual regions, or skip this workflow entirely.
- SkipDo not use it to normalize country values. See data-quality-004 for
that; run it first, since state normalization here assumes a clean
Country/Regionto pick the right lookup table (US versus Canada).
or the data quality pack, 39 EUR
One-time, excl. VAT. 30-day refund, no questions asked. Founding prices until 31 October, then 199 and 59 EUR. Includes every spec added later, up to the full 500, and the one-click installer on the full library. Building on client portals? The agency licence at 449 EUR covers unlimited client portals.





