2b5550c346
Lead with a complete plugin quick start and add task-oriented usage, troubleshooting, customization, and contribution guides. Preserve the broader plugin framing, correct conflicting contract guidance, support Agents folder reviews, and align repository validation. Convert existing sample references to clickable links without changing knowledge rules. Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
3 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
data-modeling |
|
|
|
|
ValidateTableRelation = false suppresses rename propagation, not just input validation
Description
Renaming a record updates it in all other locations that reference it through a TableRelation, with no code. That guarantee has two preconditions, and a field failing either one is silently left holding a key that no longer exists.
First, a TableRelation must exist. A field whose value is constructed or computed — a composite key, or a value derived from several fields of the target — cannot declare one, so nothing propagates. The field is still a foreign key in intent, but the platform treats it as an opaque value.
Second, and far less obvious: the relation must not carry ValidateTableRelation = false. The property name implies it only governs input validation, so it looks safe to disable on a field populated by code that already knows the target is valid. It is not. Disabling it also switches off rename propagation. The relation still documents intent and still drives lookups, but it no longer keeps the stored value correct.
Both failures are quiet: no error at rename time, and in the first case no input validation either, so a wrong value is never rejected on write.
This is verified behaviour, not inference. A parent renamed once against a child holding three fields — a normal relation, the same relation with ValidateTableRelation = false, and a field with no relation — updates only the first.
See also owning-table-must-delete-dependents-in-ondelete.md for the delete half of this asymmetry, and xrec-is-a-before-image-only-in-some-triggers.md for why OnRename is the one trigger where a hand-written fix-up is reliable.
Best Practice
Leave ValidateTableRelation at its default wherever the stored value must stay correct across a rename. When it must be disabled, or when the relationship cannot be expressed as a TableRelation at all, the table owning the referenced key carries an explicit OnRename that repoints the dependents itself.
See sample: validate-table-relation-false-suppresses-rename-propagation.good.al.
Anti Pattern
ValidateTableRelation = false added to silence a validation error, on a field expected to keep tracking its target. The field stops being maintained on rename, and the defect surfaces much later as a reference to a key that no longer exists.
Detection signal: any ValidateTableRelation = false on a field that also declares a TableRelation. Ask what repoints the value when the target is renamed; if the answer is "the platform", the finding stands.
See sample: validate-table-relation-false-suppresses-rename-propagation.bad.al.