Authorisation structure

An authorisation structure determines which users can see which forms within a collection. It uses a tree structure to define visibility, and works bottom-up: visibility increases as you move up the hierarchy. One structure can be reused across multiple forms, so if several forms share the same visibility logic, you only need to create it once.

Authorisation structures are created and managed under Management → Authorization structure.

How it works

Tree-based visibility

An authorisation structure always has one root node (the name of the structure), with child nodes below it, forming a strict hierarchy with only one root per structure.

Visibility rules

At the lowest level (leaf nodes), users see forms assigned to themselves (the creator is the default assignee), but not the forms of other users in the same node or in sibling nodes.

At a higher-level (parent) node, users see their own forms plus the forms of every user in the child nodes below them, recursively. Visibility flows upward through the tree.

Multiple node membership

A user can belong to multiple nodes at once. Their visibility is then the combined result of all those nodes: there’s no conflict resolution, all visible users are simply merged together.

User groups

A node can hold user groups as well as individual users. Group membership is dynamic: when a user joins the group they immediately inherit the node’s permissions, and when they leave, those permissions are automatically removed.

Roles within the authorisation structure

A node can be assigned a role. Roles are defined on the platform and determine what a user is allowed to do: for example, access certain dashboards, forms, or AI agents (such as Employees or Employees with expense option).

The role and the authorisation structure answer different questions:

• The role determines whether a user can create or use a certain form.
• The authorisation structure determines whose forms that user can see.

For example, a user might have the right to fill out an Expense form (their role), while the authorisation structure determines whose expenses they can view. All users in a node, and its child nodes, automatically inherit the role assigned to that node.

Variables

Instead of assigning a collection variable to individual users, you can assign it at node level. Variables are inherited downwards, and the value from the closest ancestor node wins.

For example, if level 1 sets a variable to A and level 3 sets it to B, a user at level 4 gets B, while a user at level 2 gets A. If only level 3 has a value and a user sits at level 2 (above it), that user gets no value: inheritance only flows from an ancestor down to its descendants, never up.

Example structure

A typical hierarchy might have the CEO at the top, departments at the second level, and employees at the third level. In that setup, the CEO sees all forms, department managers see all forms within their department, and employees only see their own forms.

Using authorisation structures in forms

A form can use exactly one authorisation method:

1. None: everybody sees everything.
2. Personal: everybody only sees their own forms.
3. Authorisation structure: select a structure from a dropdown; visibility follows that structure.
4. Manager: users see their own forms, plus the forms of users for whom they’re registered as manager.

Reusability

A collection can contain multiple authorisation structures, but a form can only use one at a time. The same structure can be reused across multiple forms, and can still be edited after being linked to one or more forms: changes take effect as soon as the form is saved.