Permission-shaped screens
One layout serves every role with fields hidden by permission. Each role works on a screen organised around another role’s job.
Table of Contents
Summarize with:
Key facts
- One layout with fields hidden by permission is quick to build.
- Hiding fields leaves the screen organised around the technical model.
- Several roles may share data while needing different task support; choose shared, adaptive or separate views according to those differences.
- Training material differs by role for the same screen.
- Permissions control who may see or do what. How each role’s screen is organised is a separate design question.
How to spot it
- Operator screens with gaps where fields were removed
- Planners exporting to compare records
- Training material that differs by role for the same screen
- The same screen gets opposite verdicts from different roles
Why it happens
Internal structure became navigation. Entities and configuration hierarchies map directly onto menus and layouts, which makes them quick to build.
Permissions used to reconcile roles. One interface serves several ways of thinking, and permissions are used to fit it to each. Hiding fields leaves the screen organised around the technical model.
Design consideration
One screen is cheaper to maintain
Separate role screens add design and development work for every new feature.
What it costs
- Slow work for every role. Operators work around gaps, and planners export to compare records.
- Training per role. Each role learns a different subset of the same screen.
- Enterprise evaluations. Larger buyers asking about roles see hidden fields where they expect role-based screens.
Where it shows up