Roles and permissions

Every member of your company has a role. The role decides what they can see and do — in the company workspace, in the office, in calls and meetings, and in Company administration. Every company has five standard roles, and owners and admins can create custom roles with exactly the permissions a team needs. You choose a standard role when you invite someone and can change it later.

Roles are enforced by the server#

HyoNova checks permissions on the server for every request, not only in the interface. Hiding a button is never the protection: if someone tries an action their role does not allow, the server refuses it. When an area is not available to you, HyoNova shows "Not available for your role" and "Ask a company admin if you need access to this." A member who loses a permission loses it at once, on their next action.

The standard roles#

A company always has at least one owner. Standard roles cannot be edited or deleted.

Where you see roles#

• Settings → Access (every member). The Your access card shows your Role and how many Permissions you hold, with the note "Every action is authorised by the server; this page only shows the presets." The Roles card lists the five standard roles with a one-line description, and the Permission matrix shows each standard role against each area as Full, Read, Create, Update, Delete, Approve, Export or Admin. Custom roles do not appear here.
• Company administration → Access → Roles and Permissions (owners and admins). Standard and custom roles together, with the permissions each one carries. See Custom roles.

What each standard role can do#

✓ means the role can do it. — means it cannot.

People#

Owners can give any role; admins can give any role except Owner. See People and Invitations.

Company administration#

Billing pages are read-only for everyone today; plan changes are handled by HyoNova. See Admin, Audit and Billing and plans.

Work#

See Tasks.

Customers, finance and reports#

Managers and employees see the Customers area, but customer and deal records are confidential, so today they get "Not available for your role" when they open it. See Data clearance below.

Files#

See Files.

Communication#

Host controls apply when the person is the meeting's host or co-host. See Meetings.

Office (world)#

See World permissions.

Guests#

See Guests.

Data clearance#

Besides permissions, every record in HyoNova has a sensitivity level, and every role has a clearance — the most sensitive level it may open. A person needs both the permission for an action and enough clearance for the record.

This is why an admin, who can do almost everything, still cannot open invoices or payroll, and why the Customers area is not yet usable for managers and employees. In a custom role, clearance is two permissions in the Access group of the matrix.

Taking part in a chat or meeting only needs a colleague's name, so people with internal clearance can message and meet everyone without seeing their employee records.

Custom roles#

When no standard role fits — a team lead who should assign tasks but not see customers, or a marketing team that needs Mail — owners and admins create a custom role. Custom roles belong to your company only.

Create and manage custom roles#

Open Company administration → Access → Roles: "Standard roles and the roles your company created." Each role is tagged Standard or Custom and shows how many permissions and members it has, with its description. A role that carries permissions you do not hold is tagged Above your own role.

To rename a custom role or change its description, select Edit, change the fields and select Save (or Cancel). To remove it, select Delete. Delete stays unavailable while anyone holds the role — "This role is assigned to members and cannot be deleted." — so first give those members another role. To change what the role may do, use the permission matrix.

The permission matrix#

Open Company administration → Access → Permissions: "What each role may do. Standard roles are read-only; custom roles are editable."

The matrix has one table per group: Access, People, World, Builder, Chat, Meetings, Guests, Files, Projects & tasks, CRM & sales, Finance, Analytics, Company admin, Integrations and AI & automation. Each row is a role; standard roles are marked Standard role (read-only). Each column is one permission, shown by its technical name.

The change applies straight away to everyone who holds the role. A step-by-step example is in Configure roles and permissions.

Give a custom role to a member#

Custom roles are assigned in Company administration → People → Members, in the Change role column. They cannot be chosen in the invitation form or in the People page menu: invite the person with a standard role, then change it once they have joined. See People.

Rules that always apply#

• No escalation. Nobody can create, edit, delete or give a role that carries a permission they do not hold. The server refuses it even if the interface is bypassed.
• Standard roles are fixed. They cannot be edited or deleted; copy one with Start from instead.
• Plans still apply. A module your plan does not include stays unavailable, even when a role allows it.
• Changes are recorded. Creating, editing and deleting roles and changing a member's role appear in the audit log.

Show technical details

Permissions are keys in the form namespace.action. Roles are sets of these keys, stored and checked on the server; the product interface only adapts to them.

• Company namespaces: people, payroll, finance, crm, sales, projects, tasks, support, marketing, communications, files, automation, ai, integrations, analytics.
• Actions: read, create, update, delete, approve, export, admin. people.admin is member administration (invite, change role, remove). tasks.approve allows assigning tasks to others. Departments use people.create (add) and people.delete (archive).
• Communication capabilities: communications.meeting.join, .meeting.invite, .meeting.moderate, .meeting.record, .call.create, .screen.share, .guest.invite, .guest.admit, .recording.read, .recording.delete, .transcript.read, .transcript.create, .transcript.delete, .support.manage, .file.guest_grant. Company meeting settings need communications.admin.
• Office (world): world.join, world.invite (create guest links), world.manage_access (allow or stop guests), world.manage, world.room.enter, world.room.manage, world.interact, world.directory.read, world.presence.read.
• Guests: guests.read, guests.manage (approve, decline, end visits), guests.promote.
• Company administration: company.admin.read (open the area), company.settings.manage, roles.read, roles.manage, audit.read, billing.read, billing.manage.
• Clearance: company.confidential.read grants confidential clearance, company.restricted.read grants restricted clearance. Without either, clearance is internal.

Standard roles:

• Owner: every key.
• Admin: every key except payroll.*, company.restricted.read and billing.manage.
• Manager: read, create, update, export on projects, tasks, crm, sales, support and files; tasks.approve, support.approve; people.read, analytics.read; company.admin.read; communications.read/create/update; meeting join, invite, moderate and record, call, screen share, guest invite and admit, recording and transcript read, live support sessions (communications.support.manage); world.join, world.invite, world.room.enter, world.room.manage, world.interact, world.directory.read, world.presence.read; guests.read, guests.manage.
• Employee: read, create, update on projects, tasks and files; read on people, crm, sales and support; support.create and support.update (working the tickets of the support queues they belong to); communications.read/create/update; meeting join and invite, call, screen share, recording and transcript read; world.join, world.room.enter, world.interact, world.directory.read, world.presence.read.
• Restricted: tasks.read, files.read; communications.meeting.join, communications.screen.share; world.join, world.room.enter, world.interact, world.presence.read.

A member cannot grant, change or remove a role that carries a key they do not hold, and a custom role cannot carry a key its author does not hold. Only company keys can be put in a custom role. Features also depend on the company's plan: a module that is not included is refused even when the role allows it.