- Scope both articles to bc-version [22..]: FindOrCreateRetentionPeriod
first appears in the 21.1 System Application and OnRefreshAllowedTables
in 22.
- Reframe the default-setup article as optional guidance; registration
without a setup is valid. The anti-pattern and review routing now cover
only false claims that registration alone cleans up data.
- Make all four samples self-contained: declare Contoso Activity Log in
each, add the Retention Policy Setup permission, and guard the default
setup on IsAllowedTable.
- Let evaluation overrides list additionalArticles and register both
retention pairs as extra privacy cases (38 cases, existing IDs unchanged).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Two articles covering retention policies for extension-owned tables,
the gap that lets high-volume log tables grow unbounded:
- register-owned-log-tables-for-retention-policies: an extension's own
log tables must be added to the allowed-tables list from install AND
upgrade code, guarded by IsAllowedTable plus an upgrade tag, with a
mandatory minimum retention where audit needs one.
- ship-a-default-retention-policy-setup: registration only makes a table
selectable; nothing is deleted until a Retention Policy Setup record
exists, so ship one (disabled by default) as the platform's own
Retention Policy Installer does.
Each ships good/bad AL samples. Claims verified against the BC admin
docs and the Retention Policy module in microsoft/BCApps.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011gvTjm746MtJEVWeRTbG46
