Customer reporting architecture guide
What should customer-facing reporting architecture include?
Build customer reporting as a controlled service: governed data, customer identity, tenant-aware access, a stable serving contract, useful presentation and a clear path from insight to action.
The direct architecture
Use five explicit layers: source and analytical data, governed business meaning, customer identity and entitlement, a customer-facing serving layer, and the reporting experience. Add a separate operational path for queries, approvals or other actions. This keeps report reads predictable and prevents the data warehouse or BI tool from becoming an accidental customer application.
The customer-facing layer should resolve the signed-in user to an organisation, apply data scope on the server, return only approved fields and preserve the report context when a customer takes action.
01
Give each architecture layer one responsibility
| Layer | Owns | Must not assume |
|---|---|---|
| Source systems | Transactions, master records and operational states | That their internal schema is a safe customer contract |
| Reporting model | Integrated history, definitions, calculations and quality rules | That every record is suitable for every customer |
| Serving layer | Tenant scope, response shape, limits, caching and versioning | That a browser or report filter is an access-control boundary |
| Experience | Navigation, explanation, visualisation, export and accessibility | That a chart alone explains the next step |
| Workflow | Requests, evidence, approvals, assignment and status | That an analytical store should process transactions |
02
Resolve identity, organisation and entitlement before querying data
A login establishes who the user is. It does not by itself determine which customer accounts, branches, contracts, reports or export fields that person may access. Model the full relationship:
- user identity and authentication method;
- organisation membership and delegated administration;
- roles, permissions and any account hierarchy;
- governed mapping to reporting customer keys;
- report, row, column and export entitlements; and
- internal support access with reason and audit history.
Apply access rules on the server and in every downstream analytical query. Test alternate identifiers, filters, cached responses, downloads and embedded reports for cross-customer exposure. See how to securely expose business data to customers.
03
Publish governed meaning, not raw database structure
A reporting model should explain the grain, formula, period, timezone, currency, exclusions and owner of each important measure. Customer labels should remain understandable even when source tables or integration tools change.
Keys
Stable customer mapping
Reconcile ERP, CRM and reporting identifiers to an approved organisation model.
Measures
One calculation owner
Define business logic once and validate it against approved reference reports.
Freshness
Visible data timing
Show the source cut-off and last successful refresh, not only the page load time.
Lineage
Investigable results
Retain enough source context to resolve a disputed number without exposing internals.
Microsoft describes semantic models as an abstraction that centralises relationships, calculations and row-level security for read-heavy analytical use. That layer helps reporting consistency, but the customer application still owns the customer journey.
04
Choose the reporting delivery pattern by customer need
| Pattern | Best fit | Architecture concern |
|---|---|---|
| Custom reporting views | Focused measures and a tailored customer journey | Query design, visualisation ownership and accessibility |
| Embedded analytics | Interactive exploration and mature BI capabilities | Embedding identity, tenant isolation, capacity and licensing |
| Generated reports | Periodic statements, formal outputs or expensive calculations | Versioning, secure storage, expiry and download audit |
| Customer API | Customers need data in their own systems | Stable contracts, quotas, versioning and support |
| Hybrid portal | Customers need insight, files and workflow together | One identity, navigation and support experience |
For a format decision, compare a dashboard, portal and custom application.
05
Design for customer trust and predictable performance
- Set a freshness commitment for each report and expose late or partial refreshes.
- Use bounded filters, paging, caching and queued exports for expensive workloads.
- Reconcile totals and representative customer records before every material release.
- Separate live operational status from slower analytical history when necessary.
- Provide definitions, limitations and a route for customers to query a result.
- Monitor failed queries, slow reports, stale data, access denials and export volume.
06
Run reporting as a service, not a set of pages
Assign owners for source data, measure definitions, access policy, refresh pipelines, customer support and platform operations. Define how teams respond when a pipeline is late, a measure changes, a customer disputes a number or an access mapping is wrong.
Keep the customer, report, period, filters and selected record attached to every question. This avoids reconstructing the evidence from screenshots or email and prepares the architecture for customer reporting workflows.
07
Deliver one trusted reporting journey first
- Define the customer decision and measurable service outcome.
- Map source ownership, customer keys, definitions and refresh timing.
- Model representative users, organisations, roles and export rights.
- Choose the smallest serving and presentation pattern that fits.
- Prototype the highest-risk query, access rule and customer action.
- Reconcile results and test security, performance and failure states.
- Pilot with real customers, measure adoption and improve before scaling.
Sources
Primary references
Questions
Frequently asked questions
What is customer-facing reporting architecture?
It is the set of data, identity, access, serving, presentation and workflow components that deliver trusted reports to external customers. It defines how a customer is identified, which data they may see, how measures are calculated and what happens when they act on a result.
Should customers query a data warehouse directly?
Usually no. Put a controlled application, semantic or serving layer between the customer and analytical storage. This layer should enforce tenant scope, shape responses, limit workloads and keep the customer contract stable while internal models change.
Can customer reporting include real-time data?
Yes, but not every measure needs the same latency. Combine governed historical reporting with live operational APIs for statuses or actions that must reflect the current system state, and label freshness clearly.
Is embedded BI enough for customer reporting?
Embedded BI can provide capable analysis and visualisation. The surrounding application still needs to own customer authentication, onboarding, tenant separation, navigation, support and any operational workflow.
What should you build first?
Start with one customer decision, one trusted dataset, a representative set of customer roles and one useful follow-up action. Prove security, freshness, performance and reconciliation before expanding the reporting catalogue.
Design the reporting service
Bring one report, its source data and the customer action it should support.
LCR can help define the smallest secure architecture that turns trusted reporting into a useful customer experience.