The rule stops living in someone’s head
A salary keyed below the pay scale minimum in March, noticed in December at the salary review. The Validation Framework holds the rules that decide what is valid in your organisation: applied the moment data is entered, checked again on the records already saved, and yours to change after go-live.
Found too late
Data problems are cheap to fix at the keyboard and expensive everywhere else. This is what waiting costs.
Not every issue is equal, the framework knows the difference
A rigid block breeds workarounds; no validation breeds bad data. Three severity levels let each rule respond in proportion to what's at stake.
Cannot proceed
The transaction stops until it's fixed. No bypass. For data that must be right: a salary below the pay scale minimum for the function.
Proceed with awareness
Flagged, and the user can continue knowingly. A rise of more than 10% goes through, and it is on the record that it did.
Awareness only
A gentle prompt, no obstruction. No reason recorded for the change: useful to have, never a reason to stop.
Caught on the way in, and checked again after
Every action is a transaction: a field edited, a hire submitted, a leave request raised, a thousand rows loaded by an interface. A rule attaches to any of them and fires the moment it happens, so the error reaches the person who can still fix it, in plain language and with the correction in reach.
A record that was valid when it was saved can stop being valid later. The same rules run again over what is already stored, on a schedule, and report what no longer holds without blocking anyone: a hire date that now overlaps an earlier period, a Vetting credential that has lapsed. Somebody works through that list and closes it off.
The same rule, twice. Once at the keyboard, once over everything already saved.
It knows the rule, whatever its origin
Most validation only checks that data is well-formed. The Validation Framework goes further: a rule is a rule, wherever it comes from, and it applies all three at the point of entry.
Data integrity
Format, completeness, plausibility: a valid IBAN, a national number that checks out, a required field actually filled.
Legislation
Statutory rules: mandatory data, legal minimums, country payroll requirements, so what the law expects is enforced, not left to someone remembering it.
Internal policy
Your own rules: company policy, sector accreditation, governance standards, encoded once and applied the same way every time.
And when a rule fires, it tells your people which rule it is, why it applies, and what to do about it. Your organisation learns the rules while applying them.
Configured to your reality, manageable after go-live
The rules are rows in a table. That is what makes them yours to change.
Popay sets it up with you
The initial framework is built during implementation, with your own rules in it from the start.
You change it after go-live
Add a rule, change a severity, retire one, in the editor. No implementation project every time your reality shifts.
The law is ours to chase
Legislative rules, payroll above all, across every country in scope, are maintained centrally and kept current. Your integrity and policy rules stay yours.
Trust the data the whole platform runs on
Every module reads the same record: payroll, reporting, compliance, Employee lifecycle. When quality is enforced at the source, in proportion, and against the right rule on every transaction, the record stays trustworthy by default. The error that would have surfaced in December simply never gets saved in March.
Nowhere does that matter more than payroll: get the data right at the keyboard and the run is right the first time, no corrections, no wrong pay, no compliance scramble after the fact.
Caught at the source. Long before the year closes.
Stop finding errors at year-end
Validate every transaction at the source, in proportion to what's at stake, and keep the record the whole platform runs on trustworthy by default.
Book a demo →