Team & Roles
Open Team & billing to see who is in the workspace, what they can do and who is online. On a wide screen (1280 px and up) the page also shows your plan, usage and latest invoices next to the team; on smaller screens they are on the Billing tab. Plan changes, the payment method and add-ons are always on Billing.
Roles
| Role | Can |
|---|---|
| Owner | Everything, including deleting the workspace and granting the Owner role |
| Admin | Everything except deleting the workspace and granting or changing the Owner role |
| Manager | Run the fleet (commands, deployments, alerts, app migrations); work on the project board; read billing and settings |
| Viewer | Read-only access to the fleet, billing, support, settings, compliance reports and the project board |
| Teacher | School workspaces: manage their own device groups; read the project board |
Roles are per workspace. The same person can be an Owner in one workspace and a Viewer in another.
Workspace configuration is for owners and admins: governance policies, MSP clients, their branding and catalogues, SSO clients and connectors (including reading an SSO client’s secret), SCIM and login domains, and the cluster-autoscale provider token. Managers see these settings but can’t change them; they can resolve policy violations and decommission autoscaled nodes. Submitting an autoscale job creates billable VMs, so it needs an owner or admin as well. Viewers can read but never change any of it.
Permission by area
| Area | Owner | Admin | Manager | Viewer | Teacher |
|---|---|---|---|---|---|
| Fleet: read nodes, app migrations, GitOps status and conflicts | ✓ | ✓ | ✓ | ✓ | — |
| Fleet: commands, deployments, start / drive app migrations, resolve GitOps conflicts | ✓ | ✓ | ✓ | — | — |
| Node terminal: open a shell, list and replay recorded sessions | ✓ | ✓ | — | — | — |
Project board (/api/tickets: projects, sprints, milestones, tickets, comments): read | ✓ | ✓ | ✓ | ✓ | ✓ |
| Project board: create, edit, move, comment, delete | ✓ | ✓ | ✓ | — | — |
| Compliance reports: templates, history, downloads | ✓ | ✓ | ✓ | ✓ | — |
| Compliance reports: generate | ✓ | ✓ | — | — | — |
| Mobile push: send a test push, rebind or mute a paired device | ✓ | ✓ | — | — | — |
| Workspace settings (2FA, terminal recording, agent auto-update), member roles | ✓ | ✓ | — | — | — |
Server-side these are the permissions fleet:read / fleet:write, fleet:shell, tickets:read / tickets:write, settings:read / settings:write and users:manage (see Control Panel API).
Platform staff
Quazzar staff manage customer workspaces from the admin console, where every change is audited under the staff session policy. Signed in with their own account (not impersonating), staff can read a workspace’s fleet and settings through the workspace API, but changing the workspace settings or a member’s role there is refused with 403 {"code": "staff_use_admin_console"} unless they are themselves an owner or admin of that workspace. A staff impersonation session acts as the workspace owner (and still can’t open a node shell).
AI chat conversations in the Control Center are private: each member sees only their own, and admins can’t open another member’s conversation or act on the bulk-action proposals made in it.
Changing a role
Owners and admins change a member’s role by clicking the role chip on the member’s row and picking the new role. Roles you can’t grant are greyed out with the reason.
- Only an Owner can make someone an Owner, or change another Owner’s role.
- A workspace always keeps at least one Owner. To step down as the last Owner, make someone else an Owner first.
- Every change is written to the audit log (
team.role_change, with the old and new role).
The member’s new permissions apply within 15 minutes, or at once after they reload the Control Center.
Inviting people
Click Invite, enter one or more email addresses (comma-separated) and pick a role: Admin, Manager or Viewer. Addresses that are already members or already invited are listed as skipped. Pending invitations are listed under the team, each with a revoke button. Invitations expire after 7 days. If the person already has a Quazzar account, accepting adds this workspace to their account.
Online, idle and offline
Each member shows a presence dot and when they were last seen:
| Status | Meaning |
|---|---|
| Online | Active in the Control Center within the last 90 seconds |
| Idle | Seen within the last 15 minutes |
| Offline | Not seen for 15 minutes or more |
“Last seen” is the latest of their activity in the Control Center and their last sign-in to this workspace.
API
| Method | Path | Description |
|---|---|---|
GET | /api/team/members | Members with role, last_seen_at and presence |
PUT | /api/team/members/{id}/role | Change a member’s role (owners and admins of this workspace; platform staff get 403 staff_use_admin_console) |
POST | /api/invitations | Invite one email |
POST | /api/invitations/bulk | Invite several emails |
GET | /api/presence | Online users and every member’s presence |
POST | /api/presence/heartbeat | Report activity (the web app calls it every 30 seconds) |
See the Control Panel API for request and response bodies.