A SaaS team invitation should make four things clear: who is invited, which workspace they will join, what they can do, and whether access has actually started. Keep a pending invite separate from an active member. Then make the server enforce the same rules the interface describes.
An invite touches two people and often two different account states. A smooth email screen is only one part of the work.
Put the workspace and role beside the email
Show the workspace name, recipient address, and selected role before sending. Use a small set of understandable role names and explain the actions each one allows. “Member” is too vague if it can include billing changes or deleting a project.
Choose a limited default role that matches the intended task. OWASP’s authorization guidance recommends least privilege, denying access by default, and checking permissions on every request. Apply that reasoning to who can send an invite and which role they can assign.
A disabled admin option in the browser is not an access check. The server should reject an unauthorized role or a workspace the sender cannot manage, even if someone changes the request.
Give pending invitations their own state
After the request succeeds, show “Invitation sent” and list the invite as pending. Keep the address visible so the sender can catch a typo. Make expiry, resend, and revoke actions easy to find where your product supports them.
Auth0’s organization invitation model includes a recipient, organization, expiry, and optional roles. It is one concrete example of the details an invitation system needs to track. Its defaults are product-specific; they are not a universal rule for your app.
If the server has queued the email but has no delivery confirmation, say that the invitation was sent or queued. Avoid claiming that the recipient received it. If sending fails, preserve the form and explain the next action.
Explain acceptance before granting access
The receiving page should identify the inviter, workspace, and role. Give the person a clear choice to accept. If they are signed into a different account, show which identity is active and offer a safe way to switch.
Check the recipient rules your authentication system supports. The server needs to bind acceptance to the intended identity and workspace, validate the invitation, and reject expired or revoked invitations. An invitation link should not become a way to choose arbitrary access.
After acceptance, show the workspace and the first useful task. If the role permits only viewing, the interface should reflect that without hiding a server failure behind an endless loading state.
Make repeat actions predictable
Decide how your product handles a second invitation to the same address. Perhaps it resends the pending invitation. Perhaps it asks the sender to change the role explicitly. State that behavior in the interface and keep it consistent.
An acceptance request may be retried after a slow response. Handle that retry without creating duplicate memberships or producing a misleading error. A revoked invitation should remain invalid after a resend or an old browser session.
Test the handoff between the two people
Use a small set of cases before release:
- A permitted sender invites the right address with a limited role.
- A sender attempts to assign a role they cannot grant.
- The recipient opens the link while signed into a different account.
- The link is expired, revoked, or already accepted.
- The same request is submitted twice.
- A member’s role changes after they have already loaded a page.
- A person tries to access another workspace by changing an identifier.
Check both the visible message and the server result. These cases help you find mismatches; they do not replace a security review.
The invitation is complete when the intended person joins the intended workspace with the intended access. Use that as the definition of success, then make every intermediate state tell the truth.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)