In Pyron, what you can see and do depends on the roles you hold. A role is a named bundle of permissions, and an administrator decides which roles exist and who holds each one.
Roles bundle permissions
A role gathers a set of permissions under one name, so access can be handed out a whole job at a time rather than one permission at a time. When you sign in with an account, the roles you hold are what open the pages and controls you use.
Some people reach Pyron another way — through a portal or a public form link — and see only what that portal or form allows. For anyone signing in with an account, the roles an administrator has assigned decide what they can reach.
A person can hold more than one role. When they do, the permissions add together and the most permissive setting wins: one role can only widen what another allows, never narrow it.
Roles can also build on one another. A role can inherit from other roles and gain every permission those roles grant, which lets an organisation keep a small base role and layer extra access on top of it. Where two roles grant different levels of access to the same thing, the higher level applies.
Your organisation might keep a broad administrator role, one or more roles for the people doing day-to-day work, and a read-only role for people who only need to look. The exact set is up to whoever sets up your workspace.
Permissions cover actions and screens
A permission is the right to do one specific thing. Permissions fall into two broad kinds: the actions you take on your information, and the screens you are allowed to open.
Action permissions cover the things you do — creating an entry, editing part of the directory, running an automation, or deleting something. Screen permissions decide which pages appear for you, such as the settings areas where forms, reports and roles are managed. A person only sees a page when their role includes a permission that belongs to it.
Permissions also come at different levels of reach. Some let you only view information, some let you create or edit it, and the strongest let you do things like delete data or change how the organisation is set up. When an administrator builds a role, they choose the level for each area of the product.
In the role editor, permissions are grouped by area — the directory and its entries, reporting, automation, and administration — so an administrator can grant a whole area at once or pick out individual permissions within it.
Roles set access across the whole of Pyron. On top of that, individual parts of the directory can be shared with specific people, which grants access to only that branch without changing anyone's role.
What this means day to day
Most of the time, permissions stay out of your way: you see the pages and buttons your role allows, and nothing else.
If a button, menu item, or page you expect is missing or shown as unavailable, it usually means your role does not include that permission. That is by design, not a fault — Pyron hides or disables controls you cannot use rather than letting you start something that would be refused.
Ask an administrator to adjust your role, or to share the part of the directory you need. Which one they choose depends on whether you need broad access or access to a single branch.
Administrators manage all of this in the policy settings. There they can create and edit roles, set which roles inherit from which, and assign people to roles. To see every permission Pyron offers and what each one allows, browse the full permissions reference.