Users, roles and permissions

The permission model

orboto uses fine-grained, permission-based access control. Every sensitive action is gated by a permission slug like ticket:edit, milestone:view_private or admin:users:write. Permissions are bundled into roles; roles are granted either per project (project membership) or globally (for admin areas).

• A super-admin global role passes every check - reserve it for very few people.
• Admin permissions are deliberately narrow (admin:backup:read, admin:webhooks:write, ...) so you can delegate one area without handing over the whole admin panel.
• Destructive rights are separate slugs from edit rights (for example ticket:delete is not implied by ticket:edit), so "can change" never silently means "can destroy".
• What a user cannot do, they also do not see - navigation entries and buttons are hidden along with the permission.

Managing roles

Admin → Roles lists every role with its permission count. Click a role to expand its permission matrix, grouped by family (ticket, comment, time, users, admin, ...). Toggle a single permission, or use Grant all / Revoke all on a family header - changes save immediately.

New role opens a form with:

• Name and Scope - Global (available everywhere) or Workspace (all projects in this workspace).
• Start from preset - backup-operator, auditor, dsgvo-operator, developer and reporter pre-check a sensible slug set you can adjust before saving.
• The same searchable permission matrix as the edit view.

Permissions carry small badges where relevant: destructive (an irreversible action) and deprecated (kept for older integrations, not recommended for new roles).

Pick which role templates auto-seed into every new project from the Default templates for new projects panel above the role list.

Creating users

Admin → Users → New user offers two modes:

• Invite by email (default) - enter a name and email, pick an invite scope (whole workspace with a global role, a single project with a project role, or a single customer with a customer role), and send. The invitee sets their own password on first sign-in. Re-inviting an email that already has a pending invitation surfaces that invitation instead of creating a duplicate.
• Create directly - you set the password yourself (or generate a random one and copy it), with an option to email the credentials. Use this for bot accounts or when email delivery is unreliable.

If the invitation email can't be delivered, the dialog stays open and shows the invite link directly so you can copy-paste it - resend it any time from the Pending invitations tab.

Bot accounts

Bots are service identities for agents and integrations: they cannot sign in with a password, they authenticate only via API keys minted for them, and each bot has a responsible human owner. Give every agent, integration and automation its own bot - presence, audit trails and rate limits stay attributable, and revoking one integration never breaks another. Bots can also be paused: a paused bot stops picking up work on its own while explicitly assigned tasks keep working (see Agents & AI).

Bulk-creating or updating many accounts at once (from a spreadsheet or another system)? See Bulk user management.

Editing a user

Open a row to edit across tabs:

• Details - avatar, name, email, hourly rate, an optional overhead factor override, and the GitHub username used for webhook attribution and assignee sync. Bot rows additionally show the responsible owner and an autonomy-pause switch. MCP (AI client) access is shown read-only here
  • the user controls that toggle from their own profile.
• Schedule - working days, hours and week start.
• Access - global roles (checkboxes) and project memberships, editable inline without leaving the dialog.
• Features - per-user overrides for surfaces that default by account type (work schedule, out-of-office delegation, time calendar): inherit the role default, or force show/hide.
• Vacation / Sick leave - balances and, for sick leave, who gets notified when this person reports sick.
• Security - reset the password: send a reset link, or set one directly (optionally emailing it).
• API keys - mint, rotate or delete keys on this user's behalf, including bot agent profiles. See API keys.

Sessions

Admin → Sessions lists every active sign-in workspace-wide - user, device, IP address, last activity and expiry - searchable by name or email. Revoke a session after a suspected compromise; it takes effect immediately. There's no single "revoke all" button - after a compromise, search by the user's name and revoke each of their rows.

Data protection

Per user, administrators with the corresponding rights can:

• Export all personal data as a downloadable JSON file (admin:dsgvo:export).
• Anonymize an account - scrubs personal data but keeps the row (and their tickets, comments and audit trail) in place, attributed to an anonymous author (admin:dsgvo:anonymize). You must type ANONYMIZE to confirm. You can't anonymize your own account, and an account under legal hold can't be anonymized until the hold is lifted.

Both actions are audit-logged.

Deactivate, reactivate, or delete

Deactivating blocks sign-in immediately; reactivating restores it. Hard delete (typing delete <email> to confirm) permanently removes the account - sessions, comments, time entries, assignments and memberships are wiped, while tickets they created, audit-log entries and attachments stay with an anonymous author. Prefer Anonymize when you want the workspace history intact but the person's data gone.

Revoking AI-client access

Separately from API keys, an admin can revoke all of a user's MCP (AI client) OAuth grants and clear their MCP sessions - their AI clients (Claude Desktop, Cursor, ...) must then re-authorize. Use this alongside deactivation and session/API-key revocation when someone leaves.

Troubleshooting

Deactivated a user, but their integration still works. Deactivation alone doesn't revoke sessions, API keys, or MCP grants - it blocks new sign-ins. Also revoke their sessions (Admin → Sessions), delete their API keys (the user's API keys tab), and revoke MCP grants if they used AI clients.

A permission checkbox change didn't seem to apply. The role editor saves each toggle immediately - refresh if the UI looks stale. Users with that role need to sign out and back in only if their session carries stale claims; most permission checks are read live from the database.

Invited someone and nothing arrived. Check the Pending invitations tab first - if the invite exists, resend it or copy its link directly instead of creating a new one (a duplicate invite for the same email surfaces the existing one rather than sending twice).

Can't anonymize an account. Either it's your own account (not allowed), or it's under legal hold - check Admin → Compliance for active holds before anonymizing.