Share dialog

Problem Context

• The shared object may be private, organization-only, public, domain-restricted, password-protected, expiring, downloadable, editable, commentable, or view-only.
• Recipients may be people, groups, domains, meeting attendees, chat spaces, external guests, anonymous link holders, or native device share targets.
• The action may create a new grant, update a link, send a notification email, copy an existing URL, open a native share sheet, revoke access, or expose an access request path.
• Policies may restrict external domains, public links, editor sharing, download and copy permissions, link expiration, passwords, ownership, or who can manage access.

Selection Rules

• Choose share dialog when the primary task is sharing a specific object by recipients, groups, link scope, role, notification, copy-link, native share, or access-management controls.
• Use invite user when the user is bringing a person into a workspace, organization, channel, team, repository, or tenant with pending invitation state.
• Use object picker when users only select existing entities without sending access, changing roles, creating links, or notifying people.
• Use permission denied state when the current user lacks access and must request access or switch account before sharing.
• Use review before submit or confirmation dialog when the change is high risk, such as public links, external recipients, editor roles, removal of many people, disabled download protection, or organization-wide exposure.
• Use notification center for retained share events and access-request follow-up after the share action, not as the immediate permission editor.
• Use related links when the UI only navigates to nearby material and does not alter who can access it.
• Offer native Web Share only for device-target distribution of already-shareable content or after product permissions are correct.
• Show current access and pending changes in one place so users can distinguish adding people, changing role, changing link scope, copying a link, and stopping sharing.
• Keep revoke, remove, disable link, stop sharing, expiration, and password changes discoverable from the same access-management path used to share.

Required States

• Object identity and current access summary state
• Recipient entry, group entry, suggested recipient, unresolved recipient, duplicate recipient, and external recipient states
• Role selection states such as Viewer, Commenter, Editor, Owner, Can view, Can edit, and custom product roles
• Link scope states such as Restricted, specific people, organization, team, anyone with link, public, password-protected, and expired link
• Notify people, message, send, copy-link, link-copied, native share available, native share unavailable, and share canceled states
• Expiration date, password, block download, prevent copy, editor-can-share, and advanced owner-control states where the product supports them
• External sharing blocked, policy approval required, too many recipients, inherited access, parent-folder access, and anonymous viewer states
• Manage access, changed permission, removed person, disabled link, stopped sharing, transfer ownership, and failed update states
• Mobile sheet, desktop dialog, keyboard focus, screen-reader summary, loading, retry, offline, and permission-limited states

Interaction Contract

• Opening the dialog identifies the object and fetches current access before presenting share controls.
• Recipient entry resolves people, groups, domains, or spaces before send and labels external, duplicate, unresolved, and already-access states.
• Role and link-scope controls update a pending change summary before the system grants broader access.
• Copy link copies the URL that matches the visible link scope and role; if the user changes link settings first, the copied link uses the updated settings or explains why it cannot.
• Send shares with the selected recipients, role, notification setting, and message, then reports whether access was granted, approval was requested, or delivery failed.
• Native share is triggered by a user action and is treated as distribution to device targets, while product-specific permissions remain visible and enforceable.
• Removing access, disabling a link, changing public access, and stopping sharing require clear affected-party summaries and return focus to the access list after completion.
• Policy restrictions, inherited folder access, organization controls, anonymous access, and owner-only settings explain what users can and cannot change.

Implementation Checklist

• Define the object identity, current access model, direct grants, inherited grants, link grants, roles, group behavior, external-domain policy, notification channel, and audit fields before designing the dialog.
• Implement recipient lookup, duplicate detection, role eligibility, domain warnings, link scope choices, copy-link feedback, notification toggle, message validation, expiration, password, download protection, and revoke paths according to the real backend.
• Distinguish link creation from access granting: copying an existing restricted link should not silently make the object public or editable.
• Add review or confirmation for public, anyone-with-link, editor, external, organization-wide, inherited-access, owner-transfer, and mass-removal changes.
• Support manage-access actions such as change role, remove person, delete link, stop sharing, edit expiration, remove password, and inspect pending access requests.
• Handle native Web Share with feature detection, user activation, permission-policy failures, unsupported file types, cancellation, no targets, and fallback copy-link or email actions.
• Log actor, object, old access, new access, recipients, link scope, role, notification choice, message presence, copied link, expiration, revoke, and failure reasons without leaking secret link tokens.
• Test mobile layout, keyboard navigation, screen-reader labels, long object names, long recipient lists, external domains, anonymous link holders, inherited folders, blocked policy, offline retry, and localization.

Common Generated-UI Mistakes

• Using Share as a one-click public-link generator without showing the link scope.
• Treating native OS share as if it grants product access.
• Hiding current viewers, editors, and link holders from the user who is about to change access.
• Defaulting to broad editor access when most shares should be restricted or view-only.
• Copying a link whose access does not match the visible role or scope.
• Making revoke, delete link, stop sharing, expiration, or password settings harder to find than the initial share action.
• Sending notifications without telling the user which recipients will be emailed.
• Letting inherited parent-folder access look like a removable direct grant.

Critique Questions

• What exact object is being shared, and can users verify it before they change access?
• Who can open the object now, who will gain access, and who will lose access after this action?
• What can recipients do: view, comment, edit, download, copy, reshare, or manage permissions?
• Does the link apply to specific people, an organization, anyone with the link, or the public web?
• Will anyone be notified, and does the message match the role and link being sent?
• Can users revoke access, delete the link, stop sharing, or change expiration after sending?
• What happens when native share is unavailable, canceled, blocked by permission policy, or unable to share the selected data?