Permissions

Most permissions use entity:action:scope triples. Actions include list, read, edit, and delete. Scopes typically differentiate all versus assigned access for large entities such as customers or tours.

Organization administration is also expressed with the admin entity: roles that can manage child organizations, roles, and similar hierarchy tooling include admin permissions such as admin:list:all, admin:read:all, and related admin:* combinations. Server-side checks for “organization administrator” may treat any permission string that starts with admin: as sufficient for certain routes—always use the dashboard role editor as the source of truth for a workspace.

Primary entities with list support include customer, tour, landing-page, event, offer, newsletter, project, document, contactform, siteplan, place, and admin. Sub-entities such as protocol, email, and task intentionally omit list because visibility is inferred via relationships.

Edge cases—such as mixed assignments or platform-operator shortcuts—are resolved inside the product; use the dashboard role editor as the source of truth for a given workspace.

Permission format

entity:action:scope

Part	Meaning	Example
entity	Resource type being controlled.	customer, tour, event, admin
action	Operation the role can perform.	list, read, edit, delete
scope	Breadth of access.	assigned, all, off

Actions

Action	Meaning
list	See records in list views for entities that support listing.
read	Open or inspect record details.
edit	Create or update records.
delete	Delete records where allowed.

edit includes creation rights in the permission model, so create buttons often depend on edit permission rather than a separate create permission.

Scopes

Scope	Meaning
assigned	Access records connected to the user through assignment or relationship rules.
all	Access all records for that entity inside the organization.
off	No explicit access, except special self-access or relationship rules enforced by the product.

Assigned-only behavior can vary by entity. For example, customers can have responsible users, while tasks, emails, and protocols can be visible through customer assignment or direct assignment.

Entity groups

Primary entities support list-style access:

• customer
• tour
• landing-page
• event
• offer
• newsletter
• project
• document
• contactform
• siteplan
• place
• admin

Sub-entities intentionally do not use list:

• protocol
• email
• task

These sub-entities are usually reached through relationships to customers, projects, or direct assignments.

Dashboard visibility

The sidebar uses permissions to decide which groups and routes appear. If a user cannot see a page, check the entity permission first:

• Customer management: customer, protocol, task, project, document, newsletter, email, event.
• Web apps and tours: landing-page, tour, offer, contactform, siteplan (site plans and questions are gated with landing-page visibility in typical configurations).
• Settings hierarchy: admin entity permissions (child organizations and roles).
• Event settings: event.

Gallery under Web apps and tours is shown more broadly than some neighboring items; exact rules can vary by deployment—if a link is missing, confirm landing-page, tour, and organization context rather than assuming a broken build.

Platform operators may see additional routes that tenant users never encounter.

Related concepts: Permissions and organizations, Child organizations and roles.