Opening proof path
SIRJ is loading the workspace, connector, or public page with the same proof path intact: ad spend, lead, booked job, invoice, paid.
Review SIRJ client invitation states, scoped memberships, token redaction, invite links, expiration, revocation, accept flows, dashboard team controls, and client-only access boundaries.
Buyer answers
The invitation path is where client trust becomes operational: role, token handling, expiry, revocation, and membership scope all have to be clear.
A client invitation stores the account id, client id, invited email, analyst or viewer role, pending status, invited-by user, token hash, expiry timestamp, created timestamp, and later accepted or revoked timestamps when the invitation changes state.
The access record is specific enough to review who was invited, which workspace they were invited into, what role they received, and whether that invite is still pending.
Review related access pathInvitation records store token hashes, and API responses serialize invitations without stored token-hash details. The dashboard can show pending invite rows, statuses, expiry, and revoke actions without exposing the raw one-time token that grants access.
Operators can manage invitations in the product while the secret needed to accept access stays out of listed invitation records and rendered team tables.
Review related access pathAcceptance checks the submitted token against the stored token hash, confirms the invitation is pending and unexpired, saves the accepted invitation state, creates a client membership, and returns an account membership scoped to the invited client id.
A valid invite does not become broad account access. It becomes a scoped membership for the client workspace that the agency selected.
Review related access pathClient invitation creation, listing, and revocation require client-management permission, active tenant and client scope, and client-management rate limits before the runtime saves or changes invitation records.
Client access remains an owner-controlled setup path, so normal viewer access does not quietly become team administration.
Review related access pathInvitation lifecycle
Pending, accepted, revoked, and expired records give operators a precise access history before client reporting expands.
| State | User sees | System path |
|---|---|---|
| Pending | The team view can show the invited email, role, pending status, expiry, and revoke action for the selected client workspace. | Invite creation normalizes the email, limits roles to analyst or viewer, stores a token hash, saves a pending invitation, and returns a redacted invitation record plus a one-time accept link. Open related surface |
| Accepted | A successful accept flow returns an accepted invitation, a client membership, and a tenant membership that includes the invited client id. | The accept route checks token equality, pending status, expiry, accepted user, and client scope before persisting membership changes. Open related surface |
| Revoked | A pending invitation can be revoked before acceptance, preserving a revoked status and revoked timestamp for later access review. | Revocation requires manage-client permission, active client scope, the original pending invitation, and a save path that returns the invitation without stored token-hash details. Open related surface |
| Expired | Expired invitations stay separate from active access, so stale links cannot silently create workspace membership after the allowed window. | Acceptance checks expiresAt before membership creation, and default invite generation sets the expiry window when an operator does not supply one. Open related surface |
Access controls
Invite creation, listing, acceptance, revocation, and persistence each have a visible user surface and a protected runtime behavior.
| Control | Reviewer sees | Protected behavior |
|---|---|---|
| Dashboard team panel | Current role, whether the user can manage client access, pending invite count, email input, analyst or viewer role selector, and revoke controls. | The dashboard state only loads pending invitations for users with manage-client permission and sanitizes each invitation before it reaches the UI. Review evidence |
| Invite creation endpoint | A created invitation with normalized email, role, expiry, redacted token hash, and an accept URL when the app base URL is available. | Runtime checks active client scope, client-management permission, and rate limits before generating a token hash and saving the invite. Review evidence |
| Invitation accept page | A scoped invitation page that asks for email, name, and password when account id, client id, invitation id, and token are present. | Incomplete links show an explicit missing-token state instead of pretending the user can enter the workspace. Review evidence |
| Token and membership persistence | Accepted invitations and client memberships can be persisted while listed and returned records avoid exposing reusable invitation secrets. | Persistence adapters store hashed invite tokens and map invitation rows back to domain objects, while API and dashboard serializers remove stored token-hash details before public responses. Review evidence |
| Rate-limited management | Invite, list, revoke, and accept operations are separate routes with client id context and clear request outcomes. | The API runtime applies client-management rate limits and requestWithActiveClient before invitation list, creation, acceptance, or revocation work runs. Review evidence |
Membership boundaries
SIRJ separates the invitation record from the membership it can create, then keeps role, client, secret, and revocation boundaries visible.
| Boundary | Buyer sees | Enforcement |
|---|---|---|
| Role limit | Client invites can grant analyst or viewer access, not owner access, so invitation links do not become account administration shortcuts. | createClientInvitation rejects unsupported invite roles before persistence and the team UI only offers viewer and analyst roles. Follow boundary |
| Client scope | The accepted user receives membership for the invited account and client workspace instead of an unconstrained agency-wide view. | acceptClientInvitation creates a clientMembership and a tenant membership whose clientIds list contains the invitation client id. Follow boundary |
| Secret handling | The product can show pending invitations and accept URLs without putting token hashes into team tables or normal API response bodies. | Invitation serializers omit stored token-hash details, while persistence stores the hash for token verification. Follow boundary |
| Revocation state | Pending invites can be revoked before acceptance, giving operators a visible way to close access that should not remain available. | revokeClientInvitation only accepts pending invitations, so accepted or stale records cannot be rewritten into misleading pending access. Follow boundary |
Invite workflow
The invitation path should be easy to audit: choose the client, choose a reporting role, generate the accept path, reject bad tokens before persistence, and show only scoped access.
Invitation work starts after the active account and client workspace are resolved, so the invite path belongs to the selected client rather than a default agency account.
The dashboard team panel, invitation endpoint, and accept URL all carry the client id needed to keep access scoped.
Open workflow stepThe invite form offers analyst and viewer roles because client invites should add reporting collaborators, not account owners.
Team controls show the role selector and current user role before an operator sends an invite.
Open workflow stepThe runtime generates or accepts an invitation token, stores a hash, saves the pending invite, and returns an accept URL with account, client, invitation, token, and email parameters.
The operator can send the client an invite link while the invitation record returned to the app remains redacted.
Open workflow stepThe accept route compares the submitted token to the stored hash and rejects invalid tokens before saving invitation or membership changes.
Invalid-token tests prove the runtime returns an error without persisting invitation or membership records.
Open workflow stepAfter acceptance, the product uses client membership and tenant membership scope to keep the invited user in the intended workspace.
The returned membership includes the invited client id and the dashboard uses client scope before rendering reporting surfaces.
Open workflow stepAccess standards
These standards keep invitation secrets, role limits, stale links, and management routes from becoming client-access risk.
Invite links grant access, so raw tokens or token hashes in dashboard rows, API lists, or rendered pages would turn team management into a security liability.
Invitation tokens are stored as hashes and serialized records omit stored token-hash details before they reach the dashboard, public accept page, or API response body.
A client invite should never become a shortcut into billing, deletion, integrations, client creation, or account administration.
Invite roles are limited to analyst and viewer, and the team UI exposes only those two roles in the invite selector.
Expired or invalid invitation links can create scope confusion if the product accepts them after the original invitation is no longer valid.
The accept path checks pending status, expiry, and token equality before saving invitation or membership changes.
Team controls become dangerous if listing, inviting, accepting, or revoking invitations can act on a different client than the active workspace.
Invitation routes parse the client id, switch request context to that client, enforce manage-client permission, and apply client-management rate limits.
FAQ
No. Client invitations are limited to analyst and viewer roles. Owner-level billing, client management, integration administration, deletion, and team administration remain outside the invite path.
No. Invitation records can be persisted with token hashes for verification, but dashboard state and API responses return redacted invitation objects without stored token-hash details.
The invitation acceptance page shows an incomplete-link state when account id, client id, invitation id, or token is missing, and asks the user to request a fresh invitation.
Yes. Users with client-management permission can revoke pending invitations, and revoked records keep a revoked status and timestamp instead of remaining available for acceptance.
Client access review
Review roles, client workspaces, white-label reporting, and audit evidence before you open client-facing access.