Access controls

Roles and permissions keep client proof visible without opening every control to every user.

Review SIRJ owner, analyst, and viewer roles; client-scoped invitations; dashboard, Ask Data, export, billing, team, integration, and data administration permissions.

Review client workspaces Open security controls White-label reporting Client invitations Exports and destinations Delivery and recipients Audit evidence

Buyer answers

Make access clear before client reporting spreads.

Agencies need clients, operators, strategists, and executives inside the same reporting motion without turning every user into an account administrator.

Buyer answer

What roles does SIRJ support?

SIRJ uses owner, analyst, and viewer roles. Owners can manage the account, team, clients, integrations, billing, exports, and data administration. Analysts can inspect dashboards, ask source-backed questions, and export reports or data. Viewers can inspect dashboards and ask supported questions without administration privileges.

Agencies can involve operators, strategists, executives, and clients without giving every person the same ability to change sources, billing, exports, or data controls.

Follow the access path

Buyer answer

Can a user be limited to one client workspace?

Yes. A membership can be scoped to all clients or to specific client ids. Client access checks require the membership account to match the client and the requested client to sit inside the user's allowed client list before permissions are evaluated.

A client viewer or analyst can be routed into one client workspace without exposing the agency portfolio or another client's reporting data.

Follow the access path

Buyer answer

How do invitations work?

Client invitations create pending, accepted, revoked, or expired access records. Invitations are limited to analyst or viewer roles, include a one-time token, and create a client-scoped membership when accepted before expiry.

The invite path lets an agency add clients or collaborators to a single workspace while preserving token handling, invite status, accepted user, expiry, and revocation evidence.

Follow the access path

Buyer answer

Which actions are restricted?

Billing, team management, client management, integration management, report export, data export, and data deletion require explicit permissions. The API runtime checks role and client scope before handling client, integration, billing, export, and compliance routes.

A polished report workflow does not require giving every user the ability to alter connections, run exports, delete data, or change billing.

Follow the access path

Role map

Owner, analyst, and viewer roles carry different access.

The role table gives buyers a fast answer before they inspect invitations, client scope, exports, or administration controls.

Role	Can do	Best for
Owner	Manage billing, team access, clients, integrations, dashboards, Ask Data, report exports, data exports, and deletion workflows for the account and scoped clients.	Agency leadership, operations owners, or implementation leads who are responsible for source setup, billing, client workspace structure, and governed data actions. See related surface
Analyst	View dashboards, ask supported questions, export reports, and export source-backed data when the analyst is inside the account and client scope.	Strategists, reporting operators, and account managers who need proof access and export ability without billing, team, integration, or deletion administration. See related surface
Viewer	View dashboards and ask supported questions for the client workspace they can access, without report export, data export, team, billing, or connector administration.	Clients, executives, and stakeholders who need source-backed visibility without the ability to change setup, invite users, export data, or manage integrations. See related surface

Permission boundaries

Sensitive actions stay separate from simple visibility.

A client-facing user can review proof without gaining the controls that change billing, users, source setup, exports, retention, or deletion.

Permission area	Allowed roles	Protected action	User impact
Billing and team administration	Owner	Plan checkout, billing portal access, team invitations, invitation revocation, account-level client management, and role assignment remain owner-level responsibilities.	Pricing, rollout, and client access decisions stay with the account owner instead of drifting into every reporting user account. Review boundary
Client and integration administration	Owner	Client creation, source connection, OAuth starts, API key setup, resource selection, sync actions, and connector disconnects require administration rights.	A viewer can inspect proof without accidentally changing the source path that dashboards, reports, and Ask Data answers depend on. Review boundary
Dashboard and Ask Data access	Owner, Analyst, Viewer	Dashboard viewing and supported questions are available to scoped users so they can inspect source-backed answers without broader administration rights.	Clients and internal stakeholders can see evidence and ask supported questions while the product still refuses unsupported or out-of-scope answers. Review boundary
Report and data export	Owner and Analyst	Report exports and source-backed data exports require export permissions and active client scope before the runtime returns a file or package.	Agencies can share report access broadly while keeping downloadable proof and data packages restricted to users with a stronger operating role. Review boundary
Data deletion and retention	Owner	Tenant data deletion and retention routes require data administration permission, client confirmation, and scoped compliance job handling.	Destructive or regulated actions stay out of normal reporting roles and remain reviewable through compliance and audit evidence paths. Review boundary

