Roles and permissions

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. They're listed most senior first.

Each role includes everything the one below it can do, so promoting someone never takes anything away.

The distinction that matters most is between Agent and Member. Both see every ticket in the organization. An agent works what lands on them; a member picks up anything and shapes how the work is organized — boards, tags, templates, automations. Start people as agents and promote the ones who take ownership of the workspace.

The second one to know is Member versus Manager. A member is senior on the work but can't invite people, change anyone's role, or read the audit log. Reach for it before making someone a manager, which is really about running people rather than running the work.

Everyone in the organization can see every ticket. If you need a group who only ever see what they raised themselves — a department that files requests but doesn't fulfil them — that's a custom role, below.

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. This is where a requester role goes: permissions for seeing your own tickets and creating them, and nothing else.

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.