A permission is a single decision: it names a part of your site and one thing a person can do there. Permissions group into areas, rise through levels of power, and together decide which screens a person can open. To gather permissions into a role and hand them to the people who hold it, see the roles editor.
Resources and actions
Every permission joins two halves: the part of your site it applies to, and the action it allows there. Editing an entry, running an export, and switching on an automation are three different actions on three different things — so each is its own permission.
The parts of your site fall into four areas, and within each area they are grouped by the thing a permission applies to. This is the same grouping the roles editor uses when you choose what a role can do.
Within a thing, actions rise through levels. Seeing a thing is the lightest step; managing it fully is the broadest. In the roles editor each level is its own control, so you can let a role see and change automations without letting it delete them.
A permission applies to a whole type of thing rather than a single item. Granting a role permission to edit reports lets its holders edit every report, wherever it sits — not one report in particular.
To give one person access to a single node or one page — rather than to every node or every page — use sharing instead of a role permission. See access and sharing and directory sharing.
Some tasks draw on several permissions at once. Starting a project from chat, for example, needs permission to create the project, to save and apply its plan, and to see it. When a role holds only part of such a task, the roles editor points out what else the role needs before you save. To see who can do what across your site, use the access explorer.
Screen access
Permissions do more than allow actions — they also decide which screens a person can open. A screen opens for anyone who holds a permission for something that lives on it. There is no separate permission for a screen: screen access follows from the permissions a role already grants.
A role with any reporting permission can open the screens where reports live, and a role with a permission for roles can open the roles editor. Grant a role its first permission on a settings screen and that screen opens for its holders; remove their last one and the screen closes to them again.
The Setup area gathers these settings screens, and it opens for anyone who can reach at least one screen inside it. Each screen inside checks on its own, so a role reaches only the settings screens it holds a permission on.
The main working areas of Pyron do not gate this way. The directory and the AI assistant stay open to anyone signed in — no permission hides them, though what you can see and do inside still follows your role.
You never grant access to a screen directly. Because a screen opens from the permissions behind it, giving a role a permission in a settings area also opens that area's screen — worth keeping in mind when you decide what a role can do.