The workflow before#
A Core works in construction and concrete, and its clients want to see how their own projects are tracking. The analytics behind that reporting ran on a single data source. Bringing in more data meant reworking the pipeline each time, and there was no way to give one client a view of its records without exposing everyone else's. So client reporting stayed narrow, and anything more ambitious waited. The team knew a quick patch would only push the problem down the road. They wanted to build the foundation once, with security designed in from the start, so they wouldn't spend the next two years paying down shortcuts.
What we built#
We built one Azure data lake that holds every client's data and keeps it apart. Each record carries a tag for the client it belongs to, and access follows that tag all the way from storage to the dashboard. A Core's clients log in and see their own numbers. Nobody sees anyone else's, and nobody had to build a separate system per client to make that true.
Client separation built into the pipeline
The pipeline tags every record with its client as it lands, and Entra ID groups decide who can read which records. We put the boundary in the data layer, not in each report, because a rule enforced once at the source can't be forgotten when someone builds a new dashboard.
Per-client dashboards in Power BI
A Power BI engineer built dashboards on top of the secure layer, so each client opens a view scoped to its own projects. A Core's team maintains one set of reports instead of a copy per client. When a report improves, every client gets the improvement.
Room for new sources
We brought two more data sources into the analytics, taking A Core from one source to three. The lake follows the five pillars of the Azure Well-Architected Framework: operational excellence, security, reliability, performance and cost. That's why the next source plugs in without a rebuild.
How we delivered it
We designed the architecture and the security pattern first, then built the pipeline and brought the new sources in, with a Power BI engineer working alongside our data engineers on the dashboards. Security was tested before any client saw a report, so the first rollout went to clients with the boundaries already proven.
Before and after#
| Measure | Before | After |
|---|---|---|
| Data sources in analytics | 1 | 3 |
| Client data access | No per-client separation | Each client sees only its own data |
| Adding a new source | Rework of the pipeline | Added without refactoring |
| Report maintenance | Narrow, single-source reporting | One set of dashboards scoped per client |
What's next#
With client data separated and governed, A Core can put an assistant in front of it. Each client could ask questions in plain language and get answers drawn only from its own records, using the same access rules that already protect the dashboards. The boundary is already built, so the assistant inherits it.
