Worked Scenario: Mapping a Retail Data Estate

Cascadeen Retail Group has a familiar problem: the business wants to use customer and order data with confidence, but nobody can say exactly where all the important data lives, how sensitive it is, or whether it is fit for use. This scenario follows one continuous engagement from discovery to decision, showing how Microsoft Purview capabilities work together as a governance loop rather than as separate features.

The starting point: a small estate with real uncertainty

Cascadeen Retail Group is fictional, but its data problem is ordinary. The company has an on-premises order database, a cloud customer relationship management system, and an Amazon Web Services shipment bucket. The systems are known, but the contents are not fully understood. Some teams believe old shipment files may contain payment data. Others suspect customer records have quality problems. Marketing wants to restart an artificial intelligence recommendation project, but the data team cannot yet answer basic questions about risk, ownership, lineage, or fitness for use.

The engagement does not begin with policy writing. It begins with evidence. The team needs to register the sources, scan them, classify the data, make the important assets discoverable, trace quality problems to their cause, and then focus governance effort on the customer fields that matter most.

📌

Scenario boundary. This walkthrough uses Microsoft Purview concepts, but the pattern applies to any governance program that must move from inventory to action.

Step 1 and 2: register the sources, then scan them

The team first registers three known sources in the Data Map, which is the technical inventory that stores metadata about data assets. The on-premises order database is reached through an integration runtime installed inside the corporate network. The cloud customer relationship management system, often shortened to CRM, is connected through its native connector. The Amazon Web Services, or AWS, shipment bucket is reached through the Multicloud Scanning Connector.

Access is deliberately limited. The team uses a role that gives Purview secure, read-only access, which is enough to inspect metadata and supported content patterns without giving the governance platform unnecessary control over business systems. This is a small but important design choice: governance tooling should see enough to classify and catalog data, but it should not receive broad operational privileges by default.

The scans run across all three sources. Within a day, the results are available. At this point the organization has moved from hearsay to inventory. The team can now see discovered assets, schemas, files, and classifications in one place instead of relying on tribal knowledge from application owners.

Three known sources are registered in the Data Map before scanning.

Step 3: use built-in and custom classification together

Classification is where the inventory starts to become useful. Built-in sensitive information types immediately flag credit card number fragments left behind in old shipment records inside the AWS bucket. That finding matters because it confirms a risk the company had discussed but could not prove. The issue is not theoretical anymore; the evidence points to a specific location and a specific class of sensitive data.

The built-in detectors are not enough for everything. Cascadeen also has a proprietary loyalty-card number format that no built-in detector recognizes. The team creates one custom classifier for that pattern so loyalty identifiers can be found and governed consistently across tables and files.

This is the normal shape of classification work. Built-in classifiers handle common patterns such as payment data, government identifiers, and contact information. Custom classifiers close the gap for organization-specific data, especially identifiers that carry business meaning but are not globally standardized.

⚠️

Classification is evidence. A classifier does not fix sensitive data by itself, but it tells the team where risk exists and what kind of control may be needed.

Built-in types catch common patterns; a custom classifier catches proprietary ones.

Step 4: make the data usable through the Unified Catalog

After scanning and classification, the team moves into the Unified Catalog. The catalog is the business-facing layer where technical assets can be grouped, described, owned, and found by people who do not want to inspect raw database schemas or storage paths.

Cascadeen creates a Sales governance domain. Inside that domain, the team defines a Customer Orders data product that bundles the relevant order tables, customer records, and shipment files together. This matters because business users usually search for a usable product, not for a single table buried in a source system.

The team assigns a named business owner from sales operations and attaches a shared Customer glossary term used across the organization. These choices turn the catalog entry from a loose collection of assets into something accountable. A user can see what the data represents, who owns it, and how it relates to the broader language of the company.

Step 5: trace a quality issue to its cause

The next discovery is not about sensitivity; it is about trust. A data quality rule reports that eight percent of customer postal codes are malformed. That number is high enough to distort regional reporting, shipping analysis, and customer segmentation.

Without lineage, the team might have treated the malformed postal codes as a cleanup task inside the current reporting layer. Lineage changes the investigation. By tracing how the data moved through systems and transformations, the team finds that the bad values originated in a legacy import script that ran years earlier and was never fixed.

That finding connects today’s reporting oddities to yesterday’s ingestion defect. The distinction is important. A dashboard can show that a field is wrong, but lineage can show where it became wrong. Once the root cause is visible, the team can decide whether to repair the old data, fix the import logic, add validation at the point of capture, or do all three.

