Correct table-level data classification guidance - #131
Merged
Wenjie Fan (gggdttt) merged 3 commits intoAug 18, 2026
Conversation
Document that valid table-level classifications are inherited by fields and update the privacy fixture and related guidance accordingly. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Wenjie Fan (gggdttt)
requested review from
Sun Haoran (haoranpb) and
Bugsy (pchriste-microsoft-com)
as code owners
August 17, 2026 11:16
Jesper Schulz-Wedde (JesperSchulz)
approved these changes
Aug 17, 2026
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>
…ation The requirement to declare DataClassification explicitly in a tableextension applies to the Normal fields it adds; FlowFields and FlowFilters are SystemMetadata automatically and are covered by their own article. Being added by a table extension is also not itself a finding - the finding is a Normal field added by a table extension that has no valid explicit DataClassification. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Sun Haoran (haoranpb)
approved these changes
Aug 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DataClassificationis inherited by fields unless they override itPrecision impact
BCApps #9663 received 19 thumbs-down privacy comments caused by the previous guidance requiring redundant field-level declarations. The corrected article should suppress that false-positive pattern while preserving findings for fields whose inherited classification is missing or does not match their data.
The behavior was independently verified with the AL 18 AppSourceCop: AS0016 accepted Normal fields inheriting a valid table classification and reported the equivalent field when no table or field classification existed.
Validation