Data isolation and security
This page explains how QA Sync protects your organisation’s data. It’s written for admins, security reviewers and anyone answering a customer questionnaire. Engineers can find implementation details in Database and Row Level Security.
Isolation between organisations
Section titled “Isolation between organisations”Every record in QA Sync belongs to one organisation. PostgreSQL Row Level Security (RLS) policies on every table check that the signed-in member belongs to the record’s organisation before any read or write. The check runs inside the database, so it applies to every screen and every request, not just the ones the interface shows.
A member of two organisations sees only the organisation currently selected.
Access inside an organisation
Section titled “Access inside an organisation”Within your organisation, access is narrowed further:
- Membership status. Inactive members are signed in but blocked from every workspace.
- Role. Each role can perform only its own actions. For example, only Admins can manage members or promote releases, and only Testers and Admins can submit QA results. See the Permissions matrix.
- App access. Everyone except Admins sees only the apps they’ve been granted.
- Assignment. Developers see the tasks assigned to them; Testers see staging tasks assigned to their groups.
Sensitive actions, such as reviewing a task request, submitting a QA result, deciding an approval or promoting a release, run as server-side database functions that re-check the caller’s role, status and access before doing anything.
Accounts and sign-in
Section titled “Accounts and sign-in”- No public sign-up. Organisations are provisioned by QA Sync, and members are added by their organisation’s admins.
- Email and password authentication through Supabase Auth.
- Authentication and authorisation are separate. A valid password only proves identity; access comes from an active membership with a role.
- Inactive members stay blocked in the app even though they can authenticate.
Evidence and attachments
Section titled “Evidence and attachments”Screenshots, recordings and other evidence are stored in private storage buckets:
| Bucket | Holds |
|---|---|
qa-evidence |
Screenshots uploaded to QA runs |
task-request-attachments |
Screenshots and screen recordings attached to task requests |
feedback-attachments |
Screenshots attached to feedback submissions |
Files are never public. The app shows them through short-lived signed URLs, issued only to members allowed to see the related record.
Audit trail
Section titled “Audit trail”Privileged and workflow changes are written to an immutable audit log: access changes, create/update/delete of apps, groups, modules, submodules and tasks, task-request outcomes, developer status and note changes, approvals, QA results and comments. Audit entries can’t be edited. Admins can delete only entries older than a minimum age (at least one month), and each bulk clean-up records its own audit event. See Audit log.
In the browser
Section titled “In the browser”QA Sync is a single-page web app. The browser holds only public configuration (the Supabase project URL and its public anon key). Service-role keys are never shipped to the browser. Tester device defaults are stored in the tester’s own browser, not on the server.
What QA Sync doesn’t do
Section titled “What QA Sync doesn’t do”QA Sync has no public API, no third-party integrations and no outbound webhooks, so your data doesn’t leave the platform through those routes. Notifications are delivered in the app only.