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.
How SIRJ keeps client reporting trustworthy with source lineage, stale-data detection, role-aware access, exports, and deterministic metrics.
Buyer answers
Security pages convert when they answer the buyer's practical questions: credentials, client scope, source proof, and data exit paths.
SIRJ stores integration credentials in encrypted envelopes, binds each envelope to account, client, provider, and connection scope, and redacts encrypted material before credentials are displayed or returned.
A connected source can power reporting without exposing raw tokens, refresh secrets, ciphertext, initialization vectors, or authentication tags to users.
Follow the trust pathTenant scope is carried through account IDs, client IDs, memberships, invitations, sessions, and request context before dashboard, report, billing, compliance, or integration actions are allowed.
Agency users can manage many clients without turning one client's revenue, credentials, exports, or reporting history into another client's data.
Follow the trust pathRevenue claims depend on connected source records, normalized events, metric definitions, connector health, attribution rules, and cited dashboard or report output before a user-facing answer is allowed to look complete.
The product earns trust by making the proof path visible and by refusing to turn missing data into a confident client-facing number.
Follow the trust pathCompliance jobs define export and deletion table allowlists, child-first deletion order, retention-managed event tables, readable job labels, and account or client scope before records are packaged or removed.
Trust does not stop at signup. Customers need a visible path to export, delete, and retain data without blending accounts or leaving hidden reporting records behind.
Follow the trust pathTrust controls
Buyers evaluating pricing and integrations need to see the control behind the claim, not a vague security promise.
OAuth and API-key credentials are encrypted with authenticated metadata for account, client, provider, and connection scope before they can support connector syncs.
Credential redaction returns scope and provider context while withholding ciphertext, IV, auth tag, and raw token material.
See related surfaceSessions, memberships, request context, and client workspace permissions decide which account and client records a user can see or mutate.
Dashboard, agency, integration, report, compliance, and invitation tests reject cross-tenant or cross-client access before returning data.
See related surfaceConnector health checks setup requirements, sync cadence, stale states, recent failures, reconnect needs, and severity before reports or Ask Data inherit source confidence.
Health rows show provider state, missing setup, sync history, latest run, and failure count close to the reporting surfaces that depend on them.
See related surfaceAudit records capture sensitive actions, while export and deletion jobs use explicit table allowlists, scoped predicates, and child-first deletion order.
Compliance routes package scoped data, reject out-of-scope rows, delete child records before parent connections, and audit the action.
See related surfaceDeterministic reporting
SIRJ's strongest trust signal is restraint: if a connected stack cannot support a claim, the product names the gap before the dashboard, report, or Ask Data answer looks complete.
Security workflow
The workflow below shows how SIRJ keeps trust controls close to the revenue surfaces buyers care about.
| Step | What happens | User-visible proof |
|---|---|---|
| Resolve tenant scope | Every protected action starts by resolving the active account, user, role, allowed client IDs, and selected client workspace before data reads or mutations continue. | Users see only the dashboards, client workspaces, invitations, reports, and integrations inside their active scope. |
| Protect connected credentials | Credential envelopes encrypt provider secrets with account, client, provider, and connection metadata as authenticated context. | The app can show that a credential exists without revealing the encrypted material or raw provider secret. |
| Validate source readiness | Connector health evaluates credentials, selected resources, setup requirements, sync state, stale windows, recent runs, and severity before source data supports a report. | The health table names missing setup, stale syncs, reconnect needs, and failures before a client-ready number uses that source. |
| Compute only supported claims | Dashboard cards, Ask Data answers, weekly insights, and report exports rely on metric definitions, attribution rules, normalized events, and cited rows. | Unsupported questions return safe gaps instead of invented answers, and report snapshots preserve the dashboard context used for export. |
| Record compliance actions | Exports, deletion jobs, credential changes, billing updates, and integration changes create audit-ready records with account and optional client scope. | Customers have public export, deletion, retention, and disclosure paths that match the product's scoped data model. |
Proof standards
These gates translate the security model into concrete reporting risks: credential exposure, cross-client blending, stale source confidence, and incomplete deletion paths.
Credential redaction strips ciphertext, IV, auth tag, and raw secrets while preserving scoped provider context and a has-credential signal.
Tenant scope checks reject rows and actions outside the active account and client before dashboard, integration, report, or compliance work proceeds.
Connector health computes setup state, cadence, recent runs, and severity before the source is allowed to feel report-ready.
Compliance deletion uses table allowlists, scoped predicates, and child-first order across notifications, reports, Ask Data cache, events, sync records, credentials, and memberships.
FAQ
These answers make the trust model scannable for owners, agencies, finance leads, and security reviewers.
No. Connected credentials are stored in encrypted envelopes and redacted before display. Users can see provider, connection, scope, creation time, and whether a credential exists without seeing the token material.
Client access is scoped through account membership, allowed client IDs, selected client workspace, and role checks. Cross-client rows are rejected before they can influence dashboards, reports, exports, or integration views.
Connector health shows missing setup, stale syncs, disconnected states, provider errors, reconnect needs, and repeated failures close to the reporting surfaces that depend on that source.
Yes. Compliance workflows support scoped data export, deletion, and retention jobs with explicit table allowlists, child-first deletion order, audit records, and role-based permissions.
Ready when the numbers need to hold up
Follow the data-lineage page to see how SIRJ turns source records, validation gates, and trust controls into public buyer proof.