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 how SIRJ records audit actions, report exports, compliance data exports, deletion jobs, retention tables, and failed output states for governed client reporting.
Buyer questions
The page separates audit events, report export records, compliance data packages, deletion jobs, and retention review so each reviewer knows which evidence path to inspect.
SIRJ records product actions such as integration connection changes, credential refreshes, resource selection, credential access, tenant data export, tenant data deletion, report export, and billing updates when those actions move client reporting data or change account state.
A reviewer can understand which actions are designed to leave a trail before a client workspace relies on SIRJ for reporting evidence.
Open evidence pathReport exports create scoped report snapshots, PDF export results, completed or failed status, output references, byte length when available, and an audit log entry tied to the requesting user and client workspace.
Exported reports are treated as compliance-relevant artifacts, so the account can review whether a report completed, failed, or produced retrievable output.
Open evidence pathTenant data export covers client memberships, invitations, notifications, integration connections, credentials, sync states, sync runs, raw payloads, normalized events, attribution matches, dashboard snapshots, Ask Data cache, report snapshots, and report export records.
The export path names the operational records reviewers care about instead of hiding them behind a vague data portability claim.
Open evidence pathCompliance deletion jobs process scoped tenant records in a defined order, and retention review focuses on attribution matches, normalized events, and raw integration payloads with the public retention boundary explained before rollout.
Legal and privacy reviewers can separate data export, deletion, and retention expectations before production client data is connected.
Open evidence pathAudit map
Source setup, credential handling, report export, tenant data jobs, and billing events should not collapse into one vague compliance statement. Each action has a different reviewer and proof path.
Recorded actions
These are the public review categories behind the audit trail: source changes, credential-sensitive actions, setup updates, report exports, tenant data jobs, and billing state changes.
| Action | Reviewer sees | Evidence path |
|---|---|---|
| Integration connected or disconnected | Connection state changes can be tied to the account, client workspace, actor, integration, and the reporting source that was added or removed. | Integration detail, connector health, setup manifest, and audit action records explain how a source entered or left the reporting workflow. |
| Credential refreshed or accessed | Credential-sensitive actions are named separately from ordinary data reads so security reviewers can focus on the highest-sensitivity access events. | Security and connector setup pages explain credential handling while audit actions label credential refresh and access activity. |
| Integration setup updated | Resource selection and setup changes identify which source resources are expected to feed dashboards, Ask Data answers, reports, and exports. | Source coverage, custom connector planning, and integration setup pages explain how selected resources become source-backed reporting inputs. |
| Report exported | Report export records include status, snapshot id, format, output reference, byte length, error message, requester, and completion timestamp when available. | Reports, sample report, exports, and report-export runtime code show how a client-ready artifact becomes a reviewable event. |
| Data exported or deleted | Compliance jobs distinguish tenant data export from deletion and preserve job type, status, table counts, output references, errors, requester, and timestamps. | Exports, privacy, disclosures, and compliance runtime paths explain what can leave the product and how scoped deletion jobs are tracked. |
| Billing updated | Billing changes are treated as account-level events separate from source and reporting actions so finance can review commercial state without touching data proof. | Pricing, billing limits, and plan comparison pages explain the commercial path connected to the billing update action. |
Compliance packages
Compliance review moves faster when the buyer can distinguish a tenant data export, deletion job, raw-event retention boundary, and report export artifact.
| Package | Records | Review use |
|---|---|---|
| Tenant data export | Client memberships, invitations, notifications, connections, credentials, sync states, sync runs, raw payloads, normalized events, matches, dashboard snapshots, Ask Data cache, report snapshots, and report exports. | Use when a customer needs a scoped package that explains which client reporting records can be exported for review. |
| Tenant data deletion | Deletion runs through notification, report, Ask Data, dashboard, attribution, normalized event, raw payload, sync, credential, connection, invitation, and membership records. | Use when privacy or legal review needs to understand deletion order and the scoped records involved in removing a client workspace. |
| Raw event retention | Retention review focuses on attribution matches, normalized events, and raw integration payloads, with the default raw-event retention boundary documented for buyer review. | Use when procurement needs to separate active reporting records from raw source evidence and retention expectations. |
| Report export evidence | Export requests, results, snapshot ids, formats, output references, byte length, completion status, errors, and audit log entries stay tied to the requesting user. | Use when finance, legal, or client-facing leaders need confidence that exported reports are not anonymous screenshots. |
Review workflow
Audit and compliance evidence has to stay connected to tenant scope, output status, public policy pages, and Enterprise planning when custom governance is required.
| Step | What happens | Visible proof |
|---|---|---|
| Identify the reviewed action | Start by separating source setup, credential activity, report export, tenant data export, tenant data deletion, and billing changes so reviewers know which control they are inspecting. | The audit action list names the events that matter for security, finance, legal, and client-reporting review. |
| Confirm tenant and client scope | Compliance and report-export paths assert active account and client scope before using dashboard snapshots, export history, or tenant data rows. | The review can see that records belong to the same account and client workspace before they become an export or report artifact. |
| Record completed and failed states | Exports and compliance jobs preserve completed or failed states instead of treating failure as an invisible operational detail. | A reviewer can distinguish completed exports, failed PDF rendering, failed compliance jobs, output references, and error messages. |
| Route policy questions to public pages | Audit evidence is paired with Trust Center, Privacy, Terms, Disclosures, Security, and Exports routes so policy review does not depend on private sales notes. | Each compliance row sends reviewers to the public page that explains the control, output, policy, or product boundary. |
| Use Enterprise for custom retention or destinations | When a buyer needs custom retention, SSO, private connectors, custom workspace volume, or custom destinations, the path belongs in Enterprise rollout planning. | Enterprise, custom connector, and procurement pages keep governed requirements visible before production reporting depends on them. |
Proof standards
These standards keep the page from turning into vague security copy: no recordless claims, no unscoped exports, no hidden failed output, and no custom governance outside Enterprise planning.
The page maps buyer-facing claims to audit action labels, compliance job records, report export results, and public policy routes.
Compliance export and report export paths assert tenant scope before records, snapshots, export history, or output artifacts are used.
Export and compliance results preserve failed states and error messages so the account can review what happened.
The page routes custom governance needs to Enterprise while keeping public self-serve export, deletion, retention, and report evidence boundaries explicit.
FAQ
The FAQ keeps account-specific records separate from public review guidance while still naming the evidence paths buyers should inspect.
No. This public page explains the actions and records SIRJ is designed to track. Actual account-specific audit records belong inside the authenticated product and scoped account review paths.
Security reviewers usually care most about credential access, credential refresh, integration connection changes, source resource selection, report exports, tenant data exports, and data deletion jobs.
Yes. Report export results and compliance job results preserve failed states and error messages so failed output is reviewable instead of silently disappearing.
Custom retention, custom destinations, SSO, private connectors, and custom workspace volume should be reviewed through Enterprise rollout planning before production reporting depends on them.
Ready when the numbers need to hold up
Start with the Trust Center, then follow audit actions, export paths, privacy review, and Enterprise rollout planning.