Overview
Use AccessGate after policy resolution to make allowed and restricted capabilities predictable.
Billing export capability
Switch roles and compare disabled, replaced, and hidden denied states.
Anatomy
A restricted capability should identify the boundary, explain ownership, and provide a safe next step.
- 1Policy result
Consumes an already-resolved allowed or denied capability decision.
- 2Restricted explanation
Names the required role, condition, or resource boundary.
- 3Escalation action
Offers an access request, owner contact, or support path.
- 4Capability surface
Renders normally, inert, replaced, or absent according to policy.
- 5State boundary
Keeps restricted guidance programmatically associated and visible.
When to use
Use when the same capability must adapt consistently across roles, tenants, or resource conditions.
Recommended
- Sensitive actions
Adapt export, delete, billing, identity, and security capabilities.
- Discoverable escalation
Explain restrictions for features users commonly request.
- Shared multi-role workspaces
Apply one policy result consistently across repeated surfaces.
When not to use
AccessGate is presentation logic, not authorization or a substitute for simpler conditional rendering.
Avoid
- Do not secure data with UI
Authorize every read and mutation at the API or service boundary.
- Do not hard-code role names
Resolve granular capabilities in a policy layer before rendering.
- Do not expose sensitive discovery
Use hide mode when revealing that a capability exists creates risk.
Variants
Choose denied behavior from discoverability and security requirements, then choose a surface by available space.
Disable
Preserves the capability’s location while preventing interaction.
Hide
Removes the capability and all restricted messaging.
Replace
Swaps sensitive content for a dedicated restricted state.
Inline, panel, banner
Adapts guidance to actions, whole regions, and workflow notices.
States
Capability state should remain deterministic while roles and contextual policy data change.
| State | Trigger | Visual response | Interaction |
|---|---|---|---|
| Loading | Policy is unresolved | Progress status | Capability remains unavailable |
| Allowed | Capability granted | Original content | Native behavior remains unchanged |
| Disabled | Denied but discoverable | Inert content and explanation | Only escalation remains available |
| Hidden | Denied and undiscoverable | No rendered output | No focus or announcement |
| Replaced | Denied region needs guidance | Restricted-state surface | Help or access request is available |
| Conditional | Context rule blocks access | Reason names unmet condition | User follows remediation path |
Behavior
The component reflects policy; the application owns identity, resolution, refresh, authorization, and audit.
Fail closed
Omitted or unresolved allowed values deny access.
Refresh safely
Show loading while updated role and resource claims resolve.
Escalate intentionally
Request paths identify the capability and granting owner.
Enforce server-side
Repeat the same authorization before returning data or mutating state.
Accessibility
Restricted states must be perceivable, understandable, and absent from keyboard order when unavailable.
| Key | Action |
|---|---|
| Tab | Skips inert denied content and reaches an escalation action when supplied. |
| EnterSpace | Activates the focused access-request or help control. |
| ShiftTab | Moves backward without entering disabled descendants. |
- Use visible text in addition to lock icons and color.
- Explain the required role or unmet condition.
- Keep disabled descendants out of the focus order.
- Do not announce intentionally hidden capabilities.
- Use announceDenied only for a denied state that changes after user action.
- Retain native semantics for allowed children.
- Ensure request-access actions describe what will be requested.
Content guidelines
Permission messages should explain eligibility, ownership, and the next safe action without blaming the user.
Name the capability
Tell users exactly what is restricted.
Billing export access required
Name familiar roles
Use organization terminology users recognize.
Available to Finance Admins
Explain the boundary
State why the capability is controlled.
Exports contain tax identifiers
Offer a next step
Identify who can grant access or how to request it.
Request access from the workspace owner
Examples
Resolve granular capabilities outside the component and repeat authorization at the server boundary.
Restricted settings panel
Replace an entire sensitive region with owner guidance.
Props / API
AccessGate extends div attributes for allowed, loading, and denied capability states.
Props