Data Classification in Business Central

Introduction

Many partners treat DataClassification as a property added just to stop AppSourceCop from complaining.

In SaaS, that mindset is incomplete.

In Business Central online, DataClassification is not just a development property — it is a compliance signal that connects:

• AL development
• Privacy tooling
• Telemetry safeguards
• Tenant governance processes

Microsoft requires that fields of class Normal must have a DataClassification value and must not remain ToBeClassified (enforced by AppSourceCop rule AS0016 and part of technical validation).

But the reason goes beyond validation.

In a regulated, cloud-first environment, metadata influences behavior.

This article explains:

• What DataClassification actually does
• How it connects to the Business Central client
• How it impacts privacy tooling and telemetry
• The difference between developer classification and customer sensitivity
• The governance responsibilities across roles

---

1. What DataClassification Is (From a Developer Perspective)

DataClassification is an AL property defined on table fields.

Example:

field(50101; "Personal Email"; Text[100])
{
    DataClassification = EndUserIdentifiableInformation;
}

For fields of class Normal:

• The property is mandatory.
• The value must not remain ToBeClassified.

It defines the intended nature of the data stored in that field.

However, it does not:

• Control permissions
• Encrypt data
• Mask fields
• Override security roles

It is not a security feature.

It is metadata used for privacy and compliance mechanisms.

---

2. Why It Exists in SaaS

In on-prem deployments, customers manage compliance largely on their own.

In SaaS:

• Microsoft operates the infrastructure.
• Privacy regulations (GDPR and others) apply globally.
• Customers expect export and privacy tooling to work accurately.
• Telemetry must not leak personal data.

To support this, the platform must understand what kind of data fields contain.

DataClassification provides that signal.

Without accurate classification, privacy tooling cannot reliably identify which fields contain personal or sensitive information.

In SaaS, metadata drives compliance processes.

---

3. Classification Types — Business Meaning

CustomerContent

Operational business data.

Examples:

• Sales amounts
• Inventory quantities
• Document numbers

Business data, not necessarily personal data.

---

EndUserIdentifiableInformation

Personally identifiable information (PII).

Examples:

• National ID
• Personal email
• Phone number
• Home address

Critical for GDPR-related processes.

---

OrganizationIdentifiableInformation

Company-level identifiers.

Examples:

• VAT number
• Registration numbers

---

AccountData

Subscription or billing-related metadata.
Rarely used in partner-developed extensions.

---

SystemMetadata

System-generated technical data.

---

ToBeClassified

Temporary placeholder.
Should not remain in production solutions.

---

4. What It Impacts — and What It Does Not

Clarity here prevents architectural confusion.

It Impacts

• Privacy tooling interpretation
• Data subject export processes
• AppSource validation
• Governance reviews
• Telemetry emission decisions

Microsoft documentation confirms that the Business Central server evaluates DataClassification when determining whether telemetry events may contain personal data.

---

It Does Not Impact

Feature	Controlled by DataClassification?
User permissions	No
Security roles	No
Encryption	No
Field masking	No
Access control	No
Data retention rules	No
Privacy export tooling	Yes
Telemetry filtering logic	Yes

Security and privacy are separate concerns.

---

5. Important Telemetry Nuance (For Technical Consultants)

DataClassification influences platform-level telemetry safeguards.

However, it does not automatically mask data if a developer explicitly logs a field value.

For example:

Telemetry.LogMessage('ID', MyRecord."National ID");

If you log personal data directly, the classification property does not automatically protect you.

Developers must still write privacy-aware telemetry.

Classification supports the platform — it does not replace responsible coding.

---

6. From AL to the Client: The Data Classification Worksheet

Developers define the intended classification in AL.

Tenant administrators can then review and adjust classifications using the Data Classification Worksheet in the Business Central client.

This enables:

• Reviewing personal data fields
• Setting data sensitivity
• Supporting GDPR export processes

This is the operational bridge between:

• Developer intent
• Customer compliance reality

---

7. DataClassification vs Data Sensitivity (Common Confusion)

Two related but distinct concepts exist:

Developer (AL)	Business Central Client
DataClassification	Data Sensitivity
EndUserIdentifiableInformation	Personal / Sensitive
CustomerContent	Normal / Confidential
SystemMetadata	System-controlled

DataClassification
Set by developers in AL.
Describes intended data type.

Data Sensitivity
Managed by tenant administrators.
Used for operational privacy processes.

Confusing these leads to governance gaps.

---

8. Shared Responsibility Model

Data classification is not owned by one role.

Action	Primary Owner	Tool
Set default classification	Developer	AL DataClassification property
Review privacy design	Architect / Consultant	Solution design documentation
Adjust sensitivity	Tenant Admin	Data Classification Worksheet
Handle GDPR request	Customer / Privacy Officer	Privacy & export tools
Write safe telemetry	Developer	Privacy-aware AL code

This is a governance ecosystem — not a single checkbox.

---

9. Common Consultant Mistakes

Leaving everything as ToBeClassified
Signals unfinished governance.

Marking everything as CustomerContent
Avoids thinking and reduces precision.

Misclassifying personal data
Undermines privacy tooling accuracy.

Treating classification as purely technical
It belongs in solution design workshops.

Ignoring third-party extensions
Compliance posture depends on the entire extension landscape.

---

10. Metadata Is Architecture

In SaaS systems, metadata is operational.

It influences:

• Privacy tooling
• Telemetry safeguards
• Compliance interpretation
• Customer governance workflows

Treating DataClassification as a compiler requirement reflects an on-prem mindset.

In cloud systems, metadata affects behavior.

---

Conclusion

Data Classification in Business Central is:

• Not a security control
• Not a UI feature
• Not encryption

It is a governance signal that connects:

• AL development
• Privacy tooling
• Telemetry safeguards
• Tenant-level compliance management

For mixed business and technical consultants, the key insight is this:

DataClassification is the bridge between code and compliance.

In SaaS, ignoring metadata is not neutral.

It is a design decision.