| 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. | Render a labelled lookup field with search text, scoped result list, active result, selected object chip or preview, object type, stable ID or equivalent key, secondary metadata, clear action, no-result state, loading state, and validation text. | 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. | Use approval workflow when a submitted request cannot proceed until an authorized person, group, threshold, sequence, or external policy gate explicitly approves or rejects it. | 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. | Interrupt users only when the action has a meaningful consequence that cannot be safely recovered afterward. | 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 Share button instantly copies an Anyone with the link can edit URL without showing the current access level or role. | An Invite button immediately emails every typed address with Admin access and no review of workspace, channel, or billing scope. | 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 request page says Waiting without naming the approver, required count, due date, or escalation path. | A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links. | A popup says Are you sure? with OK and Cancel but does not name the project, notes, or irreversible outcome. | A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source. |
| Good UX | A site owner adds the Finance Reviewers group as Visitors, sees that Members can contribute content, confirms no anonymous access is enabled, and saves with an audit note. | 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 requester submits a deployment, sees it is waiting for Release managers, cannot self-approve, receives a change request with a required comment, edits the change summary, and resubmits to the same route. | 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 | An owner downgrades a user to Viewer, but the user keeps edit rights through a connected team and the UI never explains effective access. | A native share sheet sends a private file URL to a chat app, but the recipient cannot open it because the product never granted access. | A member tries to invite a contractor but learns after send that guests require admin approval and no request status is shown. | A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure. | The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account. | A user types a person name and presses Save, but no actual user account was selected. | 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 task is quick one-object sharing with a link or a few recipients and no broader permission model. | 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 product only needs to state that access is denied and no recovery path exists. | The user is not signed in and the next step is authentication rather than authorization. | 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. | Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone. | 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. | Using Share as a one-click public-link generator without showing the link scope. | 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. | Showing a generic pending message without the approver, gate, rule, or due date. | Using a review page that contains no captured answers. | Asking users to confirm every routine action until they stop reading. | Calling a social feed or notification drawer an activity log without event evidence. |