Microsoft Purview is a Trap: The Hard Truth About Data Governance

Microsoft purview isn't something you install, it's already in your tenant, waiting. You don't buy it, you don't go through a vendor evaluation, it's just there. Part of your Microsoft 365 subscription, it sits in the background like a feature you haven't thought about yet, and that's the trap. You flip a switch, there is no procurement gate to stop you, there is no planning meeting, there is no moment that forces you to sit down and ask, what are we actually trying to do here? What question does this catalog answer, who owns the answer? Six weeks later, the collection admin role has sprawled across your organization. Data governance teams can't say who has access to what. Nobody owns a single data product, the catalog is locked down and wide open at the same time. Business users opened it once, found chaos and stopped coming back, you have thousands of assets, you have policies nobody understands, you have roles assigned to people who don't even remember getting them, that's not a tooling problem, that's a rollout problem. This episode is about the structural flaw in how most organizations approach data governance and how to fix it. The problem, why ease becomes a trap? Starting costs nothing, so most teams start with nothing in mind, there is no friction, there is no forcing function, there is no problem. No moment where someone has to justify the investment or define success, you just turn it on and because you can scan without asking why, you do, you scan every source, you hand out access to whoever asks, you build no structure around it, the swamp builds itself, the catalog fills with thousands of assets nobody asked for, the claims table, the payouts table, the customer reference data, the temporary staging area someone created last month and forgot about, all of it flows into the same searchable space, undifferentiated, unlabeled and untouched by strategy. Permission sprawl, you grant collection admin to one team so they can manage their own registrations, then another team needs it, then the finance team, then the risk team, six months later you have 12 collection admins scattered across the organization. Nobody can say who has permission to do what, nobody can audit it, nobody can fix it without breaking someone's workflow, business users open the catalog once, they search for something they care about, they get back 10 results that look nothing like what they need, a raw table name, a technical field description, a timestamp column from a system nobody's heard of. They leave, they never come back, you spend the budget, you turn on the tools. You show leadership the feature, you lost the trust, the real cost isn't the licensing. It's not the storage, it's not even the time spent on misconfiguration, the real cost is the change management you never planned for. The organizational discipline required to make the catalog work, the business alignment that's harder to build after you've already scanned everything than it was to define before you started. Most organizations treat per view like a technology deployment, turn it on, configure it, run some scans, declare victory. But governance isn't technology, governance is structure. It's the deliberate choices you make about ownership, accountability and how information flows. Those choices have to come first. The tool is the byproduct. When you flip the switch without asking why you get a filing cabinet with the lights on, you get organization theater, you get the appearance of control with none of the substance and the deeper the catalog gets, the harder it is to undo. This is the moment where teams realize we moved fast and broke governance, we have to rebuild the entire model, we have to reassign permissions, we have to rename collections, we have to explain to business owners why their data disappeared and then reappeared in a different place, start from that point, from the consequence of doing it wrong and you understand why the right sequence matters. The real failure, big bang versus use case first, teams that end up with a mess don't start out trying to fail, they think they're being rational, they want to catalog the entire data estate, they look at the org chart, finance has data, sales has data, operations engineering claims, they all have data, so the team creates a collection for every department, they scan every single thing those departments own, they try to make every asset discoverable, it feels like progress, it feels like governance, but in reality it's the opposite. The moment you decide to catalog everything you've already failed, not because you didn't work hard enough, but because of your intent you chose to build for completeness, instead of building for a person, that distinction is fatal. Completeness without a specific purpose is just noise, it's a mountain of metadata about things nobody ever asked for, it's organized in a way that makes sense to the platform team, but it means nothing to the person who actually needs an answer, it's a massive failure disguised as total coverage, here is what actually matters, a use case is one sentence, it's one business question that a real human is waiting on right now, it's not, let's catalog our customer data, it's which customers paid their invoices on time for the last five cycles, it's not, we should organize our risk data, it's which loan applicants in the pipeline have a 30% chance of defaulting in year two, it's not, let's make our operational data discoverable, it's which claims are most likely to be fraudulent this quarter, that last sentence is specific enough to define your entire project, it tells you exactly which sources matter, like the policy admin system, the historical claims database and the payout records, it identifies the people who actually need the data, like fraud analysts and claims managers, it even tells you what success looks like, which is a score or a list that someone can actually act on, and it tells you what doesn't matter, you don't need customer service core logs, you don't need billing adjustment tables, you definitely don't need that test data someone created three years ago, none of that helps answer the question, so none of it belongs in the product, one use case pulls the entire rollout forward, when you start with a question instead of a checklist, everything changes, you don't catalog everything, you only register what the question requires, you don't create a claims collection and scan 10 years of archives and backups, instead you only pull in the policy table and the payouts that feed the fraud model, nothing else, you don't give the whole company read access to the catalog, you give it to the fraud team, you give it to the claims managers, you give it to the people who are actually going to use the answer, nobody else needs it yet, you don't build a governance domain for claims and fill it with random volunteers, you find the people who own fraud prevention, you assign one owner maybe two for backup and you let them run it, no committees, no forums, just owners, you don't just scan and hope something useful pops out, you scan the specific sources that answer the question, you build one data product and you test it with the fraud team, you measure if the model works and then you hand it over, that isn't a rollout, it's a pilot, it's controlled, it's focused and it delivers value you can actually see, the big bang approach creates noise and lets people hide from responsibility, everyone sees the data but nobody owns it, the use case first model creates focus, one team, one question, one answer and one owner, the chaos you see in most deployments doesn't come from the tool, it comes from the decision to organize for completeness instead of organizing for a customer. The second you ask, what should we catalog? Instead of what question should we answer, you've chosen noise over signal that one choice ruins everything that follows from your permissions and structure to the trust your users have in the system, now that we see where it breaks, let's look at the structure that actually keeps it together, the four layer permission blueprint, overview, nobody tells you this when you get your purview tenant but access control isn't just one thing, it's four. Most teams find this out the hard way, an analyst asks for read access so you grant it but they still can't see anything, you grant more power and suddenly they see things they shouldn't, you lock it down and now nobody can work, you spend an entire week debugging permissions and you still don't know where the boundaries are. The problem is that purview spreads access across four distinct layers, each one handles a different type of power, they each have their own roles and their own logic and they don't talk to each other, the four layers are the tenant level, the data map, the unified catalog settings and the governance domain, the tenant level is for the platform admins, these are the people who create domains and configure the whole account, they hold the keys to the kingdom and control who has the power to build in the first place, the data map is where the metadata actually lives. This is where you find your collections, your data sources and your scan settings, this layer controls who can see the raw metadata coming from your SQL databases or your fabric workspaces. The unified catalog is your control panel, this is where you assign roles for the glossary, data products and business concepts, it's the layer that manages the actual business meaning of your data. The governance domain is where ownership finally happens, this is where domain owners delegate tasks to stewards and data product owners, it's where the business actually runs the show and defines what the data represents. There are two rules that sit above all of this, if you get these wrong, the whole system falls apart. Rule number one is to always assign roles to intro groups, never to individuals, the moment you start adding people one by one, you lose the ability to manage the system, you lose your audit trail and you create technical debt that will take months to fix, use groups, every single time. Rule number two is to avoid creating a group for every single role in every layer, this is the instinct that kills most projects, you see four layers and dozens of roles, so you think you need a group for each one, you make a per view admin group, a data reader group and a collection admin group, then you realize you need five different versions of those for five different business units, suddenly you have 50 groups and nobody knows what they do, stop, a real person doesn't live in just one layer, an analyst who needs to read the catalog needs a role in the unified catalog and a reader role in the data map, that's two different layers, if you split those into two separate groups, you will spend your entire career debugging half-granted access, you need to bundle the permissions, a specific persona needs into one single group, package them together, create one group that says this person is a data reader and give that group the right roles across all the layers at once, you have four layers but you only need about five groups, you'll end up with more groups than layers because a group should be shaped around a human being, not around the software architecture, this is the difference between a mess and a structure, so let's break down each layer and see what they actually control, layer one, tenant level, the keys to everything, this layer is assigned at the organizational level, it sits above everything else, it applies to both the data map and the unified catalog, if you control the tenant level, you control who gets to build the platform, who assigns roles and who decides what people are allowed to see, two role groups matter here, the first is purview administrators, these are the people who create and delete domains, assign roles in the data map and configure the account, they can do almost anything, the second is data governance, this role carries the data governance admin assignment, which acts as the bridge between the tenant level and the business side, it delegates the first level of catalog access down to the next layer, before you assign anyone to these groups, check your account type, unified catalog features, sit behind enterprise licensing, not the free tier, if you're on the free version, you have scanning and basic discovery, but you don't have governance domains or data products, you have a catalog, but you lack the business structure that makes a catalog worth maintaining, if you are on enterprise, keep this layer tiny, this is the one place where you actually want the fewest people possible, no more than two or three admins on the default domain, not a team, not a department, three people maximum, here is the structure that works, make one a service principle, service principles are non-human identities used for automation, they don't need MFA, they don't need to remember passwords, and they handle the repetitive work that makes a human admins job tedious, they run scans and register sources, then they stop, they don't have broad discretionary power, make the second a break-class account, this is an account you touch only in an emergency, it stays stored securely, documented and audited, it isn't for day to day work, it exists in case the primary admin leaves the company or the main account gets compromised, it is your backstop. The third admin, if you even need one, is your primary working account, this is the person who manages the platform during normal operations, because this role can raise its own permissions, it should have the shortest activation window and the strictest approval requirements, that is the fear you need to understand, per view administrators can change almost anything, including their own access levels, they can make themselves a governance domain owner, elevate themselves to any level or grant themselves access to sensitive data products, a compromised admin at this level can do more damage than most people realize, never hand this out a standing access, never create a permanent member of the per view administrators group who logs in every day with that role active, that is a breach waiting for a calendar invite, the tenant layer decides who configures the platform, but the data map layer decides where your metadata physically lives, layer 2, data map, collections and domains, the data map is where metadata physically lives, it is your registry of every asset you have scanned, every source you have registered and every table that exists in your environment, this layer keeps an up to date map of your assets, you shape it with two tools, domains and collections, they sound similar but they serve completely different purposes, domains are technical boundaries, they sit at the top of the hierarchy to separate credentials, connections and scan rule sets, a domain is where you define which Azure SQL databases or snowflake connections get registered and which credentials apply to them, you get one default domain automatically when your per view account is set up, you can add up to four custom domains but you should only use them if you have a real technical boundary, a separate region or a legal entity with different regulations might justify it, but don't use domains for dev versus production, that split belongs in collections, don't use them to separate the platform team from the business unit that is an organizational distinction not a technical one, domains are expensive to manage so keep them minimal, collections are operational and access centric, they are your security boundary for metadata, they are the actual containers where your sources land and your scanned assets appear, a per view account supports up to 1000 collections organized up to eight levels deep, you almost certainly do not want that depth, resist the urge to nest collections to mirror your organizational chart, collections are meant to be navigable, if someone opens the catalog and finds a 16 level hierarchy that matches the company reporting structure, they will leave to find a spreadsheet, four data map roles control access within these collections, each one is assigned per collection and inherited by child collections, the collection admin manages the collection and assigns roles, the data source admin registers sources and runs scans, the data curator maintains metadata and certifies assets, the data reader can view the metadata, here is the critical inside most teams get wrong, shape collections around your internal business domains, not your platforms, your instinct will be to organize by what you see, as you are a sequel here, snowflake over there, a fabric workspace in another collection, platform teams think in platforms, which is natural but it is also backwards, collections are what business users browse and filter, the boundary they see must be a business boundary, not a technical one, when a claims analyst opens per view, they expect to see a collection labeled claims, they don't want to see Azure SQL policy admin database or snowflake premium cluster, if they work in pricing they expect to see underwriting and pricing, if they are in finance they expect to see finance, when the analyst opens the claims collection they know they are home, everything relevant to their job is in that one place, the raw claims table might live in Azure SQL while the enriched features live in fabric and the reports live in power BI, all of them belong in the claims collection, the platform is just an implementation detail, the business domain is the label that matters, platform teams still run the scans, the engineering team registers the SQL database and the fabric workspace, they configure the scan roles, that is operational work, but the label the business sees belongs to the business, the claims collection, the finance collection, the customer collection, there is one registration rule you need to know, you cannot register the same source twice in one account, if several teams need access to the same database register it in apparent collection and scan into subcollections, this ensures assets appear where each team expects them to be, environments splits like dev, test and production also live in collections, a half build test table should never sit beside production claims data because they are separated into different collections, keep collection admins few, this is where the sprawl begins if you are not careful, assign collection admin roles at the top level or at a specific subcollection, but never scatter them across the account like random permissions, collections answer where metadata sits and who can touch it, they do not answer what the business calls it or who owns the meaning, that is the next layers job, layer three unified catalog, the control panel, unified catalog lives inside the settings menu of the purview portal, you go to settings then unified catalog, this is the single control panel for the business side of your data, it's where you manage governance domains, data products, glossary terms and access policies, if you are getting support tickets asking why can't I see this, the answer usually starts right here, but before you start handing out access you need to look at a massive vulnerability most teams miss, it's called live view, if a user has red access on an Azure resource or a fabric workspace, they can see that asset in the unified catalog, they don't need purview permissions, they don't need your permission, Azure roles flow directly into the catalog and surface assets you might think are private, you need to audit your cloud resource permissions before you assume the catalog is locked down. If you don't, you'll wake up six months from now and realize the entire engineering team can see sensitive data products just because they have a reader role on the underlying storage account. Unified catalog uses three permission levels, tenant, catalog and governance domain, you've already handled the tenant level where the purview administrators live, the catalog level is different, this is where roles reach across every single governance domain in your account. The governance domain creator builds new domains and hands off ownership. The global catalog reader can see published concepts across the whole company unless the specific domain blocks them. The global asset curator attaches glossary terms to assets and columns anywhere in the catalog. Finally, the data health owner and data health reader manage the quality reporting that spans your entire estate, you need to be very careful with the reader roles because people constantly mix them up. Global catalog reader lets someone see published concepts everywhere. Local catalog reader, which you set inside a specific domain, limits their view to just that one area. You use the local version for regulatory walls. If data in one domain must stay invisible to everyone else for legal reasons, that's your tool. But if you overuse it, you'll fragment the catalog and end up rebuilding the exact same silos you were trying to break down in the first place. Here is the counter intuitive part. Your first instinct will be to lock everything down. You'll want to keep reader access tight and only open it for people who prove they needed, resist that. A reader sees metadata, not the actual data. They see table names, column descriptions, owners and lineage. They see the structure, but they never see customer records or financial details. They see what the data is, not what it contains. You should default to broad read access and give almost everyone in the company a reader role. A catalog that nobody can see isn't actually a catalog. It's just a bureaucracy pretending to be discovery. Save your hard restrictions for real regulatory boundaries, where the law says the data must stay hidden. When you hit those walls, you need to actually verify the restriction works before you tell anyone it's secure. There is one more rule you have to remember from the data map layer. Catalog read access by itself doesn't show you asset details. A reader still needs data reader access down in the data map to see what the scanned data actually looks like. This means one persona lives across two different layers. If you give someone global catalog reader, but forget to give them data reader, in the collections, they'll see the business concept but not the asset. They might understand what a suspicious claim is. But they won't be able to see which specific claims match that definition. To get the full picture, they need permissions in both places. This is where the business meaning connects to the physical data. And the next layer is where the business owners finally take the lead. Layer four, governance domain level, where business shows up. A governance domain is a boundary for ownership. It's fundamentally different from the layers below it. The data map handles the structure and the catalog handles visibility, but the governance domain is about power. This is where your business concepts live. It's where you find glossary terms that define what a suspicious claim actually means. It's where you find the OKRs that tie data to your strategy and the policies that decide who gets access. In this layer, the business owners run the show, not the platform teams. The roles change here too. You have the governance domain owner who is accountable for everything in that domain. You should always have at least two of them. A single owner is a single point of failure. If they leave the company or get promoted, the whole domain stalls out. Having two owners ensures the work keeps moving, then you have the data steward. They manage the business meaning. They handle the glossary, the OKRs and the policies. They are the keepers of definitions. Their job is to make sure that when someone says suspicious claim, everyone in the organization is talking about the same thing. The data product owner builds the actual products. They define the scope, decide which assets belong, and approve the quality standards. They own the relationship with the people using the data. When someone asks for access, the product owner is the one who decides if it makes sense to grant it. The governance domain reader is the simplest role. They can see the published metadata within that domain, but they can't change anything. They are there to discover what's already been built. On top of all this, you have specialized quality roles like data quality stewards and data quality readers. They don't worry about definitions or products. They just focus on the health of the data. This is where the abstraction stops and things get operational. To add a data asset to a product, a data product owner needs two things. They need that domain role in this layer, but they also need data reader access down in the data map. This is the ownership and physical access meet at this exact point. This isn't a mistake in the software. It's the design. The data map controls the technical metadata, while the governance domain controls the business decisions. You need both to actually function. This is the moment where the four layers become a working system. A governance domain owner assigns roles, then those people delegate the work to stewards and product owners. The steward defines the terms, the product owner builds the product, and the reader discovers it. It works unless the stewards and product owners also have data reader access in the right collections. These aren't four separate worlds. They are four different ways of looking at the same problem. The tenant layer decides who builds the system. The data map decides who manages the discovery. The catalog layer decides who sees the concepts, and the governance domain decides who owns the business. Each layer holds a different kind of power. You need all of them, and they only work if you are intentional about how you set them up. Now that you have the layers, the real question is how you turn them into a system that actually works. The five role groups, packaging permissions into reality. Most blueprints fall apart right here. You look at the four layers, tenant, data map, catalog, and governance domain, and you see dozens of roles scattered across them. The immediate instinct is to build a group for every single role. You create a purview administrator group, a unified catalog admin group, and a collection admin group. Then you add a data reader group and a governance domain owner group. You build a data steward group for claims and another for finance. Before you know it, you need five different collection admin groups because five different teams manage five different areas. One month later, you're staring at 40 groups and a massive spreadsheet just to figure out what a new analyst needs to do their job. Stop there, you're thinking about this wrong. A real person doesn't live in just one layer of the software. An analyst who needs to read the catalog also needs unified catalog read access and data reader access in the data map. A steward who manages glossary terms needs governance domain permissions, but they also need data map read permissions so they can actually see the assets those terms describe. And a domain owner needs to delegate permissions, which means they need read access across the data map and catalog layers to verify what they're handing out. If you split these permissions into separate groups, you'll spend your entire career explaining why someone can see a data product, but can't see the actual asset underneath it. You need to bundle every grant a specific persona needs into one single role group. It's one group per person type, not one group per role per layer. You want a group that says this person is a fraud analytics steward. They have what they need everywhere, all at once. The math here feels counterintuitive. You have four layers, but you only need about five groups. You end up with more groups than layers because a group is shaped around a human being rather than a technical tier. In small domains, one group might cover both steward chip and product ownership, while larger domains might require you to keep them separate. Your total count will usually drift between four and six depending on how your company is built, but five is the most common landing point. Let's walk through the groups that actually work. Group one is the purview administrator group, and these are the keys to the entire kingdom. You have to treat this group like plutonium. Because this role has the power to raise its own permissions, having permanent standing access is a security breach just waiting for a calendar invite. You should never make people permanent members of this group. Instead, make the membership eligible through Microsoft Entra-Privileged Identity Management. An admin activates their access only when they need it, for a few hours at a time, with a full audit trail and a required approval. The group stays empty by default and no one gets in without completing MFA and proving they have a specific task to finish. Group two is the Unified Catalog Admin Group, which is the real workhorse of the platform. This group is responsible for running scans and creating the collections and governance domains before handing ownership over to the people who will run them. They build the structural house, but they don't own the furniture or the business meaning inside. This isn't the group that manages stewards or assigns who owns which data product. Their only job is to prepare the platform so everyone else can actually use it. Group three is the governance domain admin group, but you don't create just one of these for the whole company. They make one for every domain, once the Unified Catalog Admin is created domain, they hand it off to the domain owners who then grant access to stewards and product owners within their own borders. The claims domain gets its own admin group and underwriting gets another one. This ensures that no central IT team has to play gatekeeper for every single access request, allowing each domain to be semi-autonomous. Group four is the data steward group and you'll need one for each business unit. Stewards own the actual business meaning inside their domain, which includes things like glossary terms, OKRs and critical data elements. You want to split these along business lines to ensure edit isolation, meaning a finance steward can't accidentally rewrite a glossary term that belongs to claims. This also helps with navigation as a tightly-scoped group keeps people from wandering into corners of the catalog where they don't belong. Group five is the data product owner group with one created per domain. The governance domain admin gives this group the right to build and manage data products so owners get their power from the domain rather than a ticket to IT. In a small domain you'll often see this group and the data steward group overlap because the same few experts are doing both jobs. In larger organizations you'll want to keep these roles separate to maintain clear responsibilities. Then you have the data reader group which is the one group you create for the entire company. While writing roles are split by business unit to prevent people from colliding, reading is the exact opposite. You should default to broad reading access by giving everyone a single data reader group that covers both the data map and the unified catalog at the same time. The entire point of having a catalog is to share metadata, so don't make it hard for people to find things. The chain of command flows downward. The purview administrator delegates power to the unified catalog admin who then delegates to each governance domain admin who finally hands off access to the stewards and product owners. This allows access to flow where it's needed without a single team becoming a bottleneck for the rest of the company. You should name these groups after the persona and the domain like SG purviewGD claims data steward so a new hire can read the name and know exactly what it grants. Now that you have the blueprint, you need to build the foundation. Collections? Organize for discovery not platforms. The foundation of your setup is the data you actually scan, but how you organize that data determinants if people use the tool or abandon it. There is a specific mistake that quietly kills adoption in most companies. Teams tend to organize their collections by the technical platform, putting Azure SQL in one spot, snowflake in another, and fabric or a data lake somewhere else. While this looks clean and logical from an infrastructure perspective, it is completely wrong for the end user. Imagine a claims manager opens the catalog to find fraud detection data and sees a list of technical collections. They don't see a folder labeled "claims". Instead they see Azure SQL, policy admin database or snowflake premium cluster. These technical names mean nothing to them and because they have no idea where to look, they'll just close the catalog and ask a human being for help. Your expensive discovery tool just became a total waste of time. You need to organize your collections by your internal business domains instead. This is what non-technical users actually understand and it's how they search and filter for information. Most people only care about their own corner of the company anyway. They don't need to know that claims data is spread across three different systems. They just need to know where the claims section is. Your specific use case will still tell you which sources to scan. If you're looking for fraud detection, you know you need the policy admin database, the payout tables and the features in fabric. But knowing which sources matter is different from knowing how to arrange them for a human to find. You have to arrange the data for the reader. Scan those sources into collections named after business domains, such as claims, finance or underwriting. Even if the raw claims table lives in Azure SQL and the enriched features live in fabric, you should put both of them under the claims collection. The platform is just an implementation detail that the user shouldn't have to worry about. The business domain is the only label that matters. There is one technical rule to remember. You cannot register the same source twice in one account. If multiple teams need access to the same SQL database, you should register it in a parent collection and then scan it into specific subcollections. This ensures that assets appear exactly where each team expects to find them. When it comes to dev tests and stage environments, you should use collections rather than domains. Many teams get this wrong because they think splitting environments by domain looks better on a whiteboard. However, if you scan Microsoft fabric, the system won't let you split those environments across separate domains. Fabric has its own internal structure, so the environment boundary has to live within your collections. You should nest these, so each business domain maintains its own split for dev, test and production. A claims collection should have subcollections for each environment, ensuring that a half-build test table never sits right next to production claims data. Your collections will follow your business domains and your governance domains will eventually do the same. This symmetry is exactly what you want. When a manager sees a claims collection in the data map and a claims domain in the catalog, they'll know they are in the right place. To keep these collections relatable, you should follow three simple habits. First, use friendly names instead of the random six letter codes per view generates. Second, make sure the name reflects the business domain so it echoes the governance domain. Finally, keep your hierarchy shallow. A non-technical user should be able to look at your collections and find what they need without needing a tour guide. Now that we know how to structure the catalog, we have to talk about ownership because structure means nothing if no one is in charge. Governance domains, collections and domains, rhyme. You have two layers that both follow your business domains. Collections live in the data map. Governance domains live in the unified catalog. They are separate systems. They serve different purposes. But if you have organized both correctly, they will look almost identical. A claims collection in the data map. A claims governance domain in the unified catalog. Seeing the same word in both places is not a coincidence. It is the specific experience that tells a claims manager they are in the right place. This is intentional design. It is not redundancy. The layers do different jobs. Collections act as the access boundary and the place people browse when they need raw metadata. They control who can register sources, who can run scans, and who can see that assets even exist. They are the security perimeter for your metadata. Governance domains are where ownership finally shows up. This is where you define what things mean and where you build data products. It is where you publish glossary terms and policies. It is where business owners delegate authority to stewards and product owners. Collections answer the question of where an asset is and who can touch it. While governance domains answer what that asset means and who is accountable for it. But here is the key. They will not line up perfectly and that is fine. A claims collection in the data map holds the raw claims table, the payouts table, and the claims metadata table. It is just the claims. But a fraud analytics governance domain does not live in a fraud analytics collection because it does not have its own collection. The fraud analytics domain owns a data product whose assets are scattered across multiple collections like claims, underwriting, and finance. The assets sit in different places but the ownership sits in one domain that pulls them together under one business question. At the same time the claims collection feeds into multiple domains. The claims domain owns claims specific data products but the fraud analytics domain uses claims data as part of a cross-domain product. The regulatory domain might also pull claims data to support compliance. The claims collection is the source and the domains are the governance lenses over that source. The overlap is many to many. This is not a problem. It is how you avoid silos. A source system serves one collection, one collection serves multiple domains, and one domain pulls assets from multiple collections. The network is intentionally loose. One rule actually matters in all of this. Everything you scan into the data map becomes immediately discoverable in the unified catalog. Your users do not live in two separate experiences. They live in one. The claims manager opens purview and searches for fraud detection. The system shows them assets from the claims collection contextualize through the fraud analytics domain. They see the data product, the glossary terms that define what suspicious means in this context, the access policy, and the lineage showing where the score comes from. Everything they need is in one place, but that only works if naming is intentional. If the manager opens the catalog and sees a collection called call x7f2qa or an asset called sqlprod_rohr_e2, they have already lost trust. They leave, they do not come back. Name every collection for the human who reads it. Claims. Finance. Customer. Use simple business names. For the domains themselves, you need a structure that lines data up with experts and survives the next organizational reog. Use a blend of subject area domains like claims and customer, functional domains like finance and risk, regulatory domains for compliance and privacy, and project domains like fraud analytics. You need multiple perspectives because data serves multiple purposes. Three habits keep this relatable. Its friendly names instead of system defaults because the friendly name is what people actually see. Spend real effort on naming. Let the governance domain name echo the collection name when they align and keep your hierarchies shallow. A non-technical user should be able to navigate your structure intuitively without a guide. This is how you avoid a fragmented experience where users have to search both the collection tree and the domain tree to find what they need. Your name things deliberately, so the two structures feel like they are describing the same landscape from different angles. Now we understand how to structure the catalog, but structure means nothing without clear ownership. That's where data products become the bridge that connects everything. The data product, where structure becomes value. A data product is a business concept with a name, a description, owners and a list of data assets. It is the layer where all the architectural work you have done actually converts into something people can use. Everything up to this point is enabling infrastructure. The four layers, the role groups, the collections organized by business domain and the governance domains are all necessary, but they are not where value happens. Value happens when a consumer opens the catalog, finds one thing and gets an answer. A data product groups assets under one specific use case. The consumer finds it, requests access once and receives everything they need behind it. Policies attach to the product cascade down to the assets and access approval happens at the product level rather than the asset level. The consumer never touches the complexity underneath. This is the moment the rollout pays off, take the fraud detection question, which claims are most likely to be fraudulent this quarter. That is one product. All it certified claims fraud signals and put it inside the fraud analytics governance domain. Now list the assets that power it. You have the raw claims table from the policy admin system in Azure SQL, the payout history from Snowflake and enriched features table in the fabric gold lake house and a scored output report in Power BI. That is four sources across multiple platforms with different ownership models underneath. But from the perspective of the fraud analyst, it is just one thing. Certified claims fraud signals has one owner, one access policy and one set of terms of use. It is a single contract that tells you what you can do with the data, how fresh it is and who to contact if something breaks. That owner is accountable for all four assets, even though they live in different places and are managed by different technical teams. The owner does not manage the SQL database or the Snowflake connection and they do not run the fabric pipelines. They own the product that emerges from all of it. They define what fraud signal means and attach a glossary term like suspicious claim that is defined once in the fraud analytics domain. Any asset tagged with that term inherits the product's access policy. The definition is the single source of truth and the enforcement is automatic. This is how governance scales. You do not make every asset its own policy document. Instead you group assets under products and apply policies at the product level. When an approved data scientist requests access to certified claims fraud signals, they do not request access to four different assets on four different platforms. They make one request and get one approval. In that moment, the data product owner or an approver checks if this person needs the data and if the purpose makes sense. Once access is approved, the system provisions all four assets at once. This stops the scientist from having to chase four different platform teams. Because you build use case first, you can prove value before you scale. You do not build 10 data products at the same time. You build one, test it with the fraud team and measure whether the model actually works. You find out if it predicts fraud, if the analyst trusts the score and if they can act on it. You gather that feedback and iterate before you hand it over. Keep the domain in draft and give the fraud team read access. They use it and tell you what works and what does not. You learn what is actually valuable before you spend time maintaining a catalog of things nobody asked for. Then you move to the next use case. One question is proven and the next is already lining up. This is the difference between a catalog and a swamp. A swamp is a thousand assets no one asked for. Organized in a way that only makes sense to the IT team and discovered by no one. A catalog is a curated set of answers to questions people actually need. It is built one question at a time. It is built by someone accountable, governed by policy and discoverable through business language. The product is the bridge. It pulls assets across collections and layers into one unit and it hides the plumbing from the person who just wants an answer. But there is one more critical piece before a product can actually work as data transforms through the medallion layers ownership transforms with it and that handoff has to be explicit. The medallion accountability chain bronzes to gold. Most catalogs ignore one specific question. It isn't because the answer is hard to find. It is because the answer is uncomfortable who actually owns the data after you transform it. You already know who owns the raw claims table. The policy admin team pulls it from the source system. They make sure the ingestion worked. They certify that the data was captured faithfully. Their job is fidelity not correctness. They vouch for what came out of the system that is their role. But then something changes. The fraud analytics team takes that raw data and starts working. They clean the claims. They join them to historical payout records from a completely different system. They engineer features in a fabric leg house. They score the results. They build a model to predict which claims are likely fraudulent. By the time that score hits the gold layer, the business ready zone, it isn't the policy admin team's data anymore. They didn't write those joins. They didn't engineer the features. They don't even understand the model. They can't explain why a specific claim got a high score. They can't stand behind a number they didn't create. But on paper, they still own the raw claim. So who owns the fraud score? Is it the policy admin team who brought in the source? Is it the engineering team who handled the transformation? Is it both? This is where most catalogs fail. They don't answer. They register the raw table. They scan the gold table. They build a data product that includes both. And then they leave the ownership ambiguous. The assumption is that we will figure out who is accountable when something breaks. That's theatre. It isn't governance. In reality, here is what happens. Something breaks. A regulator asks who is responsible for a fraud score that turned out to be wrong. Three different teams point at each other. The policy admin team says they provided accurate source data. The engineering team says they followed the spec. The product owner says everyone did their jobs. No one is actually accountable because accountability was never assigned. The solution is an explicit handoff, as data flows from bronze to silver to gold, accountability must flow with it. It moves from the source owner to the data product owner who's team did the work. The structure of ownership changes. The responsibility shifts, usually. That shift happens in the silver layer. Silver is where the magic happens. Raw data gets cleaned. Multiple sources get joined. Business rules get applied. By the time data reaches silver, it is no longer source aligned. It isn't a faithful copy of the system anymore. It has been interpreted. It has been shaped by business logic. Someone had to decide how to handle nulls or how to join ambiguous keys. Those decisions belong to the team that made them. So the ownership shifts. The policy admin team owns the raw claims in bronze. The fraud analytics product owner owns the gold features table. Someone in the middle, usually the central data engineering team, owns the silver layer. They own the transformation logic. They own the joints. They can explain why the data looks the way it does at that specific step. Each zone has an owner, each owner answers for what they actually built. You have to write this into the catalog. Don't just leave a comment. Use explicit assignments. Set the policy admin team as the owner of the bronze claims table. Set the fraud analytics product owner as the owner of the gold table. Set the data engineering team as the owner of the silver table. Draw the lineage to show exactly where the raw source ends and the derived product begins. This is the difference between governance and theatre. In theatre, you have policies and roles. In governance, you have clear accountability at every transformation point. Everyone is responsible. Someone can be asked. Someone can answer when the model breaks or the score doesn't match reality. The moment you write ownership explicitly at each layer, the medallion architecture stops being just a storage pattern. It becomes an accountability chain. Each layer has owners. Each owner is responsible for the quality and correctness of their layer. That is what separates a real rollout from a performative one. It isn't the tool. It's the clarity of who answers when something goes wrong. PIM. Caging the purview administrator. There is one role in purview that requires a different class of control. In purview administrator role, this role can change almost anything in your account. It can create domains. It can delete them. It can modify scan rules or reassign roles to other people. And here is the part that should concern you. It can raise its own permissions. A purview administrator can make themselves a governance domain owner. They can grant themselves access to sensitive data products. They can change the policies for the entire organisation. If that role is compromised, the damage is effectively unlimited. If credentials leak or a terminated account is reactivated, the scope of exposure covers the entire platform. The window to detect the problem is incredibly narrow. This is why the purview administrator group cannot work under traditional access models. You cannot make people permanent members of this group. You cannot let them use it every day. That is structural risk. The solution is Microsoft Enter Privileged Identity Management. PIM. PIM isn't a tool you layer on top later. It is structural governance for privileged roles. It enforces just-in-time access instead of standing access. When an admin needs to work, they don't log in with that role active. They request activation. Here is how it works. An admin realises they need to create a new governance domain. They don't use their admin account directly. They go into the PIM portal and request the purview administrator role. The system asks why they need it. They provide a justification like creating a new domain for a specific use case. The system requires multi-factor authentication. They complete it. The request goes to an independent approver. That person reviews the request to see if it makes sense. If it does, they approve it. Now the admin has the role active, but only for a set amount of time. Usually this is between one and four hours. They do the work. They create the domain. They assign the owners. Then they step away. The role expires automatically. The system revokes it. No one has to remember to remove the access. The system enforces the expiration itself. Every single activation is logged. You see who activated it and when. You see the justification they provided. You see how long they held the power and what they did with it. This creates an unbreakable audit trail. The configuration of PIM around purview is intentional. You set the maximum duration to four hours. You always require MFA on activation. This means even if someone steals a password, they can't activate the role without a phone or a hardware key. You require justification to force intentionality. You require approval for high-risk roles, so someone else has to sign off. You set up notifications to alert domain owners when these activations happen. These settings implement controlled access with real accountability. The blast radius of a compromised admin is now measured in hours, not months. The attack surface shrinks. It moves from someone with standing access to someone with credentials, a second factor, and an approval from a peer. The purview administrator group sits empty by default. No one is an active member. Users are made eligible. Eligibility means they can request activation, but they don't have the power until they actually activated. That distinction is critical. Eligible is not the same as active. Eligible is potential. Active is power. When an admin needs to work, they activate. When they are done, the role expires. When something breaks, you look at the log to see who activated what and why. This is the difference between trusting people and verifying their actions. This is structural control over the most powerful role in your account. Now, let's talk about how to actually roll this out. The rollout sequence. Start narrow, scale slow. Most teams fail here. Not because they picked the wrong structure, but because they tried to do everything at once, they spend weeks designing a perfect permission model and documenting role groups. They map collections to business domains and publish a rollout plan that looks like a military operation. After every source, create every domain, assign every role, go live across the whole enterprise, then reality shows up. Change management breaks because people don't understand why their permissions changed. The catalog fills with data, no one knows how to use, and support tickets pile up until adoption stalls. Executives ask why they spend money on a tool nobody uses. The team eventually declares the project a failure, but the real failure was the sequencing. There is a different way. Don't design once and implement everywhere. You need to design for one, implement for one, and learn from one before you replicate that success. Pick one business question that real people are waiting on right now. Not a broad theme like improving data governance or building a modern platform. Find a specific urgent question that someone is losing sleep over because they can't get the answer fast enough. That question is your seed. One sentence is all you need to get started. You might ask which claims are likely to be fraudulent this quarter or how many customers will turn in the next fiscal year. Maybe you need to know which transactions violate policy within 24 hours of initiation or which employees are flight risks. Pick something with real consequences if you get it wrong. That single sentence does all the heavy lifting for you. It tells you which sources matter, which collections to create, and which domains to establish. It identifies your first audience. One use case pulls the entire roll out forward. Everything else you build serves that one question. Build the permission structure specifically for that answer. You don't need five role groups yet. You just need a domain owner for your first domain and stewards to define what the business concepts mean. You need a data product owner to own the answer and readers to consume it. Create the groups you actually need and nothing more. Register only the sources that the question requires and scan nothing else. Create one collection and one governance domain but keep it in a draft state. Give your first audience the fraud team or the churn analysts. Read access while it is still a draft. Let them use it so they can tell you what is working. Gather feedback while it still costs nothing to change. Does the term "suspicious claim" match how the team actually talks? Does the data product include everything they need or are assets missing? You need to know if the access policy is too strict and if the naming in the collection is confusing. Check if the lineage story makes sense or if it raises questions about where the scores come from. Learn in the small, fix before you scale. Then move to the next question. Once one question is proven, the next should already be waiting in line. Build a second use case in the second domain using the same discipline. One question, one collection and one product. After that, get feedback and learn. Only publish the work when it is solid. The sequence matters more than you think. Use cases come first, permission second and sources third. Most organizations do this backward by scanning everything first and hoping governance appears naturally from a big catalog. Then they try to retrofit permissions onto a landscape that is too fragmented to govern. That is when accountability disappears and the catalog becomes noise. Start narrow on purpose. Each use case teaches you how people actually talk about data and where ownership boundaries naturally fall. Every data product you build becomes a template for the next one with the same structure and quality expectations. Each governance domain you establish proves that the model works. Six months in you will have five proven use cases and five governance domains. You have templates, playbooks and evidence of value to show the leadership team. Now you can scale with confidence because you aren't learning as you go. You are simply replicating something you've already proven. This is how you build trust instead of losing it. The failure modes, what to watch for. Even with a solid design, things still go wrong. This usually isn't because the model is broken. It happens because implementation is where organizations drift from the plan and watch governance collapse. The first failure looks innocent enough. A team says they need to manage their own collection so you grant them the collection admin role. They own the data, so it seems reasonable they should manage it. Then another team asks for autonomy and you granted again. By month six, you have admins scattered everywhere like permissions were seeded by the wind. No one knows who has what and the central team can't audit the mess. The domain owners don't even understand their own structure anymore. The domain is blunt. Keep your collection admins few. Assign them only at a top level collection or a specific sub collection. Never spray these permissions across the account. Make it a deliberate act rather than a default response to request. The moment you start saying they can be their own admin, you have lost control. The second failure is subtler. Data products get created but no one is assigned as the owner. The product exists and has an access policy but there is no name attached to it. There is no accountability. Six months later the product is stale because the data went out of sync with the documentation. A consumer finds a bug but has no one to contact. The product decays and trust drops. Prevent this by making ownership explicit and visible in the catalog. The owner must be responsible for the contract the product makes with consumers. If the data is supposed to be fresh daily and it isn't, that is the owner's failure. Ownership without accountability is just a title but adding accountability changes how people work. The third failure is frustrating for everyone involved. A user has read access in the data map but not in the unified catalog. They open an asset and understand what it is but when they click the data product they see insufficient permissions. They have one level of access in one layer and something else in another. Confusion and tickets flood in. This happens because read access was granted inconsistently across the different layers. One team granted a role in the collection while another team assigned someone to the domain. The solution is mechanical. You must grant read access across both the data map and unified catalog at the same time. Use the same groups for the same people every single time. The fourth failure happens quietly as the catalog fills with noise. Teams scan everything because the scan feels free and assets pile up that no one actually asked for. A business user looking for customer data finds a thousand tables from operational systems they don't understand. They leave and never come back. You spend the budget but lost the trust of the users. Prevent this by disciplining yourself to start narrow. Scan only the sources your first use case needs. Don't scan everything just because the tool allows it. The fifth failure is architectural. Teams domains and collections don't align because collections follow technical platforms while domains follow the org chart. These two structures are incompatible. Lineage stops making sense and ownership becomes unclear. Teams won't know which domain owns which collection. Prevent this by making your collections and governance domains rhyme. Both should follow your business domains. Using the same words in both places tells users they are navigating a coherent system rather than two separate worlds. Measuring introduction. The trap of ease. Microsoft purview isn't something you install. It's already sitting in your tenant waiting. You don't buy it. You don't download it. You don't even schedule a big implementation project. It just exists as part of your Microsoft 365 infrastructure. It's a feature that came with the package. You flip a single switch in the admin center and it turns on. No procurement gate. No moment that forces you to stop and think about what you're doing. No conversation with stakeholders about what success actually looks like. That ease is the trap. Six weeks later the switch has been flipped. Someone has scanned your databases. Someone has created a few domains. Someone has handed out access to anyone who asked. Now you're looking at a catalog that sprawls across your entire organization. Collection admins are everywhere. Nobody owns a single data product. The catalog is somehow both locked down and wide open at the same time. Half your organization can access metadata through Azure resources even though you never intended it, while the other half is asking why they're being denied access to data they use to browse freely. That's not a tooling problem. That's a rollout problem. This isn't about whether purview is good software. It is. This is about the structural flow in how most organizations approach governance when there's no forcing function to do it right. The whole problem is change management that nobody planned for. It's the difference between turning something on and actually deploying something. The problem. Why ease becomes a trap? Starting costs nothing. So most teams start with nothing in mind. There's no business case to write. There's no budget conversation. The feature is already licensed as part of your M365 spend. Why not turn it on? The friction to activate is zero. The friction to plan is high. So people skip the planning. What happens next follows a predictable pattern. Everyone gains access to purview. They look at the data map. They think we should scan everything. Every database, every data lake, every fabric workspace. The idea is to build a full picture of the data estate. It feels productive. It feels like you're taking control. Then the scans run. Thousands of assets appear. Raw tables from operational systems. Staging tables from ETL pipelines. Test tables, nobody uses. Ancient tables everyone forgot about. Duplicate tables from failed migrations. The catalog fills with noise. The signal to noise ratio is so bad that finding an actual answer becomes harder than just calling someone on the phone. Business users open the catalog for the first time. They look for something specific like a customer data set or a metric for revenue, but they see a thousand results instead. None of them have names that make sense. They see SQL ProDraw, EU2 and TBL are staging before seven. The names mean something to the DBAs who created them, but they mean nothing to the people trying to find answers. They close the catalog. They never come back. Meanwhile permissions sprawl. Early access requests get approved loosely. Someone needs to see a table so they get access. Someone else needs access to the collection so they get added. By month three, nobody knows who sees what anymore. The central team can't answer the question. The domain owners don't understand the permissions they've delegated. New employees ask who they should talk to about access, and the answer is, "I'm not sure, probably multiple people." You spend the budget, you build the infrastructure, you deploy the platform, but you lost the trust. The real cost of a failed rollout isn't the tool or the licensing. Its organizational credibility. It's the moment people decide that data governance is a waste of time because the tool they were given doesn't work. It's skepticism lingers for years. The real failure. Big bang versus use case first. The fundamental mistake is starting with infrastructure. Instead of starting with a question, most teams approach a rollout like this. Here is our org chart. Let's catalog everything to mirror how we are organized. Finance gets a domain. Operations gets a domain. We scan the finance databases here. And the ops databases there, we create all the governance domains at once. We assign all the roles. We publish everything. Now we have a catalog that matches our org structure. That feels productive. It feels complete. But in reality, it delivers nothing. A claims manager opens the catalog. They search for fraud detection data. The system returns results from the claims domain, the fraud domain, and the risk management domain. They don't know which one they need. They have to ask someone. The catalog didn't answer their question. The catalog just created more work. This approach is backward because you are organizing the catalog before you understand what questions it is supposed to answer. You are building infrastructure hoping that structure will somehow create value. It won't. Structure without purpose is just noise at scale. There is a better starting point. A use case is one sentence. One business question, real people are actually waiting on. Which claims are likely to be fraudulent this quarter? How many customers will we lose before renewal? Which transactions violate our policies within 24 hours? These aren't themes. These are specific questions with business consequences. Pick one. That one sentence does immense work. It names the sources that matter. Not every database in your organization. Just the ones required to answer that specific question. It names the collection those sources belonging. It names the governance domain that owns the answer. It names your first audience. These are the people who have been waiting for this answer. And they will be your earliest advocates. One use case pulls the entire roll out forward. It forces prioritization. It creates pressure to get governance right because someone is waiting on an answer. It creates accountability. It creates focus. A big bank scan creates noise. Use case first creates focus. Noise kills adoption. Focus builds it. The four layer permission blueprint. Per view spreads access across four distinct layers. Most teams discover them one access denied ticket at a time. Here is how it works. You have the tenant layer. This sits at the organizational level and applies to everything. You have the data map layer. This controls who can register sources and manage metadata in the scanning engine. You have the unified catalog layer. This lives in settings and controls who can see and create business concepts. And you have the governance domain layer. This sits inside each individual domain and controls glossary terms and data products. Each layer grants a different kind of power. Each layer has its own roles. Each layer requires its own permission assignments. A person who needs to create a data product doesn't just need one role. They need permissions in multiple layers simultaneously. That is where most roll outs break. Teams treat these layers as separate. They grant a role in one layer. They grant a different role in another. A week later, someone is confused about why they can't do their job. They have permission in one layer but not another. Half of the functionality works. And the other half doesn't. Support tickets. Two rules sit above everything. First, assign roles to entry groups. Never to individual users. A group doesn't care if someone leaves the organization or changes roles. A group is stable if you assign to a user. You will spend your life managing individual role assignments. Second, don't create a group for every role in every layer. That is how you end up with 40 groups in a spreadsheet trying to track which one is which. A real person needs grants in more than one layer at once. Bundle those grants into role groups. Package the permissions a persona needs into one unit, four layers. Not about five groups. That is the structure that actually works. Layer one. Tenant level. The keys to everything. The tenant layer lives at the very top of your organization. It controls both the data map and the unified catalog. This is where you hand out the most dangerous permissions in the entire system. Two role groups matter here. Per view administrators and data governance. Per view administrators have the power to create domains and assign roles across the data map. They can change your scan rules and manage every connection. Data governance admins hold the keys to the first level of catalog access. This is the entry point for managing your business concepts. But before you assign a single role, check your account type. Unified catalog features require enterprise licensing. If you stay on the free tier, you can flip the switch but half the features won't actually work. You have to commit to enterprise or accept the limitations from day one. Keep this layer small. Use the fewest privileges possible. You want no more than two or three admins on the default domain. One should be a service principle for your automation. The other should be a break-class account for genuine emergencies. Both of these stay inactive by default. They should always require elevation before they can do anything. There is one role you should actually fear. The Per view administrator can change almost anything, including its own access levels. Giving someone standing access to this role is just a security breach waiting for a calendar invite. Never handed out as a permanent membership. Treat it like nuclear material. The tenant layer decides who configures the platform. The next layer decides where your metadata actually lives. Layer 2. Data map. Collections and domains. The data map is your live inventory. It tracks assets across every source you register. You shape this map using two specific tools. Domains and collections. Domains are technical boundaries at the top of the hierarchy. They separate your credentials, your scan rules and your policies. One domain cannot see another domain secrets or executed rules. You get one default domain and up to four customers. Only add a custom domain if you have a massive boundary. Think separate global regions or legal entities in different countries. Do not use them to separate dev from production. That isn't a big enough reason to justify the complexity. That's what collections are for. Collections are operational. They are your security boundary for metadata. You can have up to 1,000 collections and eight levels of depth, but you should resist that depth. Don't build your collections to mirror your org chart. Organizations change constantly. If you tie your metadata to a specific department head, your structure will be outdated by next Tuesday. Four roles control access at the collection level. The collection admin manages the roles. The data source admin registers the sources and runs the scans. The data creator creates the assets. The data reader just views what is there because these permissions flow down to child collections. You can run access at the top and it will cover everything below. Shape your collections around business domains, not technical platforms. Users need to find claims, not as your SQL policy admin database. When a claims analyst opens the catalog and sees a folder named Claims, they know they are in the right place. That is how you drive adoption. The platform teams should run the scans, but the labels belong to the business. Keep your collection admins to a minimum. Assign them at the top level or specific subcollections, but never spray them across the whole account. The moment you treat a collection admin request like a standard ticket, you've lost control of the system. Collections answer where the metadata sits. They don't answer what the business calls it. That's the next layer. Layer three unified catalog, the control panel. Unified catalog lives in settings. Then unified catalog. Inside the purview portal. That one area is the control panel for your entire business catalog. It's where you assign every catalog level role under a single menu. And this is where most why can't I see this? Tickets are born. But here's the problem. There's a critical leak you need to know about. A user with read access on an Azure or fabric resource can see that asset in the catalog using live view. Even if you never granted them catalog access, you need to audit your existing Azure role assignments before you assume the catalog is private. The unified catalog uses three permission levels. The tenant level handles who creates domains and reaches across all catalogs. The catalog level holds roles that span every governance domain globally. The governance domain level sits inside each individual domain. At the catalog level, several roles matter. The governance domain creator builds domains and delegates ownership. The global catalog reader sees published concepts across all domains unless you restrict them. The global asset curator adds glossary terms to assets. The data health owner and reader build and read health reports. Pay attention to the two reader roles. The global catalog reader sees across the whole catalog. With the local catalog reader, which you set inside a single domain limits reading to that one domain only. This role exists for regulatory roles. For when the metadata itself must stay hidden. If you overuse it, you fragment discovery. You end up rebuilding the silos. The catalog was supposed to tear down. So flip your instinct here. Most people think you should hand out read access slowly, restrictively, defensively. Resist that. A reader sees metadata, never data. They see table names, column names, descriptions, owners and lineage. They don't see a single row of actual data default to broadread because a catalog nobody can see is useless. One thing carries forward. Catalog read access alone doesn't reveal asset details. A true reader also needs data reader down in the data map. One persona, two layers. Grant both. Inside each governance domain, a different set of roles runs the business of the data. Therefore, governance domain level, where business shows up. A governance domain is the boundary for shared ownership and discovery of data products. This is where the business shows up. This is where business owners, not platform teams, run the show. The governance domain owner delegates all other domain roles and sets policies. You should put at least two owners on every domain so it never has a single point of failure. The data steward creates and manages glossary terms. OKRs, policies and other business artifacts. The data product owner creates and manages data products. The governance domain reader reads published metadata. This is where the two worlds meet to add a data asset to a data product. A data product owner or data steward also needs data reader permission on that asset down in the data map. Business ownership and physical access touch at exactly this point. One person, two layers again. One persona spanning multiple permission layers. This is where the four layers stop being abstract and become operational. You understand tenant level power. You understand data map organization. You understand catalog visibility. Now you understand how business meaning actually flows through the system. The question becomes how do you package all these permissions into something people can actually manage?