Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 06:36:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md
wenjiefan f8acb6cbdd Scope DataClassification inheritance to fields declared in the table 
Table-level DataClassification is the effective default only for Normal
fields declared inside that table object. A tableextension cannot set the
property (AL0246) and its added fields do not inherit the base table value,
so AS0016 still requires each of them to classify itself. State this in both
privacy articles so the guidance cannot suppress genuine findings on the
tableextension pattern, which is how most partner code adds fields.

Also narrow the inheritance claim to verified AppSourceCop behaviour rather
than asserting platform-level resolution, and make the sample's table-level
default semantically representative of its fields while keeping a legitimate
field-level override and demonstrating the tableextension boundary.

Verified with alc.exe 18.0.37.11445 + Microsoft.Dynamics.Nav.AppSourceCop.dll:
the revised sample produces no AS0016, and removing the explicit
classification from the tableextension field makes AS0016 fire.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-08-17 15:14:53 +02:00

2.2 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
privacy
data-classification
pii
gdpr
customer-content
table-field
under-classified
al
w1
all

DataClassification is required on table fields containing sensitive data

Description

DataClassification tells the platform what kind of data a table field stores so that telemetry, GDPR data-subject requests, and the platform's audit surfaces can treat it correctly. A field declared inside a table object can set its own value or inherit a valid table-level value; a field added by a tableextension has no table-level value to inherit and must always set its own. When neither scope supplies a valid classification, the field remains ToBeClassified — a placeholder meaning "not yet reviewed", not a safe default. Leaving a field that actually holds PII (an email address, a customer name, an employee code) as ToBeClassified, or classifying it as SystemMetadata ("no user or customer data"), are both under-classifications and privacy bugs, even though the code still compiles.

Best Practice

Set DataClassification to the value that matches the data the field actually stores. A Customer."E-Mail"-style field is CustomerContent (data belonging to the tenant's customers); a personal identifier such as an employee number or user ID is EndUserIdentifiableInformation or EndUserPseudonymousIdentifiers depending on whether it is directly identifying. A field that identifies an organization rather than a person — a company registration or VAT registration number — is OrganizationIdentifiableInformation, and a financial account identifier such as a bank account number or IBAN is AccountData. Choose the classification at field definition time — fixing it later is a schema change.

See sample: data-classification-required-on-pii-fields.good.al.

Anti Pattern

Declaring a field that stores PII with DataClassification = SystemMetadata to silence the compiler warning. The field compiles but the platform now treats customer data as system metadata in telemetry, GDPR exports and admin reports.

See sample: data-classification-required-on-pii-fields.bad.al.