Data classification and GDPR in extensions: the property you must set on every field
Every field in Business Central carries a DataClassification, and the platform uses it to answer data subject requests, to drive the data privacy tooling and, increasingly, to decide what Copilot may see. Extensions that leave it at the default make the customer non-compliant without knowing. What the values mean, how to choose, the tooling that reads them, and what else GDPR needs from an extension.
Under UK GDPR a business has to be able to say what personal data it holds, where, why, and to export or delete it on request. Business Central answers "where" from the DataClassification property on every field and table. If your extension's fields are all ToBeClassified (the compiler's placeholder) or wrongly SystemMetadata, the customer's data inventory is wrong, and the tooling that generates it is lying.
The values
CustomerContent: data the customer entered that is theirs: names, addresses, amounts, descriptions, anything on a document. Most fields.
EndUserIdentifiableInformation: data that identifies a user of the system: user IDs, names, email of employees.
EndUserPseudonymousIdentifiers: identifiers that can be linked back to a user indirectly: SystemIds, session IDs.
OrganizationIdentifiableInformation: identifies the organisation: company name, VAT number.
AccountData: credentials and account information: tokens, keys (which should be in Isolated Storage anyway).
SystemMetadata: data the system generates with no personal content: flags, enum values, timestamps that are not about a person, your log's status field.
The default on a new table is CustomerContent at table level, and fields inherit unless overridden. Set it deliberately on every table and on any field that differs.
What reads it
Data Classification worksheet (Data Administration): the inventory the DPO uses; it lists every field with its classification and lets the administrator refine it (sensitive, personal, company confidential, normal) per field.
Data subject requests: the Data Privacy Utility exports everything about a data subject (a customer, a contact, an employee) using the classification and the data subject's related tables; your table is included only if it is classified as containing personal data and has a relation the tool can follow (DataPrivacyEntities registration via OnGetDataPrivacyEntities).
Telemetry: Session.LogMessage takes a classification; it decides what is permitted in the dimensions. Never log CustomerContent.
Copilot and agents: increasingly, what the AI features may read is bounded by classification and by the AI module's data handling settings.
Registering a data subject
If your extension has a table that is about people (a driver, a visitor, a contact of your own), subscribe to OnGetDataPrivacyEntities in Codeunit "Data Privacy Entities" and call DataPrivacyEntities.InsertDataPrivacyEntity(...) with the table, the key field, the page, and the privacy-blocked field if you have one. Then the export and the "privacy blocked" workflow include it.
Beyond classification
Minimise. Do not store personal data you do not need. A courier shipment needs a name and address; it does not need to copy the contact's date of birth.
Retention. Personal data in logs and staging tables is the first thing a DPO asks about; retention policies are the answer.
Outbound. Every external API you send personal data to is a processor; the business needs it on the register. Document which fields your integration sends where.
Sandboxes. A copy of production is a copy of the personal data. The environment plan (environments post) has to say who may see it.
The analyser warns on ToBeClassified; treat it as an error in the pipeline, and classification stops being something that is fixed after the audit.
Email this post as a PDF
A branded PDF of this post, sent to your inbox to keep, print or share. Copy in colleagues if you like.
We only use these addresses to send this PDF. Nobody is added to a mailing list. Mike at Business Boxed receives a copy. See our privacy notice.
