Access rights, roles and permissions

Why it matters

Not everyone on the team should see everything: a cashier does not need accounting, an outside accountant should not grant customers credit. Genuka's roles and permissions set what each person sees and does, module by module. Understanding this mechanism also keeps you from thinking a feature is missing when it is simply closed to your account.

Summary

Each team member is given a role, and each role carries a list of permissions. A permission opens a module or a specific action: view orders, create a product, consult accounting, export data. A user only sees in their menu what their role opens to them.

A page can also be missing from the menu for another reason: if the business has chosen its modules, a page from a module that is not turned on is hidden and redirects to Settings, where the Modules button turns it on. That is not a permissions matter.

Important point: not having access to a feature does not mean it does not exist. It exists, it is simply closed to this account, and an administrator can open it in a few seconds.

How it is structured

A permission is written resource.action: orders.view (view orders), expenses.create (create an expense), accounting.view (consult accounting). The wildcard resource.* grants all actions on a resource: orders.* gives everything on orders.

Administrators have all rights without having to tick them one by one. This status, like any role, applies to a single business: being the administrator of your own business gives no administrator rights in another.

Genuka provides system roles, Administrator, Manager, Service agent (employee), Delivery person, Accountant, whose permissions can be changed but not their name, and you can create custom roles. Three rights are granted to all roles by default: agent.access, access to the AI assistant, chat.use, the team messaging of the Genuka Workspace mobile app, and work.use, Work (tasks, notes, approvals); an administrator can remove them from a role. In this team messaging, creating a discussion group (chat.groups.create) and deleting other members' messages (chat.messages.delete_any) are ticked role by role; everyone can always delete their own messages.

Some modules have granular permissions. Accounting, for example, is split finely: accounting.entries.view, accounting.journals.view, accounting.reconciliation.view, accounting.fixed_assets.view, accounting.export, accounting.setup. This lets you give an accountant exactly what they need, often viewing and export, without setup.

What each person sees in messaging

inbox.view opens the Inbox, but not all of its content. Without inbox.conversations.view_all, a member only sees the conversations assigned to them. And each WhatsApp number has its own permission: without it (or inbox.connections.*, which grants them all), they see nothing of what arrives on that number.

A conversation can also be made private: only the members you add to it can see it. Unlike the rights above, this restriction applies to everyone, administrators and the owner included: whoever is not a member finds it neither in the list, nor in search, nor in notifications or mentions, and the AI assistant does not show it to them either. It is not passed on to installed apps or automations either. The inbox.conversations.make_private permission is needed to make a conversation private; after that, only one of its members can change the member list or make it visible to the team again. The person the conversation is assigned to must be one of the members. Being a member does not replace the rights above: you still need inbox.view, access to the WhatsApp number concerned and inbox.conversations.view_all (or the conversation assigned to you). The customer concerned remains visible in the customer list.

Rights on the customer account ("tab")

Granting credit, exceeding a limit or taking an advance commit money: each of these actions has its own permission, separate from customers.*.

Administrators have them automatically. For other roles, assume nothing: check in the role editor what each person's role carries, and tick these rights case by case. The recommended split: the manager sells on credit and can exceed a limit; the employee sees the balance at the counter but does not grant credit; the accountant reads everything, allocates and writes off, but does not decide who gets credit.

Steps: open a right for a colleague

Reserved for accounts that manage the team (users.*): administrators, and by default managers (Manager role).

1. Settings › Company › Roles & Permissions (/settings/roles).
2. Open the role concerned, or Create a role.
3. Tick the permissions to grant: they are grouped by module, with a search and a Granted / Denied filter.
4. Save: the change applies right away to members who carry this role and work in this business. If you removed a right, their sessions are closed and they must sign in again.
5. Check the colleague's assignment in Settings › Company › Team (/users).

Edge cases and common mistakes

• "This page does not appear in my menu." The role does not carry the matching permission, or the page's module is not turned on (Settings › Modules). The page does exist.
• "I can view but not edit." This is normal: view and update are two separate permissions. It is even the recommended setup for an outside accountant.
• "I see the customer's balance but I can't sell to them on credit." Also normal: viewing (party_accounts.view) and committing the business (party_accounts.sell_on_account) are two different rights, and the second is not given to employees by default.
• A manager only grants what they hold. A member who manages the team without being an administrator can only tick, on a role, rights they carry themselves. A wildcard they hold covers the finer rights of the same resource (with products.*, they can grant products.view), never beyond (products.* does not allow granting company.view). Rights they do not hold are ignored on save, and they cannot assign a colleague a role broader than their own: check the role afterwards, or go through an administrator.
• Giving the administrator role to go fast. This opens everything, including billing, the team and data deletion. Prefer a role tailored to the need.
• A change that does not seem to take effect. On the server side it applies as soon as it is saved; it is the menu displayed that dates from when the page was opened. Ask the colleague to reload it. If they are working in another of their businesses at that moment, their rights will be recalculated when they come back to this one.
• A role that cannot be deleted. System roles cannot be deleted, nor can a role still carried by members: reassign them first.

FAQ

Can I give access to accounting only? Yes, and it is the typical case for an accountant: a role with the accounting view and export permissions, nothing else.

Are rights the same across all my businesses? No. The role, administrator included, and its permissions are defined per business: the same user can be an administrator in one and a plain salesperson in another. The owner of a business invited as an employee in another has only employee rights there. Each time they switch business, their rights are recalculated from the role they have in the chosen business: the administrator access of the first does not follow them, and they get it back when they return.

Can I limit a user to one shop? Yes, shop assignment is done on the team member and adds to the role's permissions.

See also

• Understand Genuka accounting
• The customer account (tab): sell on credit and track unpaid balances