Roles and permissions
Administration · 6 min read · Last updated: August 6, 2026
The four built-in roles, what each one can do, and how to invite members and pick the right role for them.
Every person in your organization holds a role, and the role decides what they can do. This guide is for whoever sets that up, usually the org admin.
The four built-in roles
Every new organization starts with these, and they cover most teams without any changes.
| Role | Who it is for |
|---|---|
| Org Admin | Full access to everything, including billing and roles. |
| Manager | Runs day-to-day work: assign and edit any ticket, manage the team, boards and tags. |
| Agent | Handles tickets day to day: create tickets, edit the ones assigned to them, comment. |
| Member | Submits tickets and sees their own. The right default for requesters. |
The distinction that matters most is between Agent and Member. An agent sees every ticket in the organization and works them. A member only sees the tickets they raised or are assigned. If you're onboarding a department that raises requests but doesn't fulfil them, give them Member.
What roles actually control
A role is a list of permissions. The ones that matter most in practice:
- Seeing tickets, whether that's every ticket in the organization or just your own.
- Editing tickets, any of them or only the ones assigned to you.
- Managing the team: inviting members, changing their roles, deactivating them.
- Managing the workspace: boards, statuses, tags, templates and automations.
- Billing: changing the plan and payment details. Org Admin only.
- Reports and the audit log, for visibility into how the organization is working.
Permissions are enforced on the server, not just hidden in the interface. A role is a real boundary, not a cosmetic one.
Inviting people
Invite from the Organization page with an email address and a role. The person gets an email, sets a password, and lands in your workspace with exactly the access their role allows.
You can invite someone who already has a LitosFlow login too. One login can belong to several organizations, and people switch between them from the organization name at the top of the sidebar.
The rule about assigning roles
You can only assign roles below your own level. A manager can make someone an agent or a member, but can't create another manager or an org admin. Org admins are exempt and can assign anything.
This rule applies everywhere a role gets set, including invitations, so there's no way around it. It exists so that delegating team management never quietly hands over the whole workspace.
Custom roles
If the four built-in roles don't fit, org admins can create more from the Organization page by choosing the permissions and the level. A custom role sits in the same hierarchy as the built-in ones, so the rule above still applies.
Start from the closest built-in role and adjust it rather than building from nothing. It's easier to reason about now, and easier for the next admin to understand later.
Removing people
Deactivate a member rather than deleting them. Deactivating removes their access right away but keeps their name on the tickets they raised and the comments they wrote, so your history stays readable. Deleting them would leave holes in that record.
Deactivated members can be reactivated later if they come back.