Workspace invitations should identify the intended organisation, recipient and proposed access, with defined acceptance, expiry and revocation behaviour. Receiving a link should not automatically grant every permission described in an old message. Recheck current invitation state and authority when access is accepted.
Let’s plan your workspace invitations.
Bring your workflow, constraints and open questions. We’ll help you define the requirements and work through a practical next step.
Define the membership outcome
Record who may invite, which roles they may grant and whether approval is required. Distinguish creating a user identity from adding that identity to a workspace.
For a hypothetical team product, an existing user may accept an invitation to another organisation without merging the organisations' data or replacing their current membership.
Use an invitation lifecycle matrix
| State or event | Requirement | Test case |
|---|---|---|
| Created | Permitted inviter and proposed scope | Inviter attempts a higher role |
| Sent | Communication status separate from membership | Email delivery fails |
| Accepted | Correct identity and current authority | Different account is signed in |
| Expired | Link cannot grant stale access | Old email opened later |
| Revoked | Existing pending link becomes unusable | Recipient accepts after withdrawal |
| Reissued | Clear relationship to prior attempt | Multiple emails arrive out of order |
Keep invitation tokens protected under the security design. Do not place them in general analytics or expose them to unrelated support roles.
Explain identity choices clearly
Show the target workspace and the account being used before acceptance where appropriate. If the intended identity differs from the active one, provide a safe correction path rather than silently adding the wrong person.
Do not infer ownership of an organisation from an unverified typed email domain. Domain-based membership policies need their own approved trust model.
Test authority changes
Remove the inviter's grant permission before a synthetic invitation is accepted. Define whether the invitation remains valid under the organisation's rules and enforce that choice consistently.
Test repeated acceptance, already-existing membership and a workspace closed after sending. The resulting membership and customer messages should reflect current state, not only the original email content.
Invitation questions
Does revoking an invitation remove an accepted member?
Those are separate lifecycle actions unless explicitly designed otherwise. Give administrators clear current-state controls.
Should accepting an invite require creating another account?
Not necessarily. Use the approved identity model and preserve separate memberships without unintended account merging.
Pair invitations with tenant identity requirements, and review access transitions with Drema's SaaS team.