Capability
One record per person. One consent history that is evidence.
Contact details, addresses, identifiers, sign-in methods, devices and preferences, held once and scoped to your tenancy. Consent is tracked per purpose and per channel rather than as a single switch, and every genuine change appends an immutable event you can produce years later.
The record, in parts.
The person
Contact details, preferred name, identifiers and your own application username — so you can look somebody up by the identifier your systems already use rather than by ours.
Addresses that are real
Typeahead lookup against a provider, with a manual fallback for new builds, rural addresses and renamed streets. A manual entry is valid but is not marked verified, so the distinction survives.
Preferences by purpose and channel
Someone can accept service updates by email while declining marketing by SMS. A missing preference is treated as different from a declined one — 'never asked' is not 'said no'.
Consent history
Append-only events recording previous and new status, purpose, channel, mechanism, policy version, actor, timestamp, address and user agent. Only real changes are recorded.
Sign-in methods
Multi-provider and self-service — Google, Microsoft, username and password. A person can never remove their last method, so they cannot lock themselves out.
Devices and sessions
Sessions are server-side and individually revocable. People can see every signed-in device and sign one out or all of them; changing a password ends every other session.
Keyed on the person, not the email address.
Authorisation is keyed on a person identifier rather than on an address, which sounds like a detail until somebody changes their email. Every permission check is recorded against the person, so it survives the change instead of quietly detaching.
The same logic runs underneath tenant scoping. Identity lookup keys are tenant-scoped, so two tenants can both have a customer whose application username is 'jsmith' without either of them ever colliding or seeing the other.
- Erasure and export are scoped to your tenancy — another tenant's record of the same person is untouched
- The underlying shared record is deleted only once the last tenant erases
- One-time setup links let staff onboard somebody without a password: single-use, 256-bit, seven-day default expiry
- Single-use is enforced by a database transaction rather than by application logic
From first contact to consent evidence.
- Create the personBy hand on screen, through the API, or by a trusted server-to-server handoff from your own site. Create, fetch and upsert are all available, including fetch by your own application username.
- Capture the preferencePer purpose and per channel, on screen or in the customer's own portal. The change appends an event; a page save that changed nothing does not.
- Confirm itThe person receives an email confirming any preference change, so a change they did not make is noticeable to them rather than invisible.
- Prove it laterThe consent history is retrievable through the API, on screen, and by the data subject themselves — and it survives erasure, because it is your evidence of lawful processing and holds no name or contact detail.
Facts a technical evaluator will ask for.
Questions about the record
Can I look somebody up by my own customer number?
Yes. As well as the platform UUID, a profile can be fetched by the application username your own systems use, and that key is scoped to your tenancy so it cannot collide with another tenant's.
What happens to preferences when somebody is erased?
The contact details, preferences, identifiers, credentials and access entries for your tenancy are removed, your sessions for them are revoked and any outstanding setup links are invalidated. The consent history is deliberately kept: it contains no name or contact detail, only the UUID, and it is your evidence that processing was lawful while it happened.
Is there an alternative to erasure?
Yes — pseudonymisation replaces identifying values with a stable token while leaving consent and preference records provable. It is deliberately not presented as equivalent to erasure: because the salt exists, you retain the ability to re-identify, so on a strict reading it may still be personal data. The interface labels the two differently. Tokens are salted per tenant so two tenants cannot correlate pseudonymised records between them.
How are addresses validated?
Through a provider-backed suggest and retrieve API with normalised fields, so you can change provider without changing your integration. Anything the provider cannot find can still be entered by hand — it is valid, it just is not marked verified.
Related capabilities
Half an hour against your own fields and your own consent purposes tells you more than any feature list.