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.
See how SIRJ handles PDF report exports, report history, tenant data exports, retention workflows, destination boundaries, and Enterprise destination planning.
Buyer questions
Buyers need to know whether exports are report artifacts, compliance packages, destination feeds, or custom implementation work.
Users can export client-ready PDF report artifacts from a frozen dashboard snapshot, review export history, and use compliance workflows for scoped tenant data export when permissions allow it.
The buyer sees a practical output path for client reporting and governance instead of a vague promise that data can be downloaded later.
Follow the export proofYes. The PDF export path creates a report snapshot from the active dashboard, records the snapshot id, renders report HTML, and saves export status instead of rebuilding a separate version of the metrics.
A client-facing export should match the dashboard evidence the team already inspected, including source breakdown, campaign performance, attention items, and recommendations.
Follow the export proofCompliance export workflows package allowed tenant tables under the active account and client scope, return table metadata, and avoid echoing raw record payloads through the API response.
Governance teams get a scoped export path without turning every report or API response into a raw-data leak.
Follow the export proofPublic SIRJ exports focus on reports, report history, and scoped compliance packages. Warehouse, BI, or private destination work should be scoped through Enterprise so source requirements, security, retention, and rollout order are explicit.
The destination boundary is clear: use public exports for proof artifacts and compliance needs, and use Enterprise for custom destination planning.
Follow the export proofOutput map
SIRJ separates report exports, export history, compliance packages, retention workflows, and custom destination planning so users do not mistake one output type for another.
Export surfaces
This table shows what users see and the product path behind each export or destination-planning surface.
| Surface | User sees | Source path |
|---|---|---|
| PDF report export | A client-ready PDF output created from a frozen report snapshot, with export status, output reference, storage key, byte length, and failed-renderer handling. | Dashboard config -> report snapshot -> report HTML -> PDF renderer -> report export result and audit log. |
| Report export history | A bounded list of report export records for the active tenant and client, including status, format, output reference, storage key, byte length, and errors. | Request context permission -> report store listReportExports -> tenant-scope assertion for each export result. |
| Scoped data export package | A compliance export job that returns table names, row counts, account/client scope, storage reference, and job status without putting raw records in the response body. | Compliance job -> allowed tenant tables -> package writer -> saved compliance job -> audit log. |
| Retention workflow | A retention run with a retention window, cutoff, table-level plan, deletion summary, and saved compliance job so expired event data can be pruned intentionally. | Retention request -> tenant data retention plan -> deleteExpiredTenantRows per allowed table -> audit log. |
| Enterprise destination planning | A scoped planning path for custom warehouses, BI tools, or private destinations when public report and compliance exports are not enough. | Enterprise scope -> source and destination requirements -> setup gates -> rollout order -> security and retention review. |
Destination boundaries
A strong export story increases trust by naming what is supported today and what belongs in a governed Enterprise rollout.
| Boundary | Buyer impact | Safeguard |
|---|---|---|
| Public exports are proof artifacts first | Most buyers need a report clients can read, an export history the team can audit, and a scoped data package for governance before they need a warehouse pipeline. | The public product story keeps PDF reports, report history, and compliance export packages separate from custom destination promises. |
| Raw record access stays scoped | Export controls lose trust if raw tenant records can be returned through casual UI requests or cross-client contexts. | Compliance export APIs return package metadata while tenant-scope checks and table allowlists protect records and clients. |
| Unavailable destinations are not hidden | A buyer comparing SIRJ with broad data-pipeline platforms needs to know whether SIRJ is the right system of record or the proof layer that feeds a later destination. | The page names custom warehouse, BI, and private destination work as Enterprise scope instead of implying every destination is self-serve. |
| Retention and deletion are not report exports | Governance actions have different permissions and risk than sending a client report, so they should not be bundled into a single download button. | Report exports, compliance exports, deletion, and retention use separate runtime paths, permission checks, saved jobs, and audit logs. |
Export workflow
Reports and compliance packages should preserve scope, status, and auditability from request through output.
| Step | What happens | User-visible proof |
|---|---|---|
| Freeze the reporting context | SIRJ creates a report snapshot from the active dashboard, preserving account scope, client scope, date range, client branding, dashboard cards, metrics, recommendations, and generated timestamp. | The exported artifact has a snapshot id and can be traced back to the dashboard metrics used for the client-ready report. |
| Render the report artifact | The report export path renders report HTML from the frozen snapshot and passes filename, scope metadata, generated timestamp, and branding to the PDF renderer. | The PDF output is created from the same report HTML surface that the product can inspect and test before export. |
| Record export status | Completed and failed exports are both saved with format, output reference, storage key, byte length, error message, and completion timestamp when a report store is available. | The user can distinguish successful exports from renderer failures without losing the audit trail for the attempt. |
| Package compliance export metadata | Compliance export jobs collect allowed tenant tables, write a scoped package through the configured writer, save the job, and return table metadata rather than raw rows. | Governance users can confirm what table groups were packaged and where the export was written without exposing records in the UI response. |
| Scope custom destinations separately | If a buyer needs warehouse, BI, or private destination work, the Enterprise path scopes destination requirements, security review, retention terms, and implementation order before launch. | Custom destinations become an implementation plan instead of a public feature claim that the current product surface does not support. |
Proof standards
These standards keep exports scoped, auditable, and honest about what leaves SIRJ.
The export path creates a report snapshot from the dashboard, then renders the artifact from that snapshot.
Report and compliance export paths require explicit permissions and assert tenant scope before returning export results.
Compliance export responses return package/table metadata while the package writer handles storage outside the response body.
SIRJ routes custom destination work through Enterprise planning where source records, destination format, retention, security, and rollout order can be documented.
FAQ
Clear export answers keep buyers from guessing whether SIRJ is a report proof layer, a compliance package path, or a custom destination project.
Yes. The report export path creates a dashboard-backed report snapshot, renders report HTML, sends it to the PDF renderer, and records completed or failed export status.
Yes. Export history is read through a permissioned report-store path and each returned export is checked against the active tenant and client scope.
Yes. Compliance export jobs package allowed tenant tables under account and client scope, save the job, and return table metadata instead of raw records through the API response.
Public exports focus on reports, export history, and compliance packages. Warehouse, BI, or private destination work should be scoped through Enterprise planning.
Ready when the numbers need to hold up
Review the sample report first, then scope Enterprise destination requirements when warehouse, BI, or private export needs determine rollout.