Standardize and Validate Records

GTM Lab's Contact phone field has five formats in active use. A routing rule that expects one normalized format keeps misrouting calls. Someone builds a fix scoped to the manual-entry form. Reps typing in a new Contact by hand now get a clean number. The routing rule keeps failing anyway, because a weekly marketing list import and a nightly integration sync both write the same inconsistent formats straight past the form the fix was scoped to.

A canonical form needs every door covered

Normalization makes a value consistent; validation catches a value that shouldn't save at all. Neither is complete until it's specified where it runs: manual entry, bulk import, and integration write. A rule that only fires on the manual-entry form isn't a smaller, weaker version of full coverage. It's a rule that looks like it's working while the real problem keeps recurring through every other path.

The decision: canonical form, every trigger point, a real enforcement choice

For each field family that feeds a report, routing rule, or handoff, define a canonical form, the full set of trigger points it must cover, and an enforcement behavior: block, block-and-flag, flag-only, or auto-correct-and-flag. Blocking every import over one bad phone number usually isn't worth the disruption; auto-correct-and-flag is often right for bulk paths, with block-and-flag reserved for manual entry, where a person can fix it immediately.

Carry this into your business

Test a new validation rule against every path data actually enters through, not just the form you happened to be looking at when you built it.