Dictionary, Lineage and Classification

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 3 of 6 in the chapter Data Quality and Governance, chapter 5 of the Data Architect course. Each module stands on its own. Previous: Keeping Bad Data Out · Next: Privacy Laws Shape the Design

The question this module answers: How do you capture what data means, where it came from, and how sensitive it is?

You’ve inherited an org. Account has 900 fields, among them Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c and Account_Status__c. Which one tells you whether somebody is actually a customer? You open the descriptions. Three are blank. One says “Customer Type.” Thank you. One says it came from the ERP; another was created six years ago by someone long gone. Now imagine you’re not the architect but an integration, a reporting team, or an agent. The organization has plenty of data. That doesn’t mean it knows what the data means.

That’s where metadata becomes architecture, through three questions that are related but not the same:

• Dictionary: what does this data mean?
• Lineage: where did it come from?
• Classification: how must it be treated?

Two Kinds of Metadata

Metadata comes in two kinds, and you need both. Business metadata is what the data means to the business: the definition, the owner, the rules for using it, how sensitive it is. Technical metadata is how it’s built and moves: the object and field, the type and length, the API name, the schema, the mapping from one system to another, the lineage from source to target. A field’s API name and type tell a developer how to use it; its definition and owner tell everyone else whether to. When they disagree, or one is missing, that’s where integrations and reports go wrong.

Test knowledge. Know business metadata (meaning, definitions, owner, rules, sensitivity: the business dictionary and classification) from technical metadata (objects, fields, types, API names, schemas, mappings and lineage).

Start With Meaning

Chapter 3 set the rule: every field gets a description. Not “Customer Status” for a field called Customer Status, but something like “The partner’s current commercial relationship with Steve Trucking. Set from the ERP after activation. Don’t use for prospect qualification.” Now I know what it means, where it comes from and what not to use it for. That’s the start of a business dictionary: common definitions for the data that matters. What’s a customer? An active customer? What does Delivered mean? What counts as on time? These sound obvious until you put five departments in a room: Finance has one definition, Sales another, Operations a third, the warehouse a fourth, and somebody built a dashboard on a fifth. The problem isn’t that nobody speaks English. It’s that the enterprise hasn’t agreed on the meaning.

A dictionary can live in a spreadsheet or a documentation tool, but its important definitions need to sit close to where people use the data. On the platform, that’s field descriptions, help text and the classification metadata. In analytics it matters even more: “revenue” can’t mean one thing on the executive dashboard and another in an analyst’s query. That’s what a semantic layer is for, and Data 360’s semantic models hold governed definitions such as metrics, dimensions and relationships above the physical data (Create a Semantic Model in Data 360 (opens in a new tab)). The technology changes; the requirement doesn’t: important data needs an agreed meaning.

And start with the meaning, not the technology. A dictionary that begins with object, field, type and API name documents the implementation. One that begins with business terms documents the enterprise:

Business term	Meaning	Where it’s represented
Retail Partner	A retailer Steve Trucking delivers for, under contract	Salesforce Account; finance ERP customer
Delivery	One delivery to one Recipient, at one address, on one day	RouteDesk today; a work order once deliveries move into Salesforce
Recipient	The person receiving a delivery	Recipient details on the delivery
Delivered	Completed according to the agreed operational definition	Delivery status
On-time delivery	Completed within the agreed delivery window	Derived metric

Click to enlarge

One meaning, many technical representations.

Then Ask Where It Came From

Once I know what a value means, I want to know where it came from. That’s lineage. A partner’s legal name in Salesforce: did a rep type it, did the ERP send it, did an integration transform it, did Data 360 unify it, was it calculated, did AI generate it? Those affect how much I trust it and what I may do with it. Remember module 2’s provisional records: two accounts can both say “Keystone,” one created by a rep yesterday, the other from the ERP with an authoritative identifier. Same text, different lineage, different treatment.

Lineage isn’t only a data engineer’s diagram of a thousand tables. For important data I want to answer practical questions: where did it start, which system is authoritative, what transformed it, which systems got copies, what last changed it, and can I trace a derived value back to its sources? Chapter 4’s landscape says the systems are connected. Lineage says what happened to the data on the way.

Some lineage comes for free: the ERP ID on the account, Created By and Last Modified By, integration logs, mapping documents. Data 360 adds lineage fields to its data objects that record the data source and source object for each record (Data Lineage Fields (opens in a new tab)). But don’t assume lineage appears because systems are integrated. Sometimes the most useful lineage is one field: Source System = Keystone. And if the source matters to governance, make it mechanically reliable, set by the integration, not typed by a person.

Derived data needs lineage most of all. Say Steve Trucking computes a late-delivery risk from truck position, the delivery window and route history, and dispatch uses it to prioritize. Where did “high” come from? Add an agent telling a Recipient “your delivery is running late,” and you need to know what grounded that, and how fresh it was. The further you move from stored values to calculated, unified, predicted and generated ones, the more lineage matters.

