Roles and permissions

A role is a named bundle of permissions you assign to a team member on a property. The system ships eight built-in roles that cover most teams, and you can edit them or create your own. This page explains how access works, what every built-in role can do out of the box, and how to set up your team with confidence. For what each individual permission controls, see the permissions reference.

How access works

There are two layers:

1. Workspace admin: when you invite a member you choose whether they're a workspace Admin or a regular Member. Workspace admins see and can do everything in the workspace, on every property, regardless of roles. This is the unconditional level. Use it sparingly.
2. Property roles: regular members are assigned to specific properties, and each assignment carries one or more roles. A member only sees the properties they're assigned to, with the access their roles grant there.

A role is simply a set of permissions. When a member holds several roles on a property, they get the union of all of them. The special permission full_access (held by the built-in Admin role) is an override that passes every check.

Three more rules worth knowing:

• Manage usually implies view. Anyone who can record payments can also see the Payments page, so you rarely need to tick both. view_financials opens every money page in one go.
• Same rules on mobile. The mobile app enforces these roles and permissions identically: it hides tabs, menus, and buttons a member can't use (checking per property), and shows an "Access denied" message for anything they reach but aren't allowed to open. A role change on the web applies to their mobile app too.
• Approvals follow workflows, not permissions. Verification and approval steps (payments, expenses, deposits, maintenance review, lease sign-off) are configured in workflows, and each step is assigned to a role. To act on a step, a member must hold that step's role on that property. So if your custom "Finance Lead" role should approve expenses, assign it to the expense workflow's gate step. Ticking extra permission boxes won't do it.

The built-in roles

The default workflows are built around these roles: for example the maintenance default runs Operator (does the work) → Property Manager (reviews) → Accountant (confirms the cost). If you rename roles or build custom ones, the workflow editor lets you point each step at whichever role should act.

Picking a role: three common shapes

• Solo manager: do nothing. As workspace admin you already have full access; roles only matter once you invite people.
• Small team (2 to 4 people): invite your bookkeeper as Accountant and your field tech as Operator, assigning each only to the properties they work on. Keep approvals with yourself (admin passes every workflow gate).
• Full team: add Property Manager per property, a General Manager across all properties, and a Treasurer for payment sign-off. The default workflows already route through these roles, so approvals start flowing with no workflow editing.

And the most useful rule of thumb: when someone needs access to one specific property, don't make them a workspace admin. Assign them a role on that property only. They'll see that property and nothing else.

Rank (seniority)

Each role carries a rank from 0 to 100. It expresses seniority: Admin 100, General Manager 80, the working manager roles 60, Operator 30, Shareholder 10.

Rank is a label for your own reference. It does not decide what anyone may do: every gate in the system reads permissions, never seniority. A custom role holding the right boxes works exactly like the built-in role holding the same boxes, whatever rank you give it. Set it near the built-in role it most resembles so your team reads the list easily, and grant the permissions themselves in the boxes below.

Custom roles

Open Settings → Configuration → Roles. You can edit any built-in role except Admin, or create a new one: just give it a name (English and/or Arabic, you don't have to fill both), set a rank and color, tick its permissions, and save. There's no "key" to invent: the system generates a unique internal identifier for you, and role names never clash between workspaces. Custom roles appear everywhere built-in roles do, member assignment and workflow step assignment included.

Each permission in the editor shows what it does, and the ones that behave differently from what their name suggests are labelled. Use the search box to find a permission by name or by description, and "Selected only" to review what a role already has.

Permission changes can take a few minutes to reach members who are already signed in.

Roles and invitations

When you invite somebody from a property's Members panel, the role you pick travels with the invitation and is applied the moment they accept. Nothing is granted before that, so they will not appear in the members list until they do.

If you tidy up your roles while an invitation is still outstanding, and the role it named is archived before the person accepts, that property is skipped rather than granted with no role at all. They still join the workspace, and you can give them access afterwards.

Inviting somebody to a property needs "Manage who works on a property", which workspace admins always have. Inviting somebody to the workspace is limited to workspace admins.

That is the general rule: what belongs to one property you grant with a permission in a role, and what belongs to the whole workspace is limited to its admins. So adding a new property, changing workspace settings, and editing roles and approval workflows are all for workspace admins, and none of them is granted by a box in the role editor.

What the permission groups control

The role editor groups permissions the same way this table does. For the full list of what each box does, open the permissions reference.

Related

• Permissions reference
• Workspaces
• Workflows and approvals
• Money
• Odoo accounting integration
• Getting started