| UI or UX | UI + UX - Durable permission administration for users, groups, roles, inherited access, effective access, and revocation | UI + UX - Object-level sharing control for recipients, link scope, roles, delivery, copy-link, native share, and access management | UI + UX - Invitation lifecycle for granting another person access | UI + UX - Guided workflow for regaining or routing around missing access | UI + UX - Authorization and access-boundary state | UI + UX - Existing-entity lookup and selected-object confirmation | UI + UX - Routed decision workflow for requests that require authorized approval | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Consequential alert decision | UI + UX - Searchable and exportable record of system, user, or administrative events |
| UI guidance | Render permission sharing as an access-management surface with the protected resource, current direct grants, inherited grants, groups, guests, anonymous or link access, role or permission level, effective access, pending changes, and revoke or save actions. | Render share dialog as an object-specific access panel that names the shared object, current access, recipient entry, link scope, role, notification and message choices, copy-link state, external-domain warnings, expiration, download controls, and revoke or manage-access actions. | Render invite user as an access-granting workflow with recipient identity, role or permission, team or channel scope, optional message, delivery method, expiry, pending status, resend, edit, cancel, and acceptance outcome. | Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task. | Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed. | Show enough fields to distinguish same-named objects before selection, and keep the selected object preview visible after the popup closes so the submitted entity can be inspected. | Render approval workflow as a routed request record with requester, object, requested action, approver eligibility, required rule, current gate, due date, decision controls, comment history, and outcome consequences. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. | Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope. | Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available. |
| UX guidance | Use permission sharing when authorized owners or admins need to grant, change, audit, or revoke durable access to a space, site, repository, folder, project, board, dataset, environment, or sensitive object. | Use share dialog when a user is granting, narrowing, distributing, or reviewing access to a concrete object such as a file, folder, document, dashboard, board, recording, report, calendar item, or media asset. | Use invite user when an authorized person needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object. | Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial. | Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action. | Use an object picker when the user must choose an existing entity whose identity matters beyond the displayed label, such as a record, person, group, account, file, team, project, or workspace. | Make the approval route understandable over time: who has the request, what decision is needed, what happens on approval or rejection, what blocks self-review, and where the requester can revise or withdraw. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. | Help the person reach a clear task outcome. | Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries. |
| Good UI | A repository access page lists teams, outside collaborators, deploy keys, and direct users with Read, Triage, Write, Maintain, and Admin roles, showing that only Admin can manage access. | A report share dialog shows the report title, current viewers and editors, a recipient field, role dropdown, Notify people checkbox, message field, link set to Restricted, Copy link, and Manage access. | A workspace invite form accepts maya@example.com, labels the invite as Workspace member, shows default channels, explains billing impact, lets the inviter add a message, and shows the pending invite with resend and cancel actions. | A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval. | A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account. | A Related account field shows two Acme Retail records with account ID, region, status, and owner, then displays a selected-object preview card before saving. | A production deployment request shows requester, service, environment, change summary, required reviewer group, self-review restriction, wait timer, Approve and Reject with reason controls, and a timeline of route changes. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. | Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive. | An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields. |
| Bad UI | A permissions page shows only individual names and Remove buttons even though group membership and parent folder inheritance still grant access. | A dialog asks for an email address but hides whether the person gets viewer, commenter, or editor access and whether an email will be sent. | A user gets admin or organization-wide access because the invite defaulted to the broadest role. | A blocked report only has Retry, so the user repeats the same denied request. | A denial page says Something went wrong and shows Retry even though the user lacks a required group. | A text field accepts Acme Retail as free text even though the backend needs a record ID. | A stale email approval applies to a request version that has changed. | Change links lack context, so assistive technology users hear a list of identical Change links. | The red destructive action is enabled immediately and sits where users expect the routine primary button. | An export button downloads a different date range and timezone than the on-screen filtered log. |
| Good UX | A space admin removes Maya from a direct grant but sees she still has View through the Contractors group, so they remove the group grant or ask a site admin to update group membership. | A manager adds finance@example.com as Viewer, keeps the link restricted, writes a notification note, copies the link, and sees that the file can be unshared from Manage access. | An admin invites an external contractor as a single-channel guest, sees the one-channel limit, adds a note, sends the invite, then extends it when it is still pending after 30 days. | A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report. | A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner. | A user searches Acme, compares two same-named records by region and status, selects the active EMEA account, and reviews the selected account ID before saving. | A finance approval requires both manager and controller approval; the first approval advances the sequence, a rejection stops downstream processing, and the requester sees the exact rejection reason and revise action. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. | Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive. | An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive. |
| Bad UX | A repository admin removes a collaborator but forgets a deploy key with write access because the access page treated machine credentials as unrelated settings. | A private file becomes publicly editable because copy link implicitly changed scope. | A user gets admin or organization-wide access because the invite defaulted to the broadest role. | A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure. | Every workspace control is disabled after one missing permission, including safe navigation and read-only tasks. | A user picks the first Acme result because every row looks identical, then links the case to the wrong account. | The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | Every archive, filter, and dismiss action opens the same confirmation until users click through automatically. | A user marks a notification read and the corresponding activity evidence disappears from the only log. |
| Best fit | Owners or admins need to manage durable access to spaces, sites, repositories, projects, folders, datasets, boards, environments, or sensitive objects. | A user needs to share one object or a small set of selected objects with people, groups, domains, links, or device targets. | An authorized user needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object. | A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue. | A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource. | Users assign, link, reference, invite, route, or attach an existing entity. | A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed. | A user has provided multiple answers and should verify them before a consequential submit action. | The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible. | Users need to inspect recorded user, admin, system, security, or integration events. |
| Avoid when | The user is requesting access after denial rather than administering access. | The task is inviting a person to become a workspace, organization, or team member rather than sharing a specific object. | The current user is creating their own account or profile. | The user is unauthenticated and the next step is sign-in or session extension. | The operation failed for network, server, validation, data, or timeout reasons after permission was granted. | Any arbitrary text is valid. | The user only needs to check their own answers before submission. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The action is routine and easily reversible. | The goal is only to show a readable milestone history for one case or process. |
| Required state | Default access list state with users, groups, guests, anonymous access, roles, and effective access. | Object identity and current access summary state | Recipient entry or directory lookup state | Recovery start state with original blocked task and current account. | Whole-object access denied state. | Empty object lookup field with label, helper text, and current search scope. | Draft or submit-ready request handoff state | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Pre-action state with an explicit consequential trigger. | Default log state with event records, result count, visible timezone, retention window, and permission scope. |
| Accessibility burden | Use labelled tables or grids with column headers for principal, source, role, capability, status, and actions. | Use labelled fields for recipient entry, role, link scope, notification toggle, message, expiration, password, download controls, copy-link, send, revoke, and stop-sharing actions. | Use labelled fields for recipient, role, scope, team, channel, message, and expiry. | Move focus to the recovery heading when the workflow opens from a denial. | Move focus to the permission message when it replaces page content or blocks a workflow. | Give the lookup field a persistent label and helper text that explains the expected object type. | Use labelled request summary, approver, status, due date, decision, comment, and history regions. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response. | Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together. |
| Common misuse | Showing only direct users while group or inherited access remains active. | Treating native OS share as if it grants product access. | Treating invitation sent as if the user is already a member. | Offering Retry for an unchanged authorization denial. | Treating authorization denial as a generic retryable error. | Treating the picker as a free text field when the system requires an existing object ID. | Treating the first approval as final when the rule requires more approvers. | Labelling the final commit button Continue. | Asking users to confirm every routine action until they stop reading. | Using vague activity labels that omit actor, action, object, timestamp, or result. |