Roles and permissions
Access is tied to your identity, organization, selected site/environment, and the action being attempted. A job title or visible navigation entry does not prove that an action is allowed.
What a permission allows
| Permission family | Typical responsibility |
|---|---|
| Read | Find and inspect permitted records. |
| Create / edit | Prepare or change records within the assigned scope. |
| Publish | Make an eligible configuration version available. |
| Execute / report | Perform an operational action or report progress. |
| Approve | Review eligible actions under the applicable policy. |
| Administer | Manage assigned settings, identities, or access. |
These are distinct permissions. Reading an order does not automatically allow reporting progress. Editing an App does not automatically allow publishing it. Konnie uses the acting identity's authority and cannot grant itself additional rights.
Scope and inherited access
In workspaces with scoped access enabled, direct grants and group membership determine effective permissions. A grant can apply to the tenant or a specific site/environment and may have validity dates. Resource restrictions can further limit the records you can change. Material stewardship, for example, can limit editing to assigned stewards even when a material is readable.
Groups collect people who should share access. A person's inherited access is managed through the originating group; changing a direct grant does not remove a permission still inherited from another active assignment. Role or job templates help initialize an assignment, but the actual effective permissions and scope are what matter.
Existing workspaces can still use legacy role-based access until scoped access is enabled and migrated. Use the access model displayed in your workspace. Owner/recovery responsibilities are protected separately from ordinary operational permissions.
Check or request access
- Confirm your account and the site/environment in the header.
- Open your profile or ask an authorized administrator to inspect your access under Admin → Users & Devices.
- Identify whether the permission is direct or group-inherited, its scope, validity, and any record restriction.
- Describe the missing action and intended records. Request the smallest relevant permission and duration.
- After an authorized change, refresh or sign in again if requested, select the intended scope, and retry the original task.
An administrator can delegate only within their own authority. Some changes require stronger authentication. A permission change does not publish a draft or approve a pending Konnie proposal.
Diagnose a denial
A missing page, disabled button, or permission error can result from a wrong scope, expired assignment, suspended membership, restricted record, or feature availability. Preserve the task and record ID and ask your administrator to inspect the access decision. Do not switch tenants or use another person's session to bypass a denial.
Use Access recipes for concrete operator, planner, author and administrator examples. See User administration, Shop-floor accounts, and Konnie approvals.