Cross-Tenant Invitations
Who can invite?
Tenant admins with the users:manage permission. In admin mode under
/admin/users the toolbar exposes two CTAs:
- New user — creates a new local or HGE ID account from scratch.
- Invite existing HGE ID — invites a user who already holds an HGE ID (i.e. is already a member of any Uslimato tenant).
What happens on invite?
- Backend looks up whether the email corresponds to an existing HGE ID.
- An invitation is created (valid for 7 days).
- An in-app notification is fanned out into every tenant the invitee is already a member of. On their next login they see it on the bell, regardless of which tenant is currently active.
- The admin always receives an "invitation sent" confirmation — regardless of whether the email exists (to protect privacy).
Accept or decline
The invitee goes to Profile → Invitations (or clicks the bell entry):
- Accept → a new user account is created in the target tenant. After a brief toast the page reloads so the tenant switcher reflects the new membership.
- Decline → the invitation is marked as declined.
What admins see
Accepted users show up in the target-tenant user list carrying an "External · <tenant>" badge. The detail page spells it out as "Managed by <tenant>" so admins can see at a glance that the identity (name, email, avatar) is owned by the master tenant.
Permissions, group memberships and roles remain per tenant — the target tenant's admin keeps full control over what the external user can see and do inside their tenant.
Security
- Rate limit: 10 invitations per tenant per hour.
- Invitation tokens are stored securely (never in plaintext).
- Server-side email match: a logged-in user can only accept or decline invitations addressed to their own HGE ID; other users' invitations stay invisible to them.
- Audit log entries in the target tenant for create / accept / decline.
Known limitations
- If the invitee is not yet a member of any Uslimato tenant, the in-app channel cannot reach them. Email delivery is the planned follow-up.
- Avatars and display names are stored per tenant; identity sync from the master tenant happens lazily on the user's next login.