Every action a person takes in Pyron and every screen they can open is governed by a permission, and a role hands a bundle of those permissions to each person who holds it. This catalogue names each permission, groups them by the part of Pyron they cover, and tells you what each one lets a person do — so you can see exactly what a role grants before you assign it on the Roles screen.
A common starting point is an administrator role that holds every permission, alongside narrower roles that carry only what a job needs — a field role, say, that can browse the tree and log entries but little else. The exact roles, and what each allows, are yours to define.
Resources and actions
An action permission covers one action on a whole type of thing — the whole directory, every report, every page. Granting a role the permission to edit reports lets its holders edit any report, wherever it sits. To give one person access to a single part of the directory or one page instead, use sharing, covered in access and sharing and the Sharing screen.
Each permission below is written as resource:action, the same key the Roles screen filters on. The standard actions repeat across types: view opens a single item, list opens the collection, and create, edit and delete make, change and remove one.
The directory
Entries
Pages and dashboards
Forms
Lifecycles
Tables and exports
Reports
Automations
The assistant and AI
People and their access
Site administration
Integrations and service accounts
A few permissions carry more weight than the rest. node:manage_access and page:manage_access let a holder share items with anyone; user:impersonate lets them act as another person; entry:create_any_node and entry:email_to_any sidestep the usual placement and address limits; and flow_graph:run_code allows an automation to run custom code. Grant these only to roles that genuinely need them.
Screen access
Alongside the actions above, some permissions open whole screens rather than single actions. Access to a screen decides whether its link appears in your navigation — a person without it sees no way to reach that screen. Most of these screens sit inside the Setup area.
A role usually pairs screen access with the matching actions: opening the Automations screen is of little use without the automation permissions to build one, and reaching the Policy screen goes hand in hand with policy:edit. To review where a role ends up once you have chosen its permissions, use the summary on the Roles screen before you save.