Permission sharing

Problem Context

• The resource has durable authorization rules such as roles, groups, teams, guests, anonymous users, parent inheritance, folder scope, repository roles, space permissions, service accounts, or keys.
• The user is an owner, admin, space admin, repository admin, site owner, project maintainer, data steward, or delegated access manager.
• Permission changes may apply to many objects, cascade through inheritance, affect connected services, expose confidential data, or remove a person's only route to work.
• The system may need audit evidence, approval, expiration, policy checks, inherited access explanation, and no-disclosure treatment for sensitive resources.

Selection Rules

• Choose permission sharing when users manage durable access grants, role assignments, group permissions, effective access, inheritance, anonymous access, or revocation for a protected resource.
• Use share dialog for quick object-level sharing with recipients, link scope, notification, and copy-link behavior.
• Use invite user when access starts through a pending workspace, organization, team, or tenant invitation lifecycle.
• Use permission recovery when a denied user asks an owner or admin to grant access; permission sharing is the owner-facing grant and revoke surface.
• Use permission denied state when the user only needs to understand why they cannot access or perform an action.
• Use approval workflow when the permission change requires an approver or policy decision before it is applied.
• Use review before submit or confirmation dialog for public, anonymous, admin, export, delete, inherited-access break, service-account, deploy-key, and bulk-removal changes.
• Include direct access, inherited access, group access, guest access, anonymous access, service credentials, owner/admin roles, and effective access where those routes exist.
• Show role capabilities in task language such as view, comment, add, edit, delete, export, manage access, administer, or approve.
• Do not claim access is revoked until every active route to access is removed or explicitly named as still active.

Required States

• Default access list state with users, groups, guests, anonymous access, roles, and effective access.
• Direct grant, inherited grant, group membership, connected-team membership, service-account, deploy-key, and anonymous-access states.
• Add user or group state with entity lookup, duplicate detection, role selection, and policy checks.
• Role change state with before and after capabilities.
• Pending changes review state that names who gains, loses, or keeps access.
• High-risk grant state for Admin, Owner, Space Admin, Full Control, anonymous access, public access, export, delete, or manage-access permissions.
• Revoke state that detects remaining access through groups, parent scopes, keys, or connected services.
• Approval required, policy blocked, inherited read-only, save failed, audit note required, and saved states.
• Bulk edit, long list, filter, search, sort, empty, loading, and permission-limited states.
• Mobile condensed state where role capability and effective access remain readable.

Interaction Contract

• Opening the permission sharing surface loads direct grants, inherited grants, group or team grants, anonymous access, service credentials, and owner or admin constraints before edits are saved.
• Adding a user or group requires a resolved entity, role, scope, and policy check before it creates an access grant.
• Changing a role shows the previous role, new role, key capabilities, and whether the change broadens or narrows access.
• Removing a row checks whether effective access remains through another route and labels any remaining group, parent, service, or anonymous grant.
• High-risk grants and removals require review, confirmation, approval, or audit note according to policy.
• Saving produces a clear result that distinguishes applied, pending approval, blocked, partial, and failed permission changes.
• The access list updates after save and preserves enough context for users to verify who can still access the resource.
• Audit records capture actor, resource, affected principal, old role, new role, source of access, timestamp, reason, approval, and policy outcome.

Implementation Checklist

• Define the permission graph: direct grants, groups, teams, guests, anonymous users, link grants, parent inheritance, service accounts, deploy keys, roles, custom roles, owners, admins, and policy constraints.
• Compute effective access separately from direct rows and expose why each person or group can view, edit, export, delete, manage access, or administer.
• Build role descriptions, capability previews, before/after summaries, duplicate checks, inherited-read-only labels, and remaining-access warnings.
• Implement add, role change, revoke, bulk change, search, filter, sort, save, approval, audit note, cancel, retry, and rollback paths.
• Protect risky operations such as anonymous access, public export, Full Control, Admin, owner transfer, deploy key write access, service-account grants, and group-wide removal with review or approval.
• Test group overlap, inherited folder access, Teams or Microsoft 365 group connection, anonymous access, deploy keys, service accounts, owner-only controls, partial failures, long names, keyboard use, screen readers, and mobile wrapping.

Common Generated-UI Mistakes

• Showing only direct users while group or inherited access remains active.
• Using a share dialog as the only permission administration surface.
• Hiding what a role can actually do until after it is assigned.
• Letting users remove a visible row and believe access is gone when effective access still exists.
• Treating service accounts, deploy keys, anonymous links, or connected teams as separate from human access review.
• Saving high-risk admin, public, export, delete, or anonymous grants with no review, approval, or audit note.
• Making bulk permission changes without before and after counts or rollback guidance.

Critique Questions

• What are all active routes by which a person, group, guest, anonymous user, service account, or key can access this resource?
• Can users tell the difference between direct access and inherited or group access?
• What does each role allow in task terms, and which actions are risky?
• Who gains access, who loses access, and who keeps access after the pending change?
• What happens if the user removes a direct grant but effective access remains?
• Which changes need confirmation, approval, audit note, expiry, or policy review?
• Can the saved access state be proven later in an activity log or audit export?