Invitations

People join a workspace by accepting an invitation. There is no "add user directly" flow: every membership has a recorded inviter, an invited email, and an audit trail.

Sending an invitation

From a workspace's settings → Members:

1. Click Invite member.
2. Enter the recipient's email and pick a role.
3. Submit. An email goes out with an accept link.

What happens behind the scenes:

• Role check. You can only invite at or below your own level. An admin cannot invite an owner. Ownership is set at workspace creation and there is no self-serve transfer.
• Already-member check. If the email already belongs to a member of this workspace, you'll get a 409 telling you so.
• Pending-invite check. If there's already an unexpired invitation for that email, the existing one is re-sent rather than a duplicate created: the invitee sees the same accept link.
• Seat-limit check. If the workspace plan caps members and you've reached it, the invitation is rejected with an explanatory message. Pending invitations count against the cap.
• Rate limit. Each user can send up to 20 invitations per hour across the whole platform.

The invite is recorded in the workspace audit log as invite_sent.

Accepting an invitation

The invitee clicks the link in the email. Loha asks them to:

1. Sign in or sign up. The accept page is gated behind authentication so the act of accepting is tied to a verified identity.
2. Confirm. They see the workspace name and the role they're being given, then click accept.

On accept, a member row is created and the workspace appears in their workspace picker. An invite_accepted audit-log entry is written.

Anyone with the link can accept, but only into the right account

The accept link is a long random token, but it's not bound to an email server-side. If the invitee forwards the email, anyone who clicks the link can accept it from their own logged-in Loha account. For high-sensitivity workspaces, prefer inviting people whose email you control or who already have Loha accounts under a known identity.

Expiry

Invitations expire 7 days after they're sent. An expired invitation cannot be accepted; the invitee must ask for a new one. Re-sending an invitation extends the expiry to 7 days from the resend.

Revoking an invitation

From the Members page, the Pending invitations section shows every unaccepted invite. Click revoke to cancel. The invitee's accept link stops working immediately, and an audit-log entry is written.

Revoking an invitation does not free a seat until the next page load, but the next invite attempt will see the freed seat and proceed. There's no race here in the typical case.

Seat limits and concurrent invites

Workspace plans cap the total number of members + pending invitations. To prevent two simultaneous invites from busting that cap, Loha serializes invitation creation per workspace with a database-level lock. If a second invite arrives while the first is still being processed, it waits, sees the updated seat count, and either succeeds (if there's still room) or fails cleanly with SEAT_LIMIT_REACHED.

This means: the members + pending invitations count is always ≤ the plan limit. There is no observable window where it exceeds.

What invitations don't do

• They don't grant access to the invitee until they actually accept. No partial state.
• They don't auto-fill from an existing user list: every invite must specify an email explicitly.
• They don't bypass MFA. If the workspace requires MFA, the invitee will be prompted to set it up after accepting.

Audit trail

Every invitation event is written to the workspace audit log:

Event	When
invite_sent	An admin or owner invites someone (or re-sends).
invite_accepted	The invitee clicks accept and the membership is created.
delete (resourceType invitation)	An admin or owner revokes a pending invitation.

Owners and admins can see these in the workspace audit log viewer.