Classification Answers a Different Question

Now: how should it be treated? Recipient name, delivery address, phone number, delivery notes, delivery status, truck number, distribution center, Retail Partner, photo: they’re not equally sensitive. “Out for delivery” isn’t a phone number, and a DC code isn’t a photo of the inside of someone’s home. Salesforce lets you record this on each field, standard or custom: Data Owner, Field Usage, Data Sensitivity Level and Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Chapter 3 called them the taxonomy fields, and why they matter: flag a field PII or GDPR and processes can find it, from masking tools to Salesforce’s AI trust layer, which can keep flagged values from reaching a large language model. One caution from chapter 3: Salesforce now disables that LLM masking for agents, because it can strip the context an agent needs (Classify What Matters: the Taxonomy Fields). So classification still has to drive the other controls.

My position here is deliberate: classify the sensitive fields, not every field. I don’t want three months spent classifying thousands of fields so someone can report “100% classified” and nobody uses it. The Recipient’s phone number: yes. Home address: yes. Delivery notes that may hold gate codes and “dog in the yard”: yes. Photos that may show people or a home: absolutely. An internal display label? Not where governance energy should go. That doesn’t make undocumented fields acceptable. Two different jobs: documentation is broad; classification is deliberate. That’s what keeps classification meaningful.

A Taxonomy People Can Use

Classification needs a vocabulary, a taxonomy. Salesforce’s defaults run Public, Internal, Confidential, Restricted and MissionCritical; your organization may want its own labels. I’m not prescribing them. Keep them understandable: if there are 47 categories and nobody outside the privacy team can tell category 31 from 32, it isn’t helping. A good taxonomy connects a label to behavior. If a field is sensitive personal data, who can see it, can it go to a sandbox, leave the region, appear in analytics, how long is it kept, may an agent use it? Now classification is doing work.

Classification Without Enforcement Is Decoration

Mark the Recipient’s phone number sensitive and change nothing else, and you’ve written documentation. Useful, but governance goes further: classification should drive permissions, masking, encryption, retention, consent, data movement, sandbox use, audit and AI access. Some of that is the architect’s design decision; some platforms now apply tags and classifications directly in policy, as Data 360 governance does (Data Governance in Data 360 (opens in a new tab)). And marking a field Restricted doesn’t stop anyone reading it. Classification says how a field should be treated; security makes it so. The sequence is: identify the data, understand it, classify what matters, then apply the controls that classification calls for.

Click to enlarge

Three questions about your data, and the third has to drive something.

Reference Data Needs Metadata Too

Country codes, delivery statuses, DC codes, partner identifiers, cancellation reasons: they look simple until two systems disagree. One says CANCELLED, another CANCELED, a third CNCL, a fourth 9. Reference data needs definitions, an owner, a source, a lifecycle where values change, and mappings when systems represent it differently. Small values can drive very large processes. Chapter 6 goes further.

All Three Together

Take Recipient phone number. Dictionary: the number used to reach the person receiving a specific delivery. Lineage: from the Retail Partner’s manifest. Classification: personal data. Now the architecture questions are possible: may the crew see it, and for how long (the brief says only for their own stops, only on the day); can it go to a sandbox; does Snowflake need it; may an agent use it; what happens when the delivery is done?

Now take delivery status. Dictionary: the delivery’s current operational state. Lineage: set by Steve Trucking’s delivery process and sent back to each partner through its own integration. Classification: operational, not sensitive. Different data, different treatment. That’s the point.

I don’t treat metadata as documentation produced after the real architecture is done. If I can’t say what a field means, I don’t understand the data model. If I don’t know where a value came from, I don’t understand the integrations. If I don’t know whether it’s sensitive, I don’t understand the security. Metadata describes the architecture, and sometimes drives it.

Beyond the exam: what AI changes. Classification is becoming the switch for what an agent may retrieve or repeat, and lineage has to reach all the way to the agent’s answer or action. If an agent tells a Recipient the delivery is late, the architecture should be able to say what grounded that, where it came from, and whether the agent was allowed to use it. “Somewhere in Salesforce” isn’t lineage, and “customer data” isn’t a classification.

What an Architect Decides Here

• Which business terms need governed definitions, so systems and teams don’t give one word different meanings.
• How important values keep enough lineage to show their source, authority and transformations.
• Which fields carry sensitivity or compliance meaning and so get explicit classification.
• Which taxonomy the organization uses, and whether people can apply it consistently.
• How classification drives real controls rather than sitting unused.

Before you govern data, know what you have: what it means, where it came from, how it must be treated. Document broadly, classify deliberately, keep lineage where it matters. Otherwise you don’t govern the data. You just have it.

Explore

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) and Create a Semantic Model in Data 360 (opens in a new tab), checked 2026-10-14.