Chain of Command in D365 F&O: three production pitfalls

Chain of Command became the default pattern for F&O customizations because the overlay approach was unsustainable - every One Version update broke something, and partners spent their upgrade budget repairing customizations that should have been forward-compatible by design. CoC lets an extension wrap a base method with next() and skip the overlay dance entirely.

The mechanism takes a minute to read. Three failure modes show up in production often enough to document.

Pitfall 1: forgetting next() when augmenting

Teams new to CoC often write validation extensions that look like this:

The bug: no next validateWrite() call. The base method never runs, so all stock validations silently vanish. Unit tests that exercise only the custom-check path pass. The missing base validations don't surface until data that the base would have rejected makes it through to production.

When the intent is to add logic rather than replace it, call next() first and combine the result:

Skipping next() is legitimate sometimes - but it should be deliberate, commented, and reviewed. The accidental skip is where silent data-integrity bugs live.

Pitfall 2: picking the wrong lifecycle hook

FormDataSource.init() runs before records are loaded. Extension code that reads this.cursor() or assumes a record context will throw or behave unpredictably. Teams shipping dynamic filters often put the logic in init() because that's the first hook they see, then get a crash the first time a user with an empty dataset opens the form.

The form-level lifecycle hooks each have a purpose:

• init() - form-level setup, no data yet
• executeQuery() - after query is built, before fetch
• active() - after a record is active on the data source
• Pre/post-event handler on executeQuery - the cleanest way to mutate the query without overriding the base

For dynamic filtering from a parameter table, a pre-event handler on executeQuery lets you modify the query's ranges with the data context available via the event args. No crash, no base-method override, no brittle downstream coupling.

Pitfall 3: reaching for private or protected members

CoC extensions can't access private or protected members of the base class. Developers migrating from overlay-era F&O hit this first:

Microsoft's extension framework documents four options:

1. Hookable base method - if the private behavior is surfaced through a public method, call that.
2. Sibling class access - occasionally a public class exposes enough of what you need.
3. Event handler on a method that exposes data via args - the cleanest path.
4. Request access via LCS Issue Search - Microsoft has opened many members in response to partner requests over successive One Version releases.

Reaching for reflection is the wrong answer. It works until the next compile shifts member layout and you're back to overlay-level fragility.

Debugging a silent extension

The most frustrating CoC failure is an extension that compiles, deploys, and does nothing at runtime. Root causes that show up in reviews of working F&O codebases:

• [ExtensionOf] attribute points to the wrong target - typo in formStr() / tableStr() / classStr().
• The extension class isn't final - required for CoC.
• The method signature doesn't match exactly - parameter type mismatches silently skip.
• The model containing the extension isn't in the target environment's model list.

First diagnostic step: drop info("hit") at the top of the method, recompile, exercise the scenario, check the Infolog. If nothing appears, one of the above is wrong.

Code review as insurance

Teams running healthy F&O codebases treat CoC extensions with a PR-time checklist: next() called correctly, appropriate lifecycle hook chosen, no private-member access attempts, unit test coverage via SysTest. The fifteen minutes per PR is the insurance policy that keeps One Version updates from turning into weekend outages.