Inviting colleagues and granting permissions

Nobody shares a password. Every person working with CateringOS gets their own account — that is what makes changes attributable to a person and lets you switch someone off without locking everyone else out.

You will find both in the Organisation area: accounts under Access & invitations, the permissions behind them under Permissions.

Inviting someone

  1. Open Organisation → Access & invitations.

  2. Enter name and email.

  3. Choose an app role (see below).

  4. Optionally set a scope — the person then sees only that part of your structure.

  5. Optionally tick one or more roles. Several are allowed; the union of their permissions applies.

  6. Create invitation.

The invited person receives a link, sets their own password through it and is signed in afterwards. The invitation is valid for 14 days.

While the platform’s email delivery is not yet active, the invitation link appears directly below the form. Copy it and pass it on — the link is the access, so treat it accordingly.

An open invitation can be revoked at any time. Accepted invitations remain as an entry: they are part of the audit trail of who was granted which access and when.

Access & invitations in the organisation area

App role and permissions — two different things

This is where most people stumble.

The app role determines which application someone lands in: kitchen, facility or parent portal. It is coarse and is set with the invitation.

The roles under Permissions determine what they may do there — per resource: view, create, edit, archive.

Table 1. Invitable app roles

Kitchen

Kitchen management

Full kitchen operation

Cook / kitchen assistant

Day-to-day work

Caterer employee

Commercial work, without kitchen operation

Facility

Facility employee

Reports headcounts, absences, closures

Parents / relatives

Parent portal

Admin roles are assigned exclusively by the platform. You can make neither yourself nor anyone else a managing director or facility manager.

This is not a missing feature but a security boundary: whoever may grant roles could otherwise raise their own permissions — and any permission management would be worthless. If you need another manager, contact CateringOS.

The scope

Without a setting, an account applies to the whole organisation. Choose a unit and it applies to that unit and everything below it.

A provider with five nurseries can invite one manager per house who sees only their own house — same role, different section.

Adjusting permissions

Under Permissions each role has a matrix: rows are the resources (people, menu plan, billing …), columns the four actions.

Two rules that cannot be switched off:

  • Menu visibility follows the view permission. Someone who may not view a resource does not even see the menu entry. That keeps menus free of dead ends.

  • Whoever gets an action automatically gets “view” with it. Editing without seeing would not be a meaningful state.

Permission matrix per role

System roles and your own roles

The roles that ship with CateringOS are system roles. They cannot be changed — but they can be duplicated: the copy is your own role and freely adjustable.

The reason is practical: system roles are the template that guides and support refer to. If it were different in every operation, the sentence “give them the Kitchen management role” would help nobody.

The provider admin is additionally protected and does not appear for selection.

Accounts in this organisation

Below the invitations you find all existing accounts with their app role and assigned roles. That is the answer to “who actually has access?” — a question asked at the latest during the first data-protection audit.

What you do next