Client invitations

Invitation states make client access reviewable.

Invitations are part of the access story: buyers need to know what is pending, accepted, revoked, or expired before clients enter a workspace.

State	User sees	Safeguard
Pending invitation	The invited email, role, client workspace, invited-by user, created time, expiry, and pending status can be reviewed before acceptance.	The invitation token is not exposed in listed invitation records, and the accept route requires account, client, invitation, and token context. Review invitation path
Accepted invitation	A valid acceptance creates a client membership and account membership scoped to the invited client so the user enters the intended workspace.	The acceptance path rejects expired or invalid-token invitations before saving membership changes. Review invitation path
Revoked invitation	A pending invitation can be revoked before acceptance, preserving revoked status and the revoke time for access review.	Only pending invitations can be revoked, which keeps accepted and expired invitation records from being rewritten into misleading states. Review invitation path
Expired invitation	Expired invitations are separated from active access so a stale invitation does not silently create workspace access after its allowed window.	The accept flow checks expiry time before membership creation and asks the user to request a fresh invitation when the link is no longer valid. Review invitation path

Workspace scope

Role checks and client checks have to work together.

A role says what a user may do. Client scope decides where that ability applies.

Scope	Buyer sees	Boundary
Account membership	The user belongs to one SIRJ account with a role that controls account-level abilities such as team, billing, clients, integrations, and data administration.	The account id must match before client access or permissions matter, which prevents a user from crossing into another tenant's workspace. Follow scope path
Client list	A membership can include all clients or a specific list of client ids, which determines which client workspaces appear to that user.	Client access fails when the requested client is outside the membership list, even if the user has a role with the requested permission. Follow scope path
Client invitation	An invitation carries account id, client id, email, role, status, invited-by user, expiry, and acceptance or revocation timestamps.	Invitations create scoped access only for analyst or viewer roles and only when the token is valid before expiry. Follow scope path
Client-facing mode	White-label and portal views can show client-facing dashboards and reports while stripping admin-oriented navigation for viewer-style access.	Branding changes presentation, not source scope, report evidence, role limits, or the underlying client workspace boundary. Follow scope path

Access workflow

From first owner to client-safe reporting access.

SIRJ shows the operating sequence: create the owner, choose a client workspace, invite scoped collaborators, check permissions before actions, and keep access visible during reporting.

Create the account owner Create or select the client workspace Invite scoped collaborators Check permission before action Keep access visible during reporting

Workflow

Create the account owner

The first account path gives the owner the commercial and administrative controls needed for plan choice, billing, team setup, client workspaces, integrations, and compliance actions.

Account setup and billing pages explain plan intent, signup, checkout, trial state, billing portal, and the first workspace route after account creation.

Open related step

Workflow

Create or select the client workspace

The owner or permitted operator creates a client workspace, then source records, dashboards, invitations, branding, reports, and weekly delivery stay tied to that client boundary.

Client workspaces show the agency overview and the selected workspace path that owns the source-backed proof.

Open related step

Workflow

Invite scoped collaborators

Invitations route collaborators into an analyst or viewer role for the intended client workspace, with status, expiry, token validation, and revocation states.

The invitation acceptance page and client access runtime show how the invite link becomes scoped workspace access or a visible invalid-link state.

Open related step

Workflow

Check permission before action

Every sensitive route should confirm client scope and the required permission before allowing exports, billing, integration setup, client management, retention, or deletion actions.

Security, exports, and audit pages show the runtime checks and reviewer paths behind protected actions.

Open related step

Workflow

Keep access visible during reporting

As dashboards, Ask Data answers, white-label reports, weekly delivery, and exports are shared, the role and client boundary should remain visible enough to explain who can inspect or move proof.

White-label reporting, reports, weekly insights, and exports keep client-facing proof separate from administration and data-exit controls.

Open related step

Access standards

Access controls should protect proof without slowing review.

These standards explain what SIRJ keeps separate when dashboard visibility, Ask Data access, exports, administration, and deletion are evaluated.

Standard

Do not give viewers administration controls

Client-facing users often need dashboard visibility, but giving them integration, billing, export, deletion, or team controls can create avoidable reporting and security risk.

