Roles and permissions
Owner, admin, member and guest; how project and channel scopes restrict access, the order in which rules are resolved and what each role can see.
In Axuz, what you can see and do depends on four layers, evaluated from the broadest to the narrowest. The narrowest rule always wins: a lower layer can restrict, never widen, what a higher layer granted. Every decision is made on the server; hiding a button on screen is not what protects the data.
The four team roles
| Role | What it can do |
|---|---|
| Owner | Full control: billing, deleting the workspace, promoting admins and overriding any scope. |
| Admin | Manage users, projects, integrations and moderation. Cannot change billing or delete the workspace. |
| Member | Creates channels, tasks and timelines in their projects and takes part in the channels they can access. Cannot change roles or join projects they are not part of. |
| Guest | Read-only by default. To do more, a guest gets explicit scopes (chat, tasks, files, wiki) per project. |
These four roles are built in and cannot be edited. Business plans allow custom roles under Company admin > Custom roles, with tailored permissions (read timelines, publish, write tasks, view payables and so on). Deleting a custom role removes the permissions of whoever had it.
Resolution order
- Company role. Owners and admins of the company have access to its teams.
- Team role. Owners and admins of the team override project and channel scope: they administer any channel of the team, even without being a member of it.
- Project scope. If a person has a scope set on the project, it restricts the modules available inside. With no scope set, the project is open to the team.
- Channel scope. Inside the channel, the member’s scope restricts even further. Someone who is not a member of a channel only gets in if the channel is public; a private channel answers “not a member of this channel”.
The modules a scope can unlock are Chat, Tasks, Files and Wiki. An empty scope means full access. In practice a guest with a Tasks-only scope opens the channel’s Tasks tab but is refused when trying to open Chat.
Private and public channels
A channel created through the interface is born private. The person who created it, people who were invited and the team’s owners and admins can open it; other team members cannot even enter. To grant access, open the channel and click Invite, generate the link and pick the scope: Full access (chat, tasks, files, wiki) or only some modules. Redeeming an invitation also makes the person a team member, so issuing invitations is an administrative act: only team owners and admins, the channel’s creator and people with the admin or moderator role in the channel can do it. Regular members cannot.
Changing the channel’s visibility, renaming, moving to another project or archiving (Channel settings) is also restricted to that group.
Project scope
Project scope limits a member to certain modules inside a project. The path available today is the Add client wizard, under Company admin > Access control: enter the e-mail, choose the project and tick Full access or specific modules. The person must already be a team member — invite them first. The Access by project table on the same screen shows each project’s members and dominant scope.
What each role sees
- Owner and admin: the whole workspace, including Company admin (users, invitations, projects, roles, moderation, audit, privacy, session policy, trash, imports). Billing belongs to the owner alone.
- Member: the channels and projects they can access, the team’s timelines, the Members list in read-only mode and their own settings.
- Guest: only what a scope or invitation unlocked; with neither, little or nothing.
Invitations follow the rules: only an owner invites another owner or admin, and an invitation is valid only for the e-mail it was sent to. Under Session policy, administrators set the idle time before sign-out, the maximum simultaneous sessions and whether admins and owners need 2FA. See also Account security and First steps.