Microsoft Purview Data Map - Simply Explained

Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365, FME out Tim and your host, Mirko Peters. Think about a normal workday. You answer email and outlook, chat in teams, save a file and share point, work from your own one drive and open a report built from Azure or Microsoft fabric data. Then someone downloads the report, changes a few numbers, and emails a spreadsheet to five people. Each app might have solid security. The problem is the information moving between them, getting copied, renamed, shared and forgotten. By the end of this episode, you will understand how Microsoft Perview helps an organization find, understand, protect and manage its data in plain English because a secure system can still contain risky data. Tell you why data sprawl turns into business risk. Imagine you start a company tomorrow. At first the data feels easy to manage. Sales keeps customer details in one system. Finance has its reports. HR stores employ you files in another place. Marketing has campaign folders. Everyone knows where their own work lives. Then the company grows. A new team starts using a different app. Someone builds a database for a project. Another team copies the data into a spreadsheet because they need an answer before Friday. A business buys another business. And now there are old file shares, old reports and old systems that still run somewhere behind the scenes. Nothing looks wrong from the outside. But the organization slowly turns into an office building with hundreds of locked rooms. There are filing cabinets in each room, but many have no clear label. Some cabinets contain customer data. Some contain old employee records. Some contain the latest pricing plan. Others contain a copy from two years ago and nobody has a full directory. That creates a strange problem. People can have secure apps, secure laptops and secure sign-ins while the organization still does now know where its most sensitive information lives. You wouldn't be probably seen this happen. Someone asks, "Oh, where can I find the approved customer numbers for last quarter?" All three people send three links. Each file looks believable. Each report has a different total. A meeting starts. Not to make a decision, but to work out which number people should trust. That is now to be just annoying. It slows down the business because people spend time searching, checking, copying and asking for access. It also creates duplicate work. One team builds a report from a data source they trust, while another team builds nearly the same report from an older copy. No one is trying to cause trouble. They are trying to get their work done. Let our teams use a simple example. A finance analyst needs the current pricing data for a monthly report. She searches SharePoint and finds five spreadsheets with almost the same name. One comes from sales. One comes from finance. One lives in an old project folder. Another was sent by email six months ago. She chooses the file that looks newest. Later, the report reaches leadership and someone notices that the prices don't know TIEM, yes, match the approved list. The analyst did not make the pick the wrong file because she lacked skill. She picked it because the organization gave her no clear way to find the right one, see who owns it or check where it came from. That automata data governance problem. And it becomes more serious when sensitive data sits in places people don't know to me think about anymore. An old project site, a forgotten database, a personal cloud account, a copied customer list on a laptop, a report exported from a dashboard and attached to an email thread. The data did no time to disappear. It just moved outside the view of the people responsible for it. That also changes how you think about security. Entra ID for example acts like the reception desk for your company. It checks who you are and whether you can enter. Intune helps manage company devices. Defender helps look for threats. Those services matter. But once a person opens a file, downloads a report or copies data into another app, the question changes. What information did they take? How sensitive is it? Where can it go next? Is it accurate enough for someone to use? This is where many organizations find a gap. They protected the building entrance, but they don't know Tim. To have a clear view of the papers moving between rooms. AI puts even more pressure on that gap. An AI tool can only give you a useful answer when it works from data you understand and trust. If it uses duplicate records, old numbers, or data with no owner, it can produce a very confident answer that sends you in the wrong direction. The problem is now to know whether people can access data. ETA autumn says whether the data deserves their trust. Research often puts a price on poor data quality, but you can see the cost without a calculator. It appears in misdeed lines, long approval chains, reports that don't know TMT agree and leaders who stop trusting the numbers in front of them. It also appears after a leak when the first question becomes, "Oh, what information actually left? AU?" If nobody knows where the data lives, that question can take far too long to answer. So, the goal is now TMT to lock every file away. People still need data to do their jobs. The goal is to give the organization a shared view of what it has, what it means, who owns it, and how it should be handled. Microsoft PerView fits into that picture as a connected control room for data, rather than another place where you store it. What Microsoft PerView actually is. Microsoft PerView helps an organization govern, secure, and manage data wherever that data lives. That sounds broad because it is. The view is now to make a place where you move every document, database, and report. It does know to make replace SharePoint, Exchange Online, Azure, or Microsoft Fabric. Those services still store and process the information they were built for. PerView adds the rules, context, and visibility around that information. Many people first hear about PerView during a compliance project, so they assume it out to miss, only for legal teams filling out forms. That opens too narrow. Others see a data catalog and think PerView only helps analysts search for tables and reports. It opens also to narrow. PerView brings several related jobs into one connected platform. It helps teams understand their data, it helps protect sensitive information, it helps keep records for the right amount of time, and it helps the right people investigate when something looks wrong. Picture a large office building from a different angle. The apps where people work are the offices, meeting rooms, and storage areas, Outlook handles messages, Teams handles conversations, SharePoint holds team files, OneDrive holds personal work files, Azure and Fabric call databases, reports, and data used for analysis. PerView is the set of information and rules that helps the building run safely. It acts like the directory that tells you what exists and who looks after it. It acts like the filing rules that explain what belongs in a cabinet, what a folder means, and how long the folder must stay. It acts like the security signs on a door that tell people, oh, this information is confidential. Don't know what made SharePoint outside the company. AO it also acts like the records room and the incident desk, where an organization can look back at actions, keep evidence when needed, and investigate unusual activity. The point is not met, to turn work into paperwork. The point is to let people work with data, while the organization applies clear rules around that data. PerView connects with Microsoft 365, so it can work with information in exchange online, SharePoint, OneDrive, Teams, and other Microsoft 365 services. It also connects with Azure and Fabric, where many organizations keep and analyze business data. Depending on the PerView capability and the connector available, it can also work with supported data sources outside Microsoft. That matters because very few organizations run every system from one company. You might have business data in Azure, customer data in a different cloud service, reports in Fabric, and documents in SharePoint. PerView helps create a clearer view across those places, rather than forcing every team to use the same storage system. It can also work with information on devices and in apps where people create, copy, share, or use company data. This is where people often mix up platform security and data protection. EntraID manages your digital identity. Think of it as the system that checks your name, your sign-in, and whether you can enter a service. It helps decide who can open the door. PerView focuses on the information once someone is inside. For example, a person may have permission to open a customer report. That permission can be correct. Yet the report might contain private customer details, and the person might try to attach it to an email sent outside the company. EntraID helps confirm that the person is really that employee. PerView helps the organization understand the information in the report and apply handling rules when the employee tries to share it. Those are different jobs, and you need both. You can think of PerView in three connected areas. First, data governance. This helps people find data, understand what it means, see who owns it, and judge whether they can trust it. Second, data security. This helps identify sensitive information and apply protection when people use or share it. Third, risk and compliance. This helps organizations keep records, review activity, support legal cases, and look into behavior or events that need attention. These areas overlap because data does no TMRT stay in one neat place. A finance table can feed a fabric report. That report can become a PowerPoint slide. The slide can appear in a Teams chat. A copy can then leave in an email. Treating each moment as someone else out, Thames problem creates gaps. PerView helps teams use a shared set of rules and a shared view of the information, even while that information moves through different services. But finding a data source and knowing its owner only solves part of the problem. A catalog can tell you that a customer list exists. It can't outmeteer by itself stop someone from sending that list to a personal email address. So the next building block starts with discovery because you can't outmeteer apply sensible protection to information your organization has no tim and found or understood. First building block, find name and trust data. The first job is simple to describe. Before you can manage data, you need to know it exists. PerView starts with the data map, which acts as a technical inventory of your connected data sources, showing the systems, databases, tables, reports, and other data assets your organization uses. Most of a large warehouse with thousands of boxes, the data map does not amount to take every box away and move it into one new warehouse. Instead it records what the boxes are, where they sit, what they contain at a high level, and how they connect to other boxes. That information about data is called metadata. Metadata means data about data, a table name, its columns, its owner, where it lives, when it changed, and what classifications apply are all examples. PerView can collect and organize this information without copying all the underlying customer records financial figures or files into PerView itself. That separation matters, your Azure database stays in Azure, your fabric data stays in fabric, a supported external source stays where it already lives. PerView helps people see and understand the information without turning into the new home for every piece of data. Technical details help IT teams, but most business users do now, TMLD, search for a server name. They search for something like, "Aew approved pricing data, Aew, Aew monthly customer figures, Aew or Aew the report used by finance." It outs at albums where the unified catalog comes in. The unified catalog gives people a business-friendly place to search for data they can use. Instead of asking around, until someone sends a link, you can search for a data product with a clear description, a named owner, its approved uses, and the rules around access. A data product is simply a useful group of related data put together for a business purpose. Imagine the finance team publishes a pricing analytics data product. It might include a source table from Azure, a cleaned table in fabric, and the approved report people use every month. Rather than telling everyone to hunt for the right file, the team can describe the product, explain what it covers, and name the people responsible for it. That gives users a better starting point. The catalog can also use a business glossary, a glossary helps everyone use the same words for the same thing. For example, does O-Active customer O mean someone who bought something this month, this year, or ever? If sales, finance, and marketing each use a different meaning, reports will never fully agree. A plain English definition gives the organization one shared answer. Pervue can group these products into governance domains too. You might have a finance domain, a sales domain, or a customer domain. Each domain helps show which part of the business owns the data, and who should make decisions about it. Ownership does not mean one person knows every technical detail. It means someone accepts responsibility for what the data means, whether it is fit for use, and how people should request it. Now this next part is where trust enters the picture, finding a table named, "How customer pricing, O-O, does now Tim, to prove that it is correct." You also need to know where the data came from, and what happened to it along the way. Pervue can show data lineage. Lineage is the trail behind a number. If you see a total in a fabric report, lineage can help show the source table it came from, the steps that changed it, and the reports or data products that now use it. So if a source field changes, a data team can see which reports may need checking. It also gives business users a chance to ask a much better question than, "How can I access this?" "How?" They can ask, "How can I trust this for the decision I need to make?" AO Data Quality helps answer that question. A data owner can set rules, such as checking whether required fields are empty, whether customer IDs exist in the right reference list, or whether values look unusual. Pervue can run those checks, produce quality scores, and raise alerts when a rule fails. An accessible report is not always a trusted report. That difference can save a team from building a decision around incomplete or outdated information. You might also see an option to request access through the catalog. That request can go to the data owner with a reason for why you need the data and what you plan to do with it. But the catalog does new, "Termint" replace the access controls in the original system. Pervue can guide discovery and approval. The source system still controls the actual permission to open the data. Once data has a name, an owner, a meaning, and a trail behind it, the organization can start handling it with more care. Second building block, "classify and protect sensitive information." Once people can find trusted data, the next question is how they should handle it. You may already know the most familiar part of Pervue. In Outlook, Word, Excel, or PowerPoint, you might see label choices such as public, internal, confidential, or highly confidential. Those labels are not just decoration. They tell people what kind of information they are working with, and they can trigger protection rules behind the scenes when the organization sets them up that way. First Pervue needs to spot sensitive information. That could mean payment card details, health records, home addresses, passport numbers, passwords, employee details, or a company out, templates, as plans for a product that has not launched yet. Pervusoft includes many built-in ways to recognize common types of sensitive information, and an organization can also create its own rules for information that only matters to them. For example, a bank might look for account details, a health care provider might look for patient information, a manufacturer might look for its product codes and design documents, Pervue can then apply or suggest a sensitivity label based on what it finds. A user can also choose a label themselves when they know the document needs special care. Think of a sensitivity label as a clear handling instruction attached to the information. A label called Confidential might add a header or a watermark to a document. It might want someone before they share it outside the organization. It might encrypt the file so only approved people can open it. It might also limit what recipients can do, such as stopping them from forwarding an email or printing a document. The exact outcome depends on the policy behind the label. That is important, because labels should match how people actually work. If every file receives the strongest label, people will either get blocked from normal work or stop taking labels seriously. A useful label policy gives people simple choices that fit real situations. Public means it is safe to share. Internal means it stays inside the company. Confidential means pause before you send, copy or upload it. This brings us to data loss prevention, usually shortened to DLP. DLP watches for sensitive information when someone tries to do something risky with it. That might mean sending an email outside the organization, copying content to a USB drive, uploading a file to personal cloud storage or sharing a document with the wrong group of people. A sensitivity label and DLP work together, but they do different jobs. The label identifies information and describes how it should be handled. DLP checks an action as it happens and can warn the person, block the action or record it for review. Imagine an employee finishing some work at home. They have a customer list in an Excel file and they decide to upload it to a personal storage account because it feels quicker than using the company R/TMSS approved tools. Without protection, the file leaves the company in seconds. With the right DLP policy, Perview can recognize the customer information and respond before the upload completes. The employee may see a message explaining that company customer lists cannot go to personal storage. Depending on the rule, they might be able to provide a business reason or the upload might stop completely. That small moment can prevent a much larger problem and it does not always need to feel like a hard stop. User coaching is one of the more practical parts of Perview. A policy tip can explain what triggered the rule and point people toward a safer option. Maybe the employee needs to share the file through a protected SharePoint site. Maybe they need to remove private fields first. Maybe they need approval from the data owner. People make mistakes when rules are hidden. Clear guidance at the moment. Someone shares information, gives them a chance to do the right thing, without turning every action into a support ticket. Organizations usually begin carefully here. They often run policies in a mode that records activity or shows warnings before they block anything. That lets the team see how often the rule triggers and whether normal work would be affected. Then they can adjust the policy based on real use. Still, stopping a risky email or upload only covers one kind of risk. Sometimes the concern appears in a pattern of actions over time, when an unusual series of downloads, copies or messages needs more context than one rule can provide. Does? Third building block, manage risk, records and investigations. Not every data problem happens when someone clicks send. Sometimes an organization needs to look back and answer a simple question. Who did what? When and with which information? That is the job of audit. An audit log records actions across supported services. It can show that someone shared a file, deleted content, changed the setting, searched for information or signed in and used a service. It does not decide whether that action was good or bad. It gives the people responsible a record they can review. Imagine a team notices that a confidential folder suddenly has different permissions. Instead of guessing, they can look for the actions around that folder. Who changed the sharing setting? When did it happen that did anyone download files afterward? Those details help the team understand the event without relying only on memory or email threads. Per view also helps manage how long information stays around. The organization keeps some information longer than it wants to. Old emails, project files, contracts, employee records, meeting notes. Some of it needs to stay because of law, company policy or a business reason. Other content should disappear after a set time. Because keeping everything forever creates more risk and more clutter. Retention policies set those rules. A policy can tell a service to keep content for a period of time, deleted when that period ends or do both in the right order. Records management takes this one step further for information that must remain unchanged and kept as an official record. Think about an approved contract. You may need people to read it, but you do not want anyone quietly changing or deleting the final version. A record rule helps protect that official copy for the required period. Then there is e-discovery. That name sounds technical, but the idea is straightforward. When a legal case, internal review or formal request needs evidence, e-discovery helps approve teams search and review business content across places such as email, teams, share point and one drive. They can collect relevant files and messages into a case, preserve them when required, and review them without asking every employee to search their own inbox. This does not mean per view turns every conversation into a legal case. It means the organization has a controlled process when it genuinely needs to find evidence. Some risks also come from unusual behavior rather than one file or one message. Inside a risk management can help teams spot patterns that deserve review. For example, someone may begin downloading far more files than usual shortly before leaving the company or repeatedly copy sensitive data to places that do not fit their normal work. A pattern is not proof of bad intent. People can have valid reasons for unusual work, so these signals need careful review by the right people. Per view gives investigators context. It does not label someone guilty. Communication compliance works in a similar way, where company rules or legal duties require it, an organization can set policies that review workplace messages for certain risks. That could include harassment, threats, sharing sensitive details or language that breaks a regulated industry rule. The policy should be clear, limited and handled by authorized reviewers. People deserve that care. Now, file names and labels only tell part of the story. A file called "O" budget finaleau might contain routine figures, or it might contain plans that would damage the business if shared. During an investigation, teams often need to understand the content and its context, not just the name stamped on it. Per view can help teams search large sets of files, emails and messages, then narrow their review to content that appears related to the case. Through AI-supported tools can assist with that sorting and analysis, which saves people from opening thousands of items one by one, but the decision still belongs to people. Per view does not replace legal advice, human judgment or the security controls in the systems where data lives. It gives the people responsible better records, better search tools, and more context when time matters. Next, let out teams follow one piece of customer data and see how these per view parts connect as it moves through everyday work. How the pieces work together. Data can start in a business system, feed a fabric report and appear in a team's discussion. Per view adds ownership, meaning, quality checks, labels, sharing rules, retention and an audit trail along that path. Start small, then build control. Start with one risky area. Name and owner define the data clearly and test the policy before expanding.