Roles and permissions
Every member of an organisation has exactly one role in that organisation. The role decides which workspace they land in and what they can change. App access and tester groups then narrow what they see.
For the full role-by-capability table, see the Permissions matrix.
The roles
Section titled “The roles”Admins run the organisation. They:
- add, edit, revoke, restore and delete members;
- create and manage apps, tester groups, modules, submodules and tasks, including bulk import;
- move any task to any workflow stage except Production, on the Kanban board or in the task editor;
- review task requests (publish, merge, mark reviewed, reject);
- view all QA runs and feedback history;
- manage approval rules, decide any approval, and promote releases to Production (with an override reason if the release isn’t ready);
- read and clean up the audit log;
- view every member’s notifications, not just their own.
Admins have access to every app in their organisation.
Product Manager
Section titled “Product Manager”Product managers work in the Product Release Workspace. They:
- see portfolio, roadmap and release analytics for their apps;
- review release candidates, readiness and approval history;
- complete Product Manager Approved approvals on items that are Ready to Ship or in Production;
- comment on release candidates.
They can’t promote releases; an admin does that once approvals are clear.
Developer
Section titled “Developer”Developers work in the Developer Workspace. They:
- see tasks assigned to them, within their apps;
- move their tasks through the delivery stages: Backlog → Planned → In Progress → In Review → Staging, and back from Staging or In Review to In Progress;
- triage issue reports on their tasks: update the issue status and add internal notes;
- escalate a tester’s suggestion to admins as a task request.
Developers don’t reassign work; assignment belongs to admins. Developers can’t approve their own task’s release unless an approval rule explicitly allows self-approval.
Tester
Section titled “Tester”Testers work in the Tester workspace. They:
- see tasks in Staging that are assigned to one of their tester groups, within their apps;
- start QA runs and record results (Passed, Failed or Blocked) with severity, notes, reproduction steps, screenshots and video links;
- request missing test coverage with task requests, including screenshot and screen-recording evidence;
- keep device defaults that pre-fill their forms.
UI Designer and Client
Section titled “UI Designer and Client”UI Designers (Design Review Workspace) and Clients (Client Progress Workspace) see portfolio, release readiness and roadmap progress for their apps, read status history and activity on release candidates, and can leave comments. They can’t change delivery state or decide approvals.
Viewer
Section titled “Viewer”Viewers (Progress Workspace) see the same portfolio, release and progress views as UI Designers and Clients. The workspace is intended to be read-only.
How app access narrows what you see
Section titled “How app access narrows what you see”| Role | Apps visible |
|---|---|
| Admin | All apps in the organisation. |
| Every other role | Only apps an admin has granted. No apps means an empty workspace. |
App access applies everywhere: tasks, modules, QA runs, task requests, comments, analytics and approvals.
How tester groups narrow a tester’s queue
Section titled “How tester groups narrow a tester’s queue”Each tester group belongs to one app. A task is assigned to one or more groups. A tester sees a task in their queue only when:
- the task is in Staging, and
- at least one of the task’s groups is one of the tester’s groups, and
- the tester has access to the task’s app.
Super Admin (platform operators)
Section titled “Super Admin (platform operators)”Super Admin is not an organisation role. It is held by QA Sync staff who review access requests and provision organisations. Platform operators don’t have standing access to your organisation’s data and don’t take part in its day-to-day work. Organisation admins can’t grant Super Admin.
See Organisations and tenancy.
Where permissions are enforced
Section titled “Where permissions are enforced”Permissions are enforced by the database, not just hidden in the interface. Even if someone crafted a request by hand, Row Level Security and server-side checks would refuse anything their role doesn’t allow. See Data isolation and security.