Validations are the guardrails of your data program.
They protect your work by catching issues early and making quality expectations visible.
Without validations:
different teams interpret data differently
errors travel downstream
reporting becomes a negotiation
With validations:
issues are flagged at the right moment
corrections happen before data becomes final
trust increases across the program
Administrators can:
create validations
edit validations
remove validations
enable/disable validations without deleting them
This makes governance practical: strict when needed, flexible during change.
In many client programs, validations are not "one size fits all."
Some rules may run:
only for specific objects
only for specific parts of a workflow
Labels act like "tags" that determine where and when a rule is applied.
From a client perspective:
Labels help keep governance organized.
They allow different teams or workflows to have the right checks, without overloading everyone with every rule.
The best validations are readable.
They should include:
a clear name
a description explaining why the rule exists
a friendly message that tells users what to fix
Validations typically have a severity:
Warning: informs users, but doesn’t stop progress
Error: requires attention and correction
Blocker: prevents progress until fixed
A common adoption path:
start as warnings (teach)
upgrade to errors (enforce)
reserve blockers for critical business rules (protect)
The enable/disable feature is valuable because real programs evolve.
During onboarding you may:
temporarily disable a strict rule while users learn
adjust file templates
re-enable the rule once the process stabilizes
This keeps teams moving without giving up governance.
Last updated