Security
Your customers’ data, kept apart.
What stops one business seeing another’s, who inside your own group can see what, and how to reach us if you find a problem.
Isolation and access
Separation that does not depend on remembering to filter.
Separation is enforced in the database, not in the application
Row-level security is enabled on the tables that hold business and customer data, with policies that scope every read and write to the organisation it belongs to. A query that forgets to filter returns nothing rather than someone else's rows.
Each location is its own boundary
Within a group, a location's customers, conversations, services and diary belong to that location. Working across branches is a separate, explicit scope rather than the default.
Scope is resolved on the server and can only narrow
The browser may express a preference for which branches to work across. It may not supply the list. The server resolves that preference against actual memberships, so a tampered cookie or a crafted URL can only ever show someone less than they already had.
Permission is per person, per action, per branch
Someone covering another branch can read its work and reply to its customers without being able to write off its opportunities. One role applied everywhere would get that person wrong the moment they covered a shift.
Data handling
What is held, what is reachable, and by whom.
Connected calendars
When a practitioner connects a calendar, the access token is encrypted at rest and can be revoked at any time from the product. Revoking it stops Clinqly reading or writing that calendar immediately.
Shared links are not search results
Booking pages, showroom shares and management links are reachable with their token and carry a noindex directive, so a link that leaks through a referrer does not become a search result. They stay crawlable on purpose: blocking the crawl would stop a crawler reading the directive that removes them.
Approved information only
The receptionist answers from the published version of each knowledge source. Unpublished or draft content is not reachable by it, so an internal note cannot be repeated to a customer.
Who processes what
Hosting, payments, email and the messaging platforms each see a defined part of the service. They are named individually, with what each one does, in the privacy policy.
Straight answers
What we do not claim.
Clinqly holds no security certification and has not completed a third-party audit. There is no published uptime commitment and no data-residency guarantee. If your organisation needs any of those, ask before you go live and we will tell you where things actually stand rather than point you at a badge.
Security questions, or something you think we have got wrong: hello@clinqly.io. Tell us what you found and how to reproduce it, and please give us a chance to fix it before publishing.
Can another Clinqly business see my customers?
No. Access is scoped to your organisation in the database itself, so a query that failed to filter returns nothing rather than another business’s rows.
Can staff at one of my locations see another location's customers?
Only if you have given them a membership at that location. Working across branches is a deliberate scope, and the server resolves it against real memberships rather than trusting the browser.
Do you have a DPA?
Our data-processing terms are being finalised and are subject to legal review. If your organisation requires one, talk to us before going live and we will work through your requirements directly.
Where do I find who processes our data?
The privacy policy names each subprocessor and what it does. Security describes how access is controlled; privacy describes what is collected and why.