White-Label Outreach Reporting Data Boundaries
A requirements checklist for tenant-scoped client reporting, data minimization, exports, attribution, corrections, and leakage tests.
Product & Engineering · September 25, 2026 · 2 min read
Before you start
A white-label report is safe only when a client can see its own evidence without seeing another tenant’s data or unnecessary recipient details. Evaluate it as a set of scope, minimization, attribution, export, and correction requirements. Branding alone does not establish isolation.
Requirements checklist
| Requirement | Pass condition | Test |
|---|---|---|
| Tenant scoping | Every query, view, and export is limited to one authorized client | Attempt an adjacent-client ID and verify no result |
| Metric attribution | Client, campaign, identity, period, and denominator are visible | Compare dashboard total with source event total |
| Minimization | Recipient-level fields are hidden unless required | Review role-based views and exports |
| Access boundaries | Agency staff and client users see only intended scopes | Test owner, reviewer, and read-only roles |
| Export control | Export includes scope, timestamp, source, and no unrelated rows | Export two clients and diff for leakage |
| Correction workflow | A wrong metric can be corrected with history | Submit a test correction and inspect audit trail |
| Deletion/suppression | Lifecycle actions do not silently erase required safety controls | Test an opt-out and later import |
Use the agency tools comparison for evaluation context, but verify current product behavior rather than inheriting marketing language. The observability guide provides a useful source-to-report model.
Minimum report contract
For each metric specify who may view it, what source produced it, which period and denominator apply, how it is corrected, and how long it is retained. Prefer aggregated counts when individual recipient records are not required. Do not show a campaign total without identity and client scope; a number that combines tenants cannot support a client decision.
Acceptance tests
- Log in as Client A and confirm Client B’s campaigns, recipients, names, links, and exports are absent.
- Change the URL, filter, API parameter, and download request to another tenant identifier; expect denial or empty scope.
- Verify that a correction changes the visible report without deleting the original audit event.
- Confirm that a suppressed contact remains protected even if a report or export is removed.
No current documentation in this draft proves that any particular product offers white-labeling. Record verified capabilities separately from requirements.
Related internal resources
Sources
Resources in this guide
- Record the owner, scope, evidence link, status, and checked date for each control.
- Mark the item HOLD when required evidence is missing or a decision is uncertain.
- Attach the completed record to the client or incident review before proceeding.
Common mistakes to avoid
- Assuming branding means client data is isolated.
- Showing recipient-level data when aggregated evidence would answer the question.
- Claiming a product is white-label without verifying current documentation.
Frequently asked questions
What must a client report hide?
Hide unrelated client data, unnecessary recipient details, credentials, internal notes, and any field not needed for the client’s agreed decision.
Is a white-label dashboard a product feature claim?
Yes. Verify current product documentation and contract terms before claiming it. This checklist describes requirements and test cases, not RepMail capabilities.
Continue learning
Next: review sending observability
Define the evidence your report can safely expose.