Permission-Aware Interfaces
Permissions can make a screen look different for different roles. A screen that works for a sales user can leave an administrator or service user without the information or action needed to complete a task. Design the interface around the task that each role is expected to perform, then review the resulting screen with a representative user for each role.
This guideline covers the user-experience effects of permissions. The Permissions reference defines the authorization model and client behavior.
Keep interface behavior and access control separate
A hidden field or disabled action is interface behavior; none of these states authorizes or denies access on its own. Configure and enforce access through the documented permission model. Use a permission-aware state only to give the user an understandable screen for the access that has already been granted or denied.
When a project needs custom state logic, use the documented permission API rather than duplicating the role or grant rules in JDito. This keeps the interface aligned with the configured authorization model when roles change.
Do not rely on hiding an element to protect data or an operation. The relevant permission must enforce the restriction independently of the visible state.
Design the remaining task
Remove information and actions that are not part of a role's task when their absence makes the screen simpler and does not leave the task ambiguous. Do not leave a user at a dead end after a visibility change: the remaining information, navigation, and available actions must still support a meaningful next step.
An unavailable control can be useful when the task is recognisable but a temporary condition prevents it, for example until a record is selected. In that case, make the condition understandable through the documented behavior of the selected component. A permanently unavailable task usually should not compete with the role's available actions.
If a user must request additional access, provide a project-appropriate next step, such as contacting the responsible administrator. Do not expose protected data, internal role names, or details of other users' permissions merely to explain an unavailable function.
Account for visibility changes
Permission effects are not limited to a single field or action. They can change the structure around it:
- A
VIEWpermission can make referenced content invisible, whileREADcontrols access to data. These are different states and must not be treated as interchangeable. - Tabs and drawers derive their visibility from their referenced content. A tab or drawer without visible referenced content can disappear automatically.
- A view that remains reachable must have a useful purpose for the role. An empty region, a navigation entry with no useful destination, or a view with no possible next step needs a deliberate project decision.
The permission reference and visibility behavior for tabs and drawers describe the technical rules. Check the configured client rather than inferring the result from the Designer structure alone.
Handle permission-dependent actions clearly
An action may be unavailable because the role lacks permission or the current record is in the wrong state. Treat these as different cases in the interaction design. For every business-critical action, decide which records a role may act on and what users experience when the current selection contains a mix of eligible and ineligible records.
The project must define whether the action processes eligible records only, becomes unavailable for a mixed selection, or reports that it cannot proceed. Whichever behavior is chosen, its title, feedback, and result should make the outcome clear. The action and ActionGroup reference describes these supported approaches.
Review each relevant role
Use representative users or permission sets for every role that has a distinct task. Review the complete flow, including entry through a menu, a dashboard, or a link from another context, rather than checking an individual component in isolation.
| Review area | Questions to answer |
|---|---|
| Entry and navigation | Can the role find the context, view, or dashboard needed for its task? Do remaining entries lead to useful content? |
| Information | Can the role see the information required to decide and complete the task, without exposing information outside the role's scope? |
| fields and layout | Does hiding content leave a comprehensible form or detail area? Are labels and related information still clear? |
| actions | Are available actions easy to find? Is an unavailable action absent, temporarily disabled, or explained for a deliberate reason? |
| Empty states | What does the role see when no readable records, visible references, or permitted actions remain? Is there a meaningful next step? |
| Multi-record work | Does the result remain clear when the selection contains records with different permissions or states? |
| Feedback | Do confirmations, errors, and status messages explain the outcome without disclosing protected information? |