Access recipes
Use these recipes as starting points for scoped grants, then verify the actual task. They describe current capability keys, not new roles or automatic grants. Existing legacy workspaces must use their available access model until migrated. See Roles and permissions.
Grant a task in one workspace
- Open Admin → Users & Devices as an administrator who may delegate the requested capabilities.
- Select a person or access group and the exact site/environment. Choose an expiry for temporary access.
- Add the capabilities required by the task. Preserve resource restrictions such as material stewardship or assigned workplaces.
- Inspect effective access, including inherited grants. Removing a direct grant does not remove the same right inherited from a group.
- Ask the intended person to select that scope and repeat one controlled task. Verify a separate task that must remain denied.
Read access, draft editing, publication, assignment and operational execution remain separate. A permission name does not override native lifecycle rules.
Choose a recipe
| Task | Capability keys to consider | Deliberate boundary |
|---|---|---|
| Use an assigned operational App | app.read, app.interact; its published capabilities and domain actions | App assignment/audience and workplace restrictions still apply. A shop-floor identity also needs an approved assigned device. |
| Inspect and report production | production_order.read, production_order.progress.report, work_center.read; production_issue.read, production_issue.report when reporting issues | No scheduling, master-data editing or commercial customer-order access merely to operate a station. |
| Plan production | planning.read, planning.manage, production_order.read, work_center.read | Calendar changes and operational order edits may require their own capabilities; planning does not publish factory definitions. |
| Build an App with a Table | app.read, app.design, custom_table.read, custom_table.design; custom_table.manage only for record management | Save drafts without app.publish. Data-source operations and own-record restrictions remain explicit. |
| Publish and assign Apps | app.read, app.publish; app.assign for account assignment | Add app.design only when the person also edits drafts. Publication does not authorize arbitrary stock or production actions. |
| Build an integration | integration.read, integration.design, integration.publish; integration.credential.manage only for credential administration | integration.execute and the target action's authority remain separate. Test external actions also require environment binding approval. |
| Review maintenance | maintenance.read, maintenance.approve; maintenance.release only for return to service | Keep performer and reviewer separate when the workflow requires independent review. |
| Inspect authorization evidence | authorization_audit.read; authorization_audit.export for export | Evidence visibility does not grant access administration or operational writes. |
These rows are composed recipes, not a promise that every listed key alone opens every screen. Dependencies, current grants and configured resources determine the effective result. Native App runtime actions can use published App authority while still checking account, scope and resource limits.
Example: temporary planner
Give the person Planning read/manage plus the necessary production-order and work-center reads in Test until the agreed end date. Verify that they can open the intended backlog and save a planning draft. Verify that publishing an App and opening another site's records are denied. Grant Production planning separately only when it is part of their responsibility.
Revoke and verify
Remove or expire the relevant direct and group assignments. Recheck effective access and refresh the affected session when requested. Verify the protected action is denied; hiding a menu is insufficient. Review background assignments and integration identities separately because they have their own saved authority. For devices, use shop-floor administration.