An invitation is a proposed membership, not a permanent access grant. People may open it late, forward it or already belong to another account. Model the invitation separately from the person and the membership it can create.
Related service: Custom software development- 01Authorize the inviter and target role.
- 02Issue an account-specific invitation.
- 03Verify the accepting identity.
- 04Recheck expiry and revocation.
- 05Create or confirm the intended membership.
SECTION 01
Separate recipient identity from the invitation record
Store who invited the person, which organization is involved, the proposed role and the invitation state. An email address helps identify the intended recipient, but it does not itself describe what the person may do. Someone can already have a login without belonging to the inviting organization.
Decide how resending works: extend the existing invitation or replace it and invalidate the old one. Keep the user-facing explanation clear. Database uniqueness can help prevent duplicate membership, while authorization checks determine whether the inviter may grant the chosen role. Do not let an ordinary member invite somebody with powers they are not allowed to delegate.
SECTION 02
Illustrative example: an invitation is revoked before acceptance
Suppose a project owner invites a contractor, then cancels the assignment before the contractor accepts. The contractor later opens the original email. The product should identify that the invitation is no longer valid without creating membership. This is a hypothetical account-lifecycle example.
If a new assignment is approved, a new invitation can carry its current scope. The old link should not regain validity just because the same email was invited again. Also test accepting while signed into a different personal account: the interface should clearly explain the identity mismatch and provide a safe route to use the intended identity.
SECTION 03
Include the administrative recovery path
Start with a few roles and one invitation method. Established identity services may provide parts of the token and sign-in workflow; a custom product still owns the account membership rules. Avoid building a complex guest directory before the first collaborative task is working.
Ask the agency to demonstrate double acceptance, expired invitations, revoked invitations, role changes, an inactive inviter and a user belonging to two accounts. Show pending invitations separately from active members, and let an authorized owner revoke them. Keep acceptance events attributable without writing secret invitation tokens into ordinary logs. The handoff should document who can recover an account when its only owner becomes unavailable.
SECTION 04
Frequently asked questions
Is an invited person already a member?
Not necessarily. Keep pending invitation and active membership as distinct states, with the acceptance conditions defined by the product.
Can we reuse the old link after reinviting?
Choose an explicit replacement policy. A revoked invitation should not silently regain authority when a new invitation is issued.
What if the recipient already has an account?
Use their verified identity to create the intended membership after checking the invitation. Do not create a second person merely because another organization invited them.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Authorization guidanceOWASP Foundation
- Database constraintsPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy