How roles and permissions work in Staffintra

Concept · Audience: everyone

The real role hierarchy, custom roles, and how an "admin" is not always the same kind of admin.

What this does

Explains the actual permission model, since it is more layered than a simple "Owner/Admin/Staff" split.

Who can do this

This article applies to everyone — understanding roles helps you know why you can or cannot see something.

What happens next

There are five system-level roles: Platform Superadmin and Platform Admin (Staffintra's own platform operators — not part of any one workspace), and Tenant Owner, Tenant Admin, and Tenant User (the three roles that exist within your workspace).

A Tenant Owner sees and can do everything in the workspace with no restrictions — this cannot be limited. A Tenant Admin has broad access by default but can have specific permissions removed via a custom role. A Tenant User only has the specific permissions granted to their role.

On top of these three, your workspace can create custom roles — a named role built by adding or removing individual permissions on top of one of the base roles (for example, a "Recruiter" role based on Tenant User with a few extra permissions added). There is also a department-local role (Department Admin / Team Lead) that grants limited management authority scoped to just that department. Permissions can also be granted directly to one person or one department, separately from their role, for narrow exceptions.

Important notes

• Editing roles and permissions (Access > Roles) is restricted to the Tenant Owner — a Tenant Admin cannot grant themselves or others more access, even though they can do almost everything else.

• A platform admin (Staffintra's own staff) can access any workspace for support purposes — this is separate from, and not limited by, your workspace's own role setup.

• If a feature seems missing, it is almost always a permission your role doesn't have, not a bug — ask your workspace administrator.