UI + UXCollaboration And Social Interactionestablished
Share dialog
Provide an object-specific dialog that exposes current access, lets users add recipients and groups, choose link scope and role, decide notification and message behavior, copy or send links, use native share only where appropriate, review risky changes, and manage or revoke access after sharing.
A user needs to share one object or a small set of selected objects with people, groups, domains, links, or device targets.
The product can show current access and enforce role, scope, notification, expiration, and revoke behavior.
Users need a quick path to copy a link while still understanding access consequences.
Access changes may cross privacy, organization, external, public, or download-permission boundaries.
Avoid when
The task is inviting a person to become a workspace, organization, or team member rather than sharing a specific object.
The user is only choosing an object or person and no access or delivery side effect occurs.
The current user lacks permission to share and needs a request-access or account-switch flow.
The action is a bulk provisioning, role-administration, policy-management, or ownership-transfer workflow that requires a broader admin surface.
The product cannot reliably show who has access or revoke the access it creates.
Problem it prevents
Sharing an object changes who can see, edit, copy, download, forward, or request access to sensitive material, but many interfaces collapse recipient entry, link copying, native sharing, role changes, and revocation into a single ambiguous Share action.
Pattern anatomy
What a strong implementation has to make clear
User need
The shared object may be private, organization-only, public, domain-restricted, password-protected, expiring, downloadable, editable, commentable, or view-only.
Pattern promise
Provide an object-specific dialog that exposes current access, lets users add recipients and groups, choose link scope and role, decide notification and message behavior, copy or send links, use native share only where appropriate, review risky changes, and manage or revoke access after sharing.
Required state
Object identity and current access summary state
Recovery path
A private file becomes publicly editable because copy link implicitly changed scope.
Access contract
Use labelled fields for recipient entry, role, link scope, notification toggle, message, expiration, password, download controls, copy-link, send, revoke, and stop-sharing actions.
Quality bar
The difference between expert and weak execution
Strong implementation
Specific, visible, recoverable
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 mobile share sheet offers native device targets for an already-public article while keeping product access controls separate for private workspace files.
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.
A user changes a folder from restricted to anyone with the link, sees an external exposure warning and an expiration control, then confirms the broader share.
Weak implementation
Vague, hidden, hard to recover from
A Share button instantly copies an Anyone with the link can edit URL without showing the current access level or role.
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 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 collaborator is removed from a document with no summary of who lost access or how the link behavior changed.
UI guidance
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.
Separate harmless distribution actions from permission-changing actions: copying an already-valid restricted link, sending an email to existing collaborators, widening link scope, adding editors, making content public, and removing access need distinct labels and review states.
UX guidance
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.
Prevent accidental exposure by showing who can open the object, what each role can do, whether recipients are inside or outside the organization, what link holders can access, whether notifications are sent, and how the share can be changed or stopped later.
Implementation contract
What the implementation must handle
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
Interaction
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.
Accessibility
Use labelled fields for recipient entry, role, link scope, notification toggle, message, expiration, password, download controls, copy-link, send, revoke, and stop-sharing actions.
Expose current access, pending changes, external-domain warnings, link-copied feedback, send result, and policy restrictions as text associated with the relevant control or live region.
Do not rely only on avatars, role colors, lock icons, globe icons, or link icons to communicate access scope.
Make recipient chips, role menus, link-scope menus, copy-link, send, native-share, remove, change role, and delete-link controls keyboard reachable.
Review
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?
Interactive lab
Inspect the states before you copy the pattern
Share one object without widening access by accident
Add recipients, switch role and link scope, toggle notification, copy the current link, review external sharing, set expiration, block download, try native share, stop sharing, and compare public-default, hidden-role, no-warning, copy-mismatch, no-revoke, and native-only failures.
Share dialog
Interactive demo is ready
Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.
State To Inspect
Object identity and current access summary state
Keyboard / Access
Tab order follows object summary, current access, recipient entry, role, notification, message, link scope, copy link, advanced link settings, send, and manage-access actions.
Avoid Generating
Using Share as a one-click public-link generator without showing the link scope.
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?
Accessibility
Use labelled fields for recipient entry, role, link scope, notification toggle, message, expiration, password, download controls, copy-link, send, revoke, and stop-sharing actions.
Expose current access, pending changes, external-domain warnings, link-copied feedback, send result, and policy restrictions as text associated with the relevant control or live region.
Do not rely only on avatars, role colors, lock icons, globe icons, or link icons to communicate access scope.
Make recipient chips, role menus, link-scope menus, copy-link, send, native-share, remove, change role, and delete-link controls keyboard reachable.
Give repeated remove and role-change controls accessible names that include the recipient, group, or link they affect.
Keep focus inside modal dialogs and mobile sheets, return focus to the Share trigger on close, and move focus to result summaries after send or revoke.
Provide readable summaries for inherited access and anonymous link holders without forcing screen-reader users to inspect every avatar.
Keyboard Behavior
Tab order follows object summary, current access, recipient entry, role, notification, message, link scope, copy link, advanced link settings, send, and manage-access actions.
Recipient lookup supports arrow-key navigation, Enter to commit a highlighted recipient, Escape to close suggestions, and Backspace to remove a focused recipient chip.
Role and link-scope menus announce the current value and whether choosing it broadens access.
Copy-link feedback returns focus to the Copy link button and announces that the copied link matches the current visible settings.
High-risk confirmation returns focus to the changed control if canceled and to the access summary if confirmed.
Native share cancellation, unavailable targets, and permission-policy failures return focus to a fallback action.
Removing a recipient or deleting a link returns focus to the next access row or the current access summary.