Platform · underneath all of it
“Fully integrated” usually means two databases and a nightly job.
It works until somebody merges two duplicate customers, or an employee changes their name, or a record is deleted on one side. Then the two halves disagree, quietly, and nobody finds out until a number is wrong in front of a client.
The test is not whether the modules talk. It is what the database refuses to allow.
- One person record, enforced not conventional
- An audit trail that cannot be edited by anyone
- Support access is a two-key process, logged to you
- Salary band changedR. Ellisfrom 84,000 to 91,000 · Firefox on macOS
- Payslip reissuedacting as A. Mensahby our support engineer, under an approved window
Three answers a competitor does not have
What a suite cannot say, however well its integrations work.
Each of these is answerable here, and each is a page you can read before you ever speak to us.
Automations
Rules that cross module boundaries, with every failure made visible.
A rule fires on something that actually happened somewhere in the product and can reach into another module — opening a deal when a placement is made, starting onboarding when a hire is accepted, flagging an invoice when something upstream reverses.
The interesting part is what happens when one misbehaves. Nothing fails silently: a loop is capped and says so, an over-firing rule is throttled with the count, and switching a module off pauses the rules that depend on it rather than leaving them active and quietly skipping — which is the failure nobody diagnoses.
- It would loop→ capped — and a row is written saying so
- It is firing too often→ throttled — with the count in the reason
- The module it needs was switched off→ the rule is paused, with a distinguishable reason
- Everything, right now→ one switch stops every rule without writing a row per rule
- You can rehearse a rule against real history —
Replay a proposed rule over what actually happened and see which events would have matched, and why the rest would not — before it ever fires.
- And forecast how often it would fire —
Because a rule firing fifty times a week is fifty decisions somebody has to make.
- A rule can require a person to approve it —
And if the approval itself cannot be started, the run is marked failed rather than proceeding ungated.
Being straight
Four things in this layer that are declared and do not work.
Criteria-based sharing rules can be written, saved and audited, and widen nobody's access — there is no evaluator behind them. A custom field can be marked required or unique, and neither is enforced. Scheduled and threshold triggers on an automation are accepted and never fire; only event-triggered rules run. And data residency is a label on a workspace with no routing behind it.
Each is being fixed. Until they are, they are not claims — they are on this page so you do not discover them during implementation.
The whole layer
Every capability, with a page that names the screen.
Written after reading how each one actually behaves — which is why each page tells you what it refuses to do as plainly as what it does.
Questions that decide it
Mostly asked by a security review.
›How is our data kept separate from another customer's?
At the database, as a condition on every row, set per request — not as a filter each query has to remember. Every table in the product carries it, and the strictest tables enforce it even against the application's own connection.
›Can your staff see our data?
Only through a process that leaves a record in your audit trail — a written justification, approval by colleagues who are not the requester, a short window, and revocation available to any of your administrators. The honest caveat: the setting that requires that process for impersonation ships switched off, and it should be switched on. Ask us to confirm it is, for your workspace.
›Is there an API?
Yes — the same API the product itself uses, with keys that inherit the permissions of whoever created them, scoped to reading or writing and to a product area. Webhooks subscribe to the same real events the automations use, signed, with a retry ladder, dead-lettering and genuine replay.
›Are reads recorded as well as changes?
Changes, thoroughly. Reads generally not, with named exceptions where a sensitive value is revealed. If your obligations include access logging, raise it — that is a gap rather than a design.
›Can we build our own permission bundles?
Custom roles are composed from the bundles that ship. Authoring an entirely new bundle is not available today.
Book a demo
Bring your security questionnaire.
We would rather answer these before a contract than during one.
- Ask what happens to the audit log when retention expires
- Merge two duplicate people and check what moved, then undo it
- Import a file with nine broken rows and read what comes back
- Switch a module off and see what happens to the rules that used it