Viewer access is limited to dashboard and supported-question permissions, while owner and analyst roles hold stronger operating permissions.

Standard

Do not skip client scope checks

A role is not enough by itself; the same analyst should not see another client workspace unless their membership includes that client.

Client access checks require account match and client id scope before the requested permission is evaluated.

Standard

Do not expose invitation secrets

Invitation links create access, so listed invitation records and public surfaces must avoid exposing token hashes or reusable secrets.

Client invitation API responses redact token hashes and the acceptance path requires the one-time token before creating membership.

Standard

Do not let export access imply deletion access

Exporting a report or data package is operationally different from deleting tenant data or running retention jobs.

Report export, data export, data deletion, and retention actions have separate permissions and API checks.

FAQ

Roles and permissions, answered plainly.

Can clients get access without seeing every agency client?

Yes. Client invitations create membership for the intended client workspace, and client access checks prevent users from opening a client outside their allowed scope.

Can viewers export reports?

No. Viewers can inspect dashboards and ask supported questions, while report and data export are limited to users with export permissions.

Who can manage integrations?

Integration administration belongs to users with integration management permission, which keeps source setup and disconnect actions away from normal client-facing viewers.

Are billing and data deletion separated from reporting?

Yes. Billing, team management, data deletion, and retention jobs are separate administrative abilities, not implied by dashboard, Ask Data, or report visibility.

Access review

Show clients the proof without opening every control.

Review client workspaces, role boundaries, white-label reporting, exports, and audit evidence before inviting collaborators into SIRJ.

Review client workspaces Open security controls

Access controls

Roles and permissions keep client proof visible without opening every control to every user.

Review SIRJ owner, analyst, and viewer roles; client-scoped invitations; dashboard, Ask Data, export, billing, team, integration, and data administration permissions.

Review client workspaces Open security controls White-label reporting Client invitations Exports and destinations Delivery and recipients Audit evidence

Buyer answers

Make access clear before client reporting spreads.

Agencies need clients, operators, strategists, and executives inside the same reporting motion without turning every user into an account administrator.

Buyer answer

What roles does SIRJ support?

Agencies can involve operators, strategists, executives, and clients without giving every person the same ability to change sources, billing, exports, or data controls.

Follow the access path

Buyer answer

Can a user be limited to one client workspace?

A client viewer or analyst can be routed into one client workspace without exposing the agency portfolio or another client's reporting data.

Follow the access path

Buyer answer

How do invitations work?

The invite path lets an agency add clients or collaborators to a single workspace while preserving token handling, invite status, accepted user, expiry, and revocation evidence.

Follow the access path

Buyer answer

Which actions are restricted?

A polished report workflow does not require giving every user the ability to alter connections, run exports, delete data, or change billing.

Follow the access path

Role map

Owner, analyst, and viewer roles carry different access.

The role table gives buyers a fast answer before they inspect invitations, client scope, exports, or administration controls.

Role	Can do	Best for
Owner	Manage billing, team access, clients, integrations, dashboards, Ask Data, report exports, data exports, and deletion workflows for the account and scoped clients.	Agency leadership, operations owners, or implementation leads who are responsible for source setup, billing, client workspace structure, and governed data actions. See related surface
Analyst	View dashboards, ask supported questions, export reports, and export source-backed data when the analyst is inside the account and client scope.	Strategists, reporting operators, and account managers who need proof access and export ability without billing, team, integration, or deletion administration. See related surface
Viewer	View dashboards and ask supported questions for the client workspace they can access, without report export, data export, team, billing, or connector administration.	Clients, executives, and stakeholders who need source-backed visibility without the ability to change setup, invite users, export data, or manage integrations. See related surface

Permission boundaries

Sensitive actions stay separate from simple visibility.

A client-facing user can review proof without gaining the controls that change billing, users, source setup, exports, retention, or deletion.

