Invitations: show what access will change

Describe capabilities, not only role names

Lovable’s role menu explains that an Editor builds, edits and publishes projects, while a Viewer has read-only access. Boards.com’s Add editors screen says those people can edit content and message members. Both expose consequences that the word Editor alone could conceal.

Write role descriptions from actual capabilities rather than copying familiar labels from another product. Editing content may not include deleting it, inviting others, viewing billing or publishing externally. If a role includes a surprising permission, put that consequence beside selection. Avoid presenting a subscription badge as though it explains the access being granted.

Keep the chosen role visible when the keyboard opens for email entry. In a multi-recipient flow, specify whether one role applies to everyone or each person has an independent choice. If changing a role increases paid seats or requires another plan, disclose that commercial consequence before submission, without making the safest available permission hard to find.

Review each recipient before sending

Houzz lists chosen contacts with Can edit beside each one. Tiro’s Permission Settings shows an invited account, a role selector and an Invite action over a specific document. These interfaces let the sender inspect the person-role relationship rather than relying on a generic count of recipients.

Validate addresses without confusing a typed suggestion with a selected recipient. Show enough account context to disambiguate similar names and let people remove one recipient without clearing the others. If an address is external to the workspace, explain that distinction before sharing sensitive project content.

For a partial result, report who was invited and who was not. Do not clear the entire form after one address fails or resend successful invitations on every retry. Treat repeated submissions as the same logical request where possible. A delivery result should remain separate from acceptance; use Pending invitation until the service confirms membership.

The link needs a visible role

Plotline’s Add people sheet describes Editor as plans with you and Viewer as follows along. The selected role also appears behind the system share sheet in a later state. A share sheet helps choose a destination; it does not explain the permissions embedded in the link. That decision must already be clear in the app.

Name a link by its effective access, such as Viewer link, rather than only saying Copy link. Decide whether possession alone grants access or whether the recipient must be approved or signed in. Use clear language for whichever rule exists. A friendly preview title cannot substitute for an access policy.

If the role changes after generating a link, make the consequence explicit. Does the old link keep working, change permission or become invalid? Do not show a new Viewer selection while copying an old Editor link from local state. Revalidate the effective role at copy and send time, and provide a way to revoke or replace supported links later.

Identify the shared object and its boundaries

ClickUp’s Share sheet says Limited and explains that only people in Project 2 can access. Collect’s board sheet offers View and Edit over a visible board titled Green. A scope summary matters because a role has meaning only in relation to the thing it applies to.

Distinguish an object invitation from workspace membership. Inviting someone to one document should not quietly give them the whole library. If access is inherited from a parent, show why a narrower role cannot be selected here. Explain whether attached files, comments and future additions are included rather than relying on the sender to infer containment rules.

Keep public sharing separate from named collaboration. A Public tab and a Permissions tab may look adjacent, but their audience can be radically different. Do not switch to a public link as a recovery shortcut when a named invitation fails. Return the sender to the original scope and offer an appropriate fix.

Make exceptional consequences hard to miss

Ancestry’s Editor card lists specific capabilities and warns that the role can see information about living people. Moises separately toggles Enable collaboration and Allow editing for a setlist, explaining that anyone with the link can join. These are useful references because the audience and editing power are two different questions.

Choose a least-privilege default appropriate to the actual task, not the role that produces the most collaboration activity. A sender should not have to discover later that an editor can see private details. If you provide link expiry, revocation or per-person links, describe the real rule and verify it server-side; do not imply protection based only on the visual role name.

The privacy-settings examples help frame consequence-oriented language. Test a revoked link, a recipient already holding broader access, an expired invitation and a sender who loses permission mid-flow. Observe whether people can predict who will see and change the content. Invitation counts alone do not establish safe or useful collaboration.

An access test with two recipients

Create a private test board and invite one existing member as Viewer and one external address as Editor. Before submission, ask the sender to identify which person can change content and what else the role permits. Keep the keyboard open and verify that the role summary remains visible rather than being pushed above an unreachable sheet boundary.

Return a partial invitation failure for the external address. The interface should identify the failed recipient, retain the successful invitation as pending and avoid resending it on retry. Do not label either person Accepted unless the service confirms acceptance. Test an address entered as plain text but never selected from suggestions to catch accidental submission of an incomplete recipient.

Generate an Editor link, switch the pending role to Viewer, then copy it. In a controlled test account, verify the effective permission of the copied link. The result should agree with the visible role; a stale cached URL is not repaired by a Viewer label. Revoke the link and confirm that the management surface reflects the change without removing unrelated named invitations.

Finally, invite someone who already inherits stronger workspace access. Show why the narrower role does not reduce that existing access. Ask the sender to explain the effective audience and powers after each step. Use those answers, plus partial-failure recovery and unintended-access incidents, to evaluate the flow rather than treating a high invitation count as a success metric.

Review the recipient’s side as well as the sender’s form. An invitation should identify the shared object, inviting account and offered access without requiring the recipient to infer the context from an anonymous link. Test an acceptance attempt after the sender revoked the invitation. The result should explain that access is unavailable, not open an unrelated workspace or invite the person to request broader permissions automatically. If the recipient uses a different signed-in account, make the mismatch understandable before binding access to the wrong identity.

Check the effective access, not just the form

Use these checks on a working build, not only on the polished reference state.

• ✓Name the shared object, audience and role before submission.
• ✓Explain important capabilities beyond familiar role labels.
• ✓Keep recipient selection and per-person roles inspectable with the keyboard open.
• ✓Distinguish copied, sent, pending, accepted and revoked invitations.
• ✓Verify generated-link permissions after a role change and prevent stale link reuse.
• ✓Handle inherited access and partial invitation failures honestly.
• ✓Test public versus named sharing, large text and accessible role selection.

Related design decisions

For the identity shown to a recipient, compare the profile design examples and retain the correct team context.

When access cannot be granted, the error-state examples help design recovery without broadening permissions behind the sender’s back.