Optional module
Some changes should need a second pair of eyes
A landlord's IBAN edited by the wrong person is not a data-entry error, it is a payment sent to a stranger. Governance of this kind normally arrives with enterprise pricing attached.
How it works
An office manager writes the rule in plain language — for example, that when staff change a landlord profile's bank name or IBAN, the manager must approve it. No scripting, no permission matrix.
When a member of staff then makes a matching change, it is not saved. It is captured as a compact before-and-after difference, held separately from your live records, and the record is locked from further editing until somebody decides. The approver sees the old value and the new value side by side and either accepts or rejects it.
On approval the change is applied through the system's ordinary save path, which means every alert, ledger entry and report downstream behaves exactly as though the change had been made directly. Nothing has to be re-run or reconciled afterwards.
The design fails in a deliberate direction. If the approval layer itself has a problem it lets the save through rather than blocking your office's work, while committing an approved change either applies fully or not at all — so nothing is ever left half-applied.
What you get
- Rules written in plain language, not code
- Changes held as a before-and-after comparison, not saved
- Records locked from further editing while pending
- Side-by-side review, then accept or reject
- Approved changes applied through the normal save path
- Pending data kept entirely separate from live records
- Fails open on interception, fails closed on commit
- Switched off by default, and switchable off at any time
Questions
What kinds of changes can be governed?
Rules target the records and fields where a mistake is expensive — landlord bank details, contract rent and dates, cheque amounts and statuses, tenant records. You choose which combinations of role, record and field require sign-off, and everything else continues to save normally.
Will this slow the office down?
Only on the changes you choose to govern. Records and fields with no rule against them save exactly as before, and the rules themselves are held in a way that adds no database work to ordinary pages. Most offices govern a small number of genuinely expensive fields rather than everything.
Set up a rule in the demo
Tell us about a change that has cost you before, and we will write the rule that would have caught it.
Book a demo