✅

Lineage turns symptoms into fixes. The postal-code issue becomes actionable because the team can trace the defect back to the legacy import script that introduced it.

Lineage traces malformed postal codes back to an old legacy import script.

Step 6: focus governance on critical data elements and one measurable objective

The team does not try to govern every field with equal intensity. Instead, it marks customer date of birth and loyalty account balance as critical data elements, often shortened to CDEs. These fields deserve special attention because they are sensitive, important to business decisions, and carry regulatory weight.

Cascadeen then sets one quarterly objective and key result, or OKR: 95 percent of critical customer data elements must pass their quality rules. This is more useful than a vague promise to improve data governance. It names the scope, defines the measure, and gives leadership a number that can sit beside revenue and other operating metrics.

The OKR also changes team behavior. Data quality is no longer a background engineering concern or an audit-only topic. It becomes a visible operating goal tied to specific customer data and specific owners.

One quarterly OKR: 95 percent of critical customer data elements pass quality rules.

The leadership decision: unblock the AI project with evidence

The practical payoff appears when marketing’s artificial intelligence, or AI, recommendation project resurfaces. Earlier, the project stalled because nobody could answer whether the proposed data was known, sensitive, complete enough, or properly owned. After the mapping work, the conversation is different.

The Unified Catalog now shows what customer and order data exists, where it came from, what it means, who owns it, how it is classified, what its quality score looks like, and where known issues remain. The answer is not simply yes or no. It is a risk-informed decision: proceed with eyes open, apply controls where needed, exclude or remediate weak fields, and keep the most critical customer elements under measurable governance.

This is the business reason for mapping a data estate. The final product is not a static report. It is a better decision made faster, with fewer assumptions. A leader can sponsor the AI effort with a clearer view of risk. A practitioner can build with a clearer view of source, meaning, and quality.

Leaders can decide whether the AI recommendation project is ready to proceed.
Data owners can see which customer fields need remediation or stronger controls.
Engineers can trace poor-quality values back to the system or script that introduced them.
Security and compliance teams can focus on confirmed sensitive data instead of suspected exposure.

The repeatable loop

Cascadeen’s engagement is small enough to follow, but it shows the complete Level 200 pattern: register, scan, classify, catalog, trace, and focus. Each step depends on the step before it. Registration gives the scan a target. Scanning feeds classification. Classification enriches the catalog. The catalog gives users a business entry point. Lineage explains trust problems. Critical data elements and OKRs focus attention where it matters most.

The same loop can be reused at another retailer, a bank, a manufacturer, a university, or a public agency. The systems will change. The sensitive patterns will change. The business terms will change. The engagement shape remains steady: build the map, add meaning, expose risk, find root causes, and turn the findings into decisions.

Key takeaways

Register, scan, classify, catalog, trace, and focus form one governance loop, not six disconnected activities.
Secure, read-only access is usually enough for discovery and helps avoid giving governance tools unnecessary operational privilege.
Built-in classifiers catch common sensitive patterns, while custom classifiers handle business-specific identifiers such as Cascadeen’s loyalty-card number.
Lineage makes data quality work more precise by showing where a defect entered the data flow, not just where it appeared in a report.
Critical data elements and objective and key results turn broad governance intent into measurable business accountability.
The useful end state is an evidence-based decision, such as whether an artificial intelligence recommendation project can proceed and under what controls.

Glossary

Data Map: A technical inventory of data sources and assets, including discovered metadata and classifications.
Integration runtime: A connector component installed in or near a private network so a scanning service can reach on-premises data sources securely.
Customer relationship management: A system used to manage customer, sales, service, and account information, often abbreviated as CRM.
Amazon Web Services: A public cloud platform, often abbreviated as AWS, that can host storage buckets, databases, applications, and other services.
Classifier: A detection rule or model that identifies a type of data, such as a credit card fragment or a proprietary loyalty number.
Unified Catalog: A business-facing catalog where data assets can be described, grouped, owned, searched, and governed.
Lineage: A record of how data moves and changes across systems, pipelines, scripts, and reports.
Critical data element: A data field that is important enough to receive focused governance because of its business value, sensitivity, or regulatory impact.
Objective and key result: A goal-setting method, abbreviated as OKR, that combines a qualitative objective with measurable results used to track progress.