Roles & Permissions

Owner

The Owner is the workspace creator. In QONE, an Owner membership always resolves to the full Admin permission set. This is a safety net: even if an Owner picks up a restrictive role, they keep full control of the workspace so they can never accidentally lock themselves out.

The Six System Roles

Every workspace is seeded with these roles in this order:

| Role | Typical scope | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Admin | Full access to every module — users, finance, HR, projects, settings, permissions. | | Finance Manager | Full finance: payments, expenses, invoices, estimates, items, and customers. Read-only on employees (no salary), and financial reports. No payroll, leave, or project management. | | HR Manager | Full HR: employees, departments, payroll, payslips, attendance, and leave approvals. Views Tempo for attendance. No finance. | | Project Manager | Full projects and Tempo (all three tiers), reads employees (no salary), sees leave for planning. No finance or payroll. | | Member | The default role for new users. Self-serve project create and "own your project" actions (create tasks, log time, manage own project members), comment, and view their own expenses, payslips, attendance, and leave. | | Guest | Limited, mostly read-only access for external collaborators — view assigned tasks, change task status, and comment. No HR, finance, or settings. |

Note: Internally the Member role is stored as USER; you will see it labeled Member throughout the interface.

Custom Roles and the Base-Role Ceiling

When you create a custom role you pick one of six base roles — Admin, Finance Manager, HR Manager, Project Manager, Member, or Guest. The new role starts as a copy of that base role's permissions.

The base role is also a hard ceiling. When permissions are resolved, a custom role's permission is granted only if both the custom role and its base role allow it. So a custom role based on Member can never gain invoice-approval rights, no matter what you toggle — Member doesn't have that permission, so the ceiling blocks it. Choose the base role to match the highest level of access the custom role should ever reach.

---

Create a Custom Role

1. Go to Settings > Roles.
2. Click Add Role.
3. Enter a Name (e.g. "Senior Developer") and an optional Description.
4. Select a Base Role — this sets the permission ceiling and the role's default dashboard:
   • Admin — full access.
   • Finance Manager — finance modules.
   • HR Manager — HR modules.
   • Project Manager — project and Tempo modules.
   • Member — standard self-serve access.
   • Guest — limited, read-only access.
5. Pick a Color for visual identification in lists and badges.
6. Click Save. The new role inherits its base role's permissions, which you can then trim in Settings > Permissions.

[Screenshot: Add Role modal with name, base role dropdown, and color picker]

Edit, Deactivate, or Delete a Role

1. On the Settings > Roles list, system roles are marked with a lock icon; custom roles show their base role and member count.
2. Click Edit to change a custom role's name, description, or color. System role names cannot be changed.
3. Toggle a role Inactive to stop it being assigned to new users. Existing assignments are unaffected.
4. Click Delete to remove a custom role. A role that is currently assigned to one or more users cannot be deleted — reassign those users first. System roles can never be deleted.

---

Most access control happens at the role level, but you can override permissions for an individual user when one person needs a slightly different scope than their role provides.

1. Go to Settings > Users and open the user.
2. Switch to the Permissions tab. (This tab is only visible to admins or users who can manage permissions.)
3. Toggle the specific permissions for this user. These overrides are layered on top of the user's role permissions — they take precedence where they differ.
4. Save to apply. To return the user to plain role-based access, remove their overrides.

Permission changes made here are recorded in the workspace audit log, so there is a trail of who changed what.

Tip: Reach for per-user overrides sparingly. If several people need the same adjustment, create a custom role instead — it is far easier to maintain than a scatter of individual exceptions.

---

• Menus and pages: Loaders check permissions before returning data. A user who lacks canViewInvoices, for example, never sees the Invoices menu, and a direct link returns a Forbidden response.
• Actions: Buttons like Approve, Delete, or Send only appear — and only work — when the underlying permission is granted (e.g. attendanceLeave.canApproveLeaves, financial.canSendInvoice).
• Sensitive data: Salary and bank details are gated behind dedicated permissions (canViewUserSalaries, canViewUserSensitiveInfo), so a role can list users without seeing pay.
• Dashboards follow the base role: The dashboard a user lands on is derived from their role's base role — Admin, Finance, HR, Manager, Member, or Guest. A custom role inherits the dashboard of the base role it was built on.
• Permission resolution order: Owner and Admin memberships always resolve to full Admin access. Otherwise the user's assigned role (system or custom, with its base-role ceiling applied) sets the baseline, and any per-user overrides are merged on top.

Tempo's Three Tiers

The Tempo planner uses a layered model that fits inside the same permission system:

• Tier 1 — canViewTempo: View and manage your own schedule, log your own time.
• Tier 2 — canAssignTasksInTempo: Assign and move tasks for others in the same project.
• Tier 3 — canViewManagerView: Full manager view — Team Calendar, Reports, cross-project, and editing others' time entries.

Each tier implies the ones below it. See the Tempo article for details.

---