Isolation at database level
Every business table carries the agency identifier and a row-level security policy. With no agency set, a query sees no rows at all — this is not an application filter someone can forget to write.
Security and data
Isolation is not an intention stated on a web page: it is enforced in the database, underneath the code, at the level where even a programming mistake cannot get around it.
Every business table carries the agency identifier and a row-level security policy. With no agency set, a query sees no rows at all — this is not an application filter someone can forget to write.
The API is the only process that talks to the database. No client — not the browser, not a mobile app — has direct access to the data. A compromised client does not open the database.
The application's servers are in Germany and media storage sits in European jurisdiction. Your photos and your conversations don't cross the Atlantic to be filed away.
Every incoming payload — a third-party response, a network notification, an uploaded file, a query parameter — is validated before it exists in the code. What fails is logged as-is, then rejected.
Roles and permissions are set per action, not by broad tier. An external colleague can consult a record without seeing revenue: statistics are the only screen closed on read, because the screen is the sensitive data.
A portal feed, a booking page, a public media file: each goes through a signed address, and booking links are time-limited. A link left lying in a mailbox does not open your portfolio.
Ask it in the meeting, or in writing — including to your data protection officer.
Twenty minutes over video, on your properties. No commitment, nothing to install.