The workflow before#
Continental Properties builds and operates real estate, and its reporting already ran on Microsoft Fabric, dbt and Power BI. The tools were modern; the rules around them weren't. Access had been granted one request at a time, with no target model for who should see which properties or figures. Ownership, definitions and lineage lived in people's heads, so when a number looked off, someone had to track down the person who knew. The dbt code had grown with the business and become slow and costly to run. Leadership wanted to put AI to work on company data but had no way to tell whether the data was ready for it.
What we built#
We gave Continental a governed foundation in three parts: an access model so each person sees only what their role allows, a catalog that says who owns each dataset and where it comes from, and a leaner dbt project that costs less to run. Then we tested how AI tools would perform on top of it before anyone committed to building one.
Access that follows the role
We designed a target-state access model on Entra ID with role-based groups, enforced in Power BI with row-level security. A regional manager opens the same report as the finance team and sees only the properties and figures their role covers. We tied access to groups instead of individual grants, so a new hire or a role change updates permissions in one place.
A catalog with named owners
We stood up DataHub as the data catalog, holding metadata, lineage from source to report, data owners and a business glossary. When someone questions a figure, they can trace it back and see who owns it. Putting definitions in one shared glossary means finance and operations work from the same meaning of each term.
A leaner, cheaper dbt project
In a 24-week stream we refactored the dbt project, consolidating models, moving the heaviest ones to incremental builds and cutting redundant runs. Pipelines finish faster and cost about 30% less to run. We refactored in place, so the reports people relied on kept working throughout.
An honest test of AI readiness
Rather than launch an AI tool and hope, we built lightweight semantic model prototypes and tested AI tools and prompt quality against them. The evaluation showed where answers held up and where the data needed more modeling first. Leadership came away with a specific list of work to finish before production use.
How we delivered it
The work ran as parallel streams: access design and the catalog, the 24-week dbt refactor, and the semantic layer evaluation. We worked with Continental's data team on each and documented the access model and catalog so the team could run them after handoff. The AI work stayed an evaluation by design; nothing reached users until the data was ready for it.
Before and after#
| Measure | Before | After |
|---|---|---|
| Report access | Granted ad hoc | Role-based, with row-level security in Power BI |
| Data ownership and lineage | Undocumented | Cataloged in DataHub with named owners |
| Pipeline run cost | Baseline | About 30% lower |
| AI readiness | Unknown | Tested against prototype semantic models |
What's next#
With governed access, a catalog and tested semantic models in place, Continental can build an analytics assistant over its property and financial data. Because the access model already lives in Entra ID and Power BI, the assistant can respect the same row-level permissions people have today. No one will see more through AI than they could in a report.
