Cross-system reporting built on the warehouse, with metrics defined once.
Some questions need CRM, ERP and claims data at the same time. Those get answered on the warehouse. We build that BI on Snowflake, Databricks or Fabric, in Power BI or Tableau, with a semantic model that defines each metric once and filters rows by identity group.
Snowflake or Databrickscertified martsOneLake Delta tablesFabric lakehouse
02 · Semantic layer
Semantic modelPower BI · dbt · semantic viewsIdentity groupsEntra ID · Okta
03 · BI tools
Power BIDirect Lake · ImportTableaupublished data sources
04 · Viewers
Business usersfinance · operations · regions
Microsoft FabricSnowflakeDatabricksdbt
in short·15-second read
Analytics business intelligence turns warehouse data into reports and dashboards that combine many sources.
Cohash builds BI on Snowflake, Databricks and Microsoft Fabric with Power BI and Tableau. We design semantic models that define metrics once, use Direct Lake on Fabric where it fits, and apply row-level security based on identity provider groups, so every report shows each viewer only their data.
you probably need this if
The same revenue figure comes out differently in Power BI and Tableau.
Your Power BI Premium P SKU capacity needs to move to a Fabric F SKU.
Someone keeps row-level security up to date by hand in every report, rather than from identity groups.
Power BI developerAnalytics engineer (dbt)Semantic model developer
Microsoft Certified: Power BI Data Analyst Associate
Microsoft Certified: Fabric Analytics Engineer Associate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Business Intelligence, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · business intelligence3 open
openThe same revenue figure comes out differently in Power BI and Tableau.
recurringYour Power BI Premium P SKU capacity needs to move to a Fabric F SKU.
blockedSomeone keeps row-level security up to date by hand in every report, rather than from identity groups.
exposure
Semantic modelsPower BI on FabricTableau on the warehouseRow-level security from identityReport rationalizationPower BI Premium migration
startrehearsehandover
Inventory
Define metrics
Build
Adopt
we are here
ready to hand over
Workspaces move before the subscription ends and viewers keep access.
Tableau and Power BI now show the same member count, from one definition.
Report and data set inventory
Metric dictionary with owners
chapter 01 · where it hurts
Why teams reach out
The same revenue figure comes out differently in Power BI and Tableau.
Your Power BI Premium P SKU capacity needs to move to a Fabric F SKU.
Someone keeps row-level security up to date by hand in every report, rather than from identity groups.
chapter 02 · what we change
How we solve it
Semantic models
Power BI on Fabric
Tableau on the warehouse
Row-level security from identity
Report rationalization
Power BI Premium migration
chapter 03 · how it runs
Our approach
Inventory
Define metrics
Build
Adopt
chapter 04 · where you end up
What changes
Workspaces move before the subscription ends and viewers keep access.
Tableau and Power BI now show the same member count, from one definition.
Report and data set inventory
Metric dictionary with owners
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Power BI semantic models, Snowflake semantic views or dbt's semantic layer, with metric definitions agreed with finance and operations before anyone builds a chart.
Direct Lake models on Delta tables in OneLake for large data sets, Import where it's the better fit, and F SKU capacity sized against real usage.
We publish data sources on Snowflake or Databricks and pick live or extract connections one workload at a time.
We drive security roles from Entra ID or Okta groups, so a region manager's access changes when their group does.
We retire duplicate and unused reports first, so there's less to move. The survivors go onto certified data sets.
We move workspaces off retiring P SKUs onto Fabric F SKUs, and measure capacity before and after so the sizing isn't a guess.
capability 01 / 06in production
Semantic models
Power BI semantic models, Snowflake semantic views or dbt's semantic layer, with metric definitions agreed with finance and operations before anyone builds a chart.
We pieced these together from Business Intelligence situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
A P1 capacity, a few hundred workspaces and an agreement that ends in spring
composite · not a client story
Beforethe situation
Several hundred workspaces sit on one Power BI Premium P1 capacity. The enterprise agreement runs out in the spring, and Microsoft has stopped selling new P SKUs. Nobody has counted how many viewers depend on Free licenses, or checked whether any workspace has to change region.
What we dothe work
We pull load from the Fabric Capacity Metrics app and size the F SKU, starting at F64 because that keeps Free-license viewing. Large storage format models and Fabric items are listed in case a region move comes up. Then we buy the F SKU, reassign workspaces in batches and cancel the P SKU only after every batch is validated.
Afterwhere you end up
Workspaces move before the subscription ends and viewers keep access. Capacity is sized from measured load, not a straight P-to-F swap.
case file 02
Several definitions of 'active member' across Tableau and Power BI
composite · not a client story
Beforethe situation
Analysts publish in Tableau and Power BI, and the active member counts don't match. Each report filters eligibility spans its own way. Row-level security is a hand-kept table of email addresses.
What we dothe work
We gather every version of the metric and put them in front of the business owner until one definition is written down. That definition goes into a shared semantic model on the warehouse. Row-level security moves off the email table onto Entra ID security groups, and we retire duplicate reports after telling their owners.
Afterwhere you end up
Tableau and Power BI now show the same member count, from one definition. Put someone in the right group and they see the right rows. Take them out and the rows go too.
How warehouse BI defines metrics once and filters by identity group
Certified tables in Snowflake, Databricks or OneLake feed a semantic model that defines each metric once. Power BI uses Direct Lake or Import and Tableau uses published data sources, with row-level security driven by Entra ID or Okta groups.
01 · Warehouse
Snowflake or Databrickscertified marts → Semantic model · certified tables→ Tableau · live or extract
OneLake Delta tablesFabric lakehouse → Semantic model · Direct Lake
02 · Semantic layer
Semantic modelPower BI · dbt · semantic views → Power BI · measures
Identity groupsEntra ID · Okta → Semantic model · RLS role membership
03 · BI tools
Power BIDirect Lake · Import → Business users · filtered reports
Tableaupublished data sources → Business users · filtered dashboards
04 · Viewers
Business usersfinance · operations · regions
Read the diagram as text
Snowflake or Databricks → Semantic model: certified tables
OneLake Delta tables → Semantic model: Direct Lake
Identity groups → Semantic model: RLS role membership
Semantic model → Power BI: measures
Snowflake or Databricks → Tableau: live or extract
Power BI → Business users: filtered reports
Tableau → Business users: filtered dashboards
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Inventory
We catalogue reports, data sets, users and refresh schedules, with usage data from the BI platform.
step 02
Define metrics
Key metrics written down with owners, sources and calculation rules.
step 03
Build
We build semantic models and reports on certified data, then test two things. Are the numbers right, and who can see them?
step 04
Adopt
Training, a request process for new reports and retirement of the old ones.
you keep
What you're left with
We write these for your Business Intelligence setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Business Intelligence work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you decide which of our reports to retire instead of rebuild?
Large BI estates are mostly reports nobody opens. Usage from the Power BI activity log or Tableau's admin views should drive the cut, or you pay to migrate dead content.
Q2
Where will you define each metric? And if a report author wants to redefine it, what stops them?
Metrics that live inside individual reports drift again within months. Ask about certified semantic models, endorsement and who can publish to shared workspaces.
Q3
How will row-level security follow our identity groups when people change jobs?
Static lists of email addresses go stale. Roles mapped to Entra ID or Okta groups pick up joiner, mover and leaver changes without anyone editing a table.
Q4
How will you size our F SKU, and what happens on our busiest refresh day?
Microsoft's P-to-F table compares compute. It isn't a sizing or licensing equivalence. Month-end refreshes decide whether you get throttled, so ask to see the capacity metrics behind the number.
Q5
For which of our models would you choose Import over Direct Lake?
Direct Lake has limits and can fall back to DirectQuery. A partner should say which of your models fit and prove it on your data before committing.
01How is this different from your enterprise platforms BI work?
Our enterprise platforms BI service handles reporting inside Salesforce, Dynamics 365 or the ERP, for the people who work in those apps. This one is for reporting on the warehouse, where data from lots of systems gets joined and governed.
02Do we need to migrate off Power BI Premium?
If you run P SKUs, yes. Microsoft has stopped selling new P SKUs and each one ends at the end of its agreement term, followed by a grace period. Pro and Premium Per User aren't affected. We'll plan the move to an F SKU and check the sizing.
03Power BI or Tableau?
Usually whichever one you already license and know. Power BI fits Microsoft 365 and Fabric shops. Tableau is common where Salesforce is big, and with analysts who like exploring visually. We build on both.
04Should we use Direct Lake?
Direct Lake is a good fit for large Delta tables in OneLake, where Import refreshes take too long. It needs Fabric capacity, and it has limits. In some setups it quietly falls back to DirectQuery. So we normally prototype it on your own data first.
05What happens if our P SKU subscription ends before we finish moving?
Microsoft gives a 30-day grace period at the current size. From day 31 interactive operations are throttled, and from day 91 all operations are rejected until workspaces move to an F SKU or the capacity is deleted. We plan reassignment well before the end date so none of that applies.
related
Often paired with
Projects on Business Intelligence usually end up touching one of these, so they're worth a look.