Permission area	Allowed roles	Protected action	User impact
Billing and team administration	Owner	Plan checkout, billing portal access, team invitations, invitation revocation, account-level client management, and role assignment remain owner-level responsibilities.	Pricing, rollout, and client access decisions stay with the account owner instead of drifting into every reporting user account. Review boundary
Client and integration administration	Owner	Client creation, source connection, OAuth starts, API key setup, resource selection, sync actions, and connector disconnects require administration rights.	A viewer can inspect proof without accidentally changing the source path that dashboards, reports, and Ask Data answers depend on. Review boundary
Dashboard and Ask Data access	Owner, Analyst, Viewer	Dashboard viewing and supported questions are available to scoped users so they can inspect source-backed answers without broader administration rights.	Clients and internal stakeholders can see evidence and ask supported questions while the product still refuses unsupported or out-of-scope answers. Review boundary
Report and data export	Owner and Analyst	Report exports and source-backed data exports require export permissions and active client scope before the runtime returns a file or package.	Agencies can share report access broadly while keeping downloadable proof and data packages restricted to users with a stronger operating role. Review boundary
Data deletion and retention	Owner	Tenant data deletion and retention routes require data administration permission, client confirmation, and scoped compliance job handling.	Destructive or regulated actions stay out of normal reporting roles and remain reviewable through compliance and audit evidence paths. Review boundary

Client invitations

Invitation states make client access reviewable.

Invitations are part of the access story: buyers need to know what is pending, accepted, revoked, or expired before clients enter a workspace.

State	User sees	Safeguard
Pending invitation	The invited email, role, client workspace, invited-by user, created time, expiry, and pending status can be reviewed before acceptance.	The invitation token is not exposed in listed invitation records, and the accept route requires account, client, invitation, and token context. Review invitation path
Accepted invitation	A valid acceptance creates a client membership and account membership scoped to the invited client so the user enters the intended workspace.	The acceptance path rejects expired or invalid-token invitations before saving membership changes. Review invitation path
Revoked invitation	A pending invitation can be revoked before acceptance, preserving revoked status and the revoke time for access review.	Only pending invitations can be revoked, which keeps accepted and expired invitation records from being rewritten into misleading states. Review invitation path
Expired invitation	Expired invitations are separated from active access so a stale invitation does not silently create workspace access after its allowed window.	The accept flow checks expiry time before membership creation and asks the user to request a fresh invitation when the link is no longer valid. Review invitation path

Workspace scope

Role checks and client checks have to work together.

A role says what a user may do. Client scope decides where that ability applies.

Scope	Buyer sees	Boundary
Account membership	The user belongs to one SIRJ account with a role that controls account-level abilities such as team, billing, clients, integrations, and data administration.	The account id must match before client access or permissions matter, which prevents a user from crossing into another tenant's workspace. Follow scope path
Client list	A membership can include all clients or a specific list of client ids, which determines which client workspaces appear to that user.	Client access fails when the requested client is outside the membership list, even if the user has a role with the requested permission. Follow scope path
Client invitation	An invitation carries account id, client id, email, role, status, invited-by user, expiry, and acceptance or revocation timestamps.	Invitations create scoped access only for analyst or viewer roles and only when the token is valid before expiry. Follow scope path
Client-facing mode	White-label and portal views can show client-facing dashboards and reports while stripping admin-oriented navigation for viewer-style access.	Branding changes presentation, not source scope, report evidence, role limits, or the underlying client workspace boundary. Follow scope path

Access workflow

From first owner to client-safe reporting access.

SIRJ shows the operating sequence: create the owner, choose a client workspace, invite scoped collaborators, check permissions before actions, and keep access visible during reporting.

Create the account owner Create or select the client workspace Invite scoped collaborators Check permission before action Keep access visible during reporting

Workflow

Create the account owner

The first account path gives the owner the commercial and administrative controls needed for plan choice, billing, team setup, client workspaces, integrations, and compliance actions.

Account setup and billing pages explain plan intent, signup, checkout, trial state, billing portal, and the first workspace route after account creation.

Open related step

Workflow

Create or select the client workspace

The owner or permitted operator creates a client workspace, then source records, dashboards, invitations, branding, reports, and weekly delivery stay tied to that client boundary.

Client workspaces show the agency overview and the selected workspace path that owns the source-backed proof.

Open related step

Workflow

Invite scoped collaborators

Invitations route collaborators into an analyst or viewer role for the intended client workspace, with status, expiry, token validation, and revocation states.

The invitation acceptance page and client access runtime show how the invite link becomes scoped workspace access or a visible invalid-link state.

Open related step

Workflow

Check permission before action

