Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 09:26:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/community/knowledge/security/classify-every-field-with-dataclassification.md
Jesper Schulz-Wedde 9a4198eb28 Add [all] sentinel to bc-version; apply to version-agnostic knowledge 
Most of the corpus — FindSet/SetLoadFields/CalcFields patterns, permission
sets, SingleInstance codeunits, DataClassification, IsolatedStorage,
transaction scope, SecretText — describes BC platform behaviour that is
identical across supported versions. The seed [26..28] range on every
file implied a version-specificity the content does not actually have,
and there was no way to express "applies to every version" in the
schema the way [w1] and [all] already do for countries and
application-area.

Extend the v1 schema with a universal sentinel for bc-version, parallel
to the sentinels already defined for the other dimensions:

  bc-version: [all]         # applies to every BC version

[all] is mutually exclusive with explicit versions. Range shorthand
([26..28]) and explicit lists ([26, 27, 28]) continue to work for files
genuinely tied to a version-gated API or deprecation.

Update read.md (field definition, matching semantics, partial-context
rule), write.md (default to [all], use ranges only with a concrete
reason), README.md (frontmatter example), and the CI validator. All
forty existing knowledge files and the three action skills convert to
[all]; none of the current content is version-gated. Validator passes.
2026-04-23 16:00:03 +02:00

1.5 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
security
dataclassification
gdpr
privacy
euii
compliance
al
w1
all

Classify every field with DataClassification

Description

Every field on every AL table and table extension must carry an explicit DataClassification property. The value drives GDPR tooling, data-subject requests, retention policies, and audit reporting — all of which rely on the field metadata to know what data to include, anonymize, or delete. A field with no DataClassification defaults to ToBeClassified, which is a compliance gap, not a neutral state.

Best Practice

Choose the narrowest value that accurately describes the field's content: EndUserIdentifiableInformation for data that directly identifies a person, EndUserPseudonymousIdentifiers for indirect identifiers, CustomerContent for business operational data, SystemMetadata for system-generated housekeeping, AccountData for tenant/billing, OrganizationIdentifiableInformation for organization-level identifiers. When uncertain between two values, pick the stronger protection.

See sample: classify-every-field-with-dataclassification.good.al.

Anti Pattern

Leaving DataClassification = ToBeClassified on a field, or omitting the property entirely (which resolves to the same default). Code in this state fails compliance audits and breaks the subject-access-request and retention tooling that depends on the property being set correctly.

See sample: classify-every-field-with-dataclassification.bad.al.