Classifying the Data

Module 4 of 6 in the chapter Understanding Integration Requirements, chapter 6 of the Integration Architect course. Each module stands on its own. Previous: Steve’s Number of Zeros · Next: Success Factors, Growth and Regulation

The question this module answers: How sensitive is the data on each arrow, and what does that decide about the integration?

Every arrow carries fields. Every field has a level of sensitivity, whether anyone has written it down or not. And the level decides a lot about the arrow: whether the field may leave Salesforce at all, which systems may receive it, how it travels, and what may be kept in the logs along the way. So before you design an integration, you need to know how its data is classified. That’s a requirement, and it’s usually an implied one.

Start With the Company’s Language

Every company already has words for this. “Customer data.” “Need to know.” “Never leaves the building.” Some have a written policy; some have a habit. Before I use anyone else’s words, I want theirs. What is their language of data, and how does it map?

Then map it to a standard set of levels, so everyone, and every system, means the same thing. Salesforce gives every field a Data Sensitivity Level, with five default values (Data Classification Metadata Fields (opens in a new tab), Salesforce Help, checked 2026-11-01):

• Public: anyone may view it, but not change it.
• Internal: employees and contractors; not shared publicly, but it can be shared with customers and partners under a non-disclosure agreement.
• Confidential: an approved group of employees and contractors; not restricted by law or contract, but still shared only under an agreement.
• Restricted: only an approved group; in Salesforce’s words, “likely restricted by law, regulation, an NDA, or a company MSA.”
• MissionCritical: a small group, with heightened requirements for any third party who gets access; almost always restricted by law, regulation or contract.

Most companies never need the fifth. Four levels are the useful set for most, and that’s what Steve Trucking uses. The Data Architect course explains why, and builds the whole protection design on them, in Classify, Then Protect.

The exam’s three words

The integration architect exam asks you to classify data as confidential, secure or public. Those aren’t Salesforce’s field values, so map them. One way to read them: public is Public; confidential covers Internal and Confidential, data for the company and the people it has agreements with; secure is Restricted, and MissionCritical if you have it: data that needs encryption, masking or legal controls. Whatever the words, the question is the same: what is this data allowed to do?

Where Salesforce Keeps It

The classification lives on the field itself. Salesforce gives every standard and custom field four data classification fields, in every edition:

• Data Sensitivity Level: the level, from the list above. You can change the values to match your company’s language.
• Compliance Categorization: the laws and rules that apply to the field’s data. The defaults include GDPR, CCPA, HIPAA, PCI and PII. Module 5 is about those.
• Data Owner: the person or group who understands the data and decides its level.
• Field Usage: whether the field is still in use.

Here’s the part that matters for integration: the classification isn’t just a label on a screen. Salesforce exposes the sensitivity level through its API, so the integration layer can read it, and decide from it, for example, which fields to mask before it writes a log. A classification that a program can read is a classification you can enforce on every arrow, not only in the design document.

What Each Level Means for an Arrow

So what does a level change in an integration? I ask the same questions of every field on every arrow: may it leave Salesforce, who may receive it, what goes in the log, and what goes in a test system?

Click to enlarge

What each level means for an arrow.

Every arrow travels over an encrypted connection, whatever it carries. That protects the data while it moves. But when a Restricted field passes through a system in the middle, the connection isn’t enough: the data sits in the middleware, in a queue, in a file. Then the data itself needs protecting, or it shouldn’t be on that arrow at all.

Only What the Arrow Needs

The best way to protect a field on an arrow is not to send it. Take one Steve Trucking delivery and the status that goes back to Redrock. Which fields does Redrock actually need?

Click to enlarge

Only what the arrow needs.

Redrock needs the window and the status, with its own reference so it can match them. It doesn’t need the route or the truck. It doesn’t need the recipient’s phone: Redrock is the retailer, and it has its own customer’s number. And the gate code never goes into a partner feed. It goes to one crew, on the day, through the crews’ own app.

Notice that chapter 4 asked a similar question about events: send the whole package, or just the ID? Classification is one of the best reasons to send less. A field that isn’t on the arrow can’t leak from the other end.

And remember that the classification travels with the data. A Confidential phone number copied to a partner’s system is still Confidential there, and now you depend on their controls as well as yours.

Watch the Logs

Here’s where integrations leak most quietly. In module 1, logging was a non-functional requirement: you need logs with details, and I’ve even seen logs that keep the whole low-level payload. Now put the classification next to it. If the payload carries confidential data, health information or personal information, every log that keeps the payload keeps that data too, often in a tool with weaker controls than Salesforce, kept for longer than anyone meant.

So for every arrow, the logging requirement says: which fields are logged, which are masked, and which are never logged at all. Confidential: masked. Restricted: never. And because the integration layer can read the classification from Salesforce, it doesn’t have to be a list someone keeps by hand.

What an Architect Decides Here

• The company’s own language of data, and how it maps to Salesforce’s levels.
• That every field an integration carries has a level, an owner and its compliance categories set in Salesforce.
• For every arrow: which fields it carries, and why each one is needed. Everything else stays.
• For every level: who may receive it, how it’s protected in the middle, what’s logged, and what’s in a test system.
• How the integration layer uses the classification to mask what it logs.

Beyond the exam: what AI changes. Classification becomes the guardrail for AI. Which fields may be sent to a model? Which may an agent read, and which may it repeat back to a person? An AI service is one more system at the end of an arrow, and the same rules apply: only the fields its job needs, nothing Restricted without an approved exception, and nothing in a prompt log that you wouldn’t put in any other log. The Data Architect course gives agents and prompts their own column in Classify, Then Protect.

Explore

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab): the four fields and their default values, checked 2026-11-01.
• In the Data Architect course, Classify, Then Protect: the protection matrix, encryption, masking, and why classification travels with the data.