Every sensitive route should confirm client scope and the required permission before allowing exports, billing, integration setup, client management, retention, or deletion actions.

Security, exports, and audit pages show the runtime checks and reviewer paths behind protected actions.

Open related step

Workflow

Keep access visible during reporting

As dashboards, Ask Data answers, white-label reports, weekly delivery, and exports are shared, the role and client boundary should remain visible enough to explain who can inspect or move proof.

White-label reporting, reports, weekly insights, and exports keep client-facing proof separate from administration and data-exit controls.

Open related step

Access standards

Access controls should protect proof without slowing review.

These standards explain what SIRJ keeps separate when dashboard visibility, Ask Data access, exports, administration, and deletion are evaluated.

Standard

Do not give viewers administration controls

Client-facing users often need dashboard visibility, but giving them integration, billing, export, deletion, or team controls can create avoidable reporting and security risk.

Viewer access is limited to dashboard and supported-question permissions, while owner and analyst roles hold stronger operating permissions.

Standard

Do not skip client scope checks

A role is not enough by itself; the same analyst should not see another client workspace unless their membership includes that client.

Client access checks require account match and client id scope before the requested permission is evaluated.

Standard

Do not expose invitation secrets

Invitation links create access, so listed invitation records and public surfaces must avoid exposing token hashes or reusable secrets.

Client invitation API responses redact token hashes and the acceptance path requires the one-time token before creating membership.

Standard

Do not let export access imply deletion access

Exporting a report or data package is operationally different from deleting tenant data or running retention jobs.

Report export, data export, data deletion, and retention actions have separate permissions and API checks.

FAQ

Roles and permissions, answered plainly.

Can clients get access without seeing every agency client?

Yes. Client invitations create membership for the intended client workspace, and client access checks prevent users from opening a client outside their allowed scope.

Can viewers export reports?

No. Viewers can inspect dashboards and ask supported questions, while report and data export are limited to users with export permissions.

Who can manage integrations?

Integration administration belongs to users with integration management permission, which keeps source setup and disconnect actions away from normal client-facing viewers.

Are billing and data deletion separated from reporting?

Yes. Billing, team management, data deletion, and retention jobs are separate administrative abilities, not implied by dashboard, Ask Data, or report visibility.

Access review

Show clients the proof without opening every control.

Review client workspaces, role boundaries, white-label reporting, exports, and audit evidence before inviting collaborators into SIRJ.

Review client workspaces Open security controls

Roles and permissions keep client proof visible without opening every control to every user.

Make access clear before client reporting spreads.

What roles does SIRJ support?

Can a user be limited to one client workspace?

How do invitations work?

Which actions are restricted?

Owner, analyst, and viewer roles carry different access.

Sensitive actions stay separate from simple visibility.

Invitation states make client access reviewable.

Role checks and client checks have to work together.

From first owner to client-safe reporting access.

Create the account owner

Create or select the client workspace

Invite scoped collaborators

Check permission before action

Keep access visible during reporting

Access controls should protect proof without slowing review.

Do not give viewers administration controls

Do not skip client scope checks

Do not expose invitation secrets

Do not let export access imply deletion access

Roles and permissions, answered plainly.

Can clients get access without seeing every agency client?

Can viewers export reports?

Who can manage integrations?

Are billing and data deletion separated from reporting?

Show clients the proof without opening every control.

Preparing the source route.

Roles and permissions keep client proof visible without opening every control to every user.

Make access clear before client reporting spreads.

What roles does SIRJ support?

Can a user be limited to one client workspace?

How do invitations work?

Which actions are restricted?

Owner, analyst, and viewer roles carry different access.

Sensitive actions stay separate from simple visibility.

Invitation states make client access reviewable.

Role checks and client checks have to work together.

From first owner to client-safe reporting access.

Create the account owner

Create or select the client workspace

Invite scoped collaborators

Check permission before action

Keep access visible during reporting

Access controls should protect proof without slowing review.

Do not give viewers administration controls

Do not skip client scope checks

Do not expose invitation secrets

Do not let export access imply deletion access

Roles and permissions, answered plainly.

Can clients get access without seeing every agency client?

Can viewers export reports?

Who can manage integrations?

Are billing and data deletion separated from reporting?

Show clients the proof without opening every control.