{"id":1409,"date":"2026-04-27T05:34:36","date_gmt":"2026-04-27T05:34:36","guid":{"rendered":"https:\/\/cloudclif.com\/blogs\/?p=1409"},"modified":"2026-04-27T05:40:34","modified_gmt":"2026-04-27T05:40:34","slug":"event-handlers-vs-chain-of-command-the-real-decision-framework-for-2026","status":"publish","type":"post","link":"https:\/\/cloudclif.com\/blogs\/2026\/04\/27\/event-handlers-vs-chain-of-command-the-real-decision-framework-for-2026\/","title":{"rendered":"Event Handlers vs Chain of Command: The Real Decision Framework for 2026"},"content":{"rendered":"\n

Reading time: ~9 minutes.<\/em>\u00a0<\/p>\n\n\n\n

Yesterday’s post argued that Chain of Command is usually the right tool for overriding F&O method logic. That was deliberately one-sided \u2014 you can’t teach a decision framework in one post. Today is the other side. Event handlers still have a clear, non-trivial place in every real F&O codebase, and choosing between the two is a daily call that no Microsoft Learn page walks you through. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This post takes the short decision table from yesterday and stress-tests it \u2014 showing what each tool actually does, the sharp edges of each, and a scenario-by-scenario walkthrough that closes with a practical flowchart. <\/p>\n\n\n\n

If you\u00a0haven’t\u00a0read the CoC post yet:\u00a0Chain of Command in D365 F&O<\/a>\u00a0<\/p>\n\n\n\n

The three kinds of “event handler” \u2014 they are not the same<\/strong> <\/p>\n\n\n\n

First, a clarification that saves hours of confusion later. When F&O developers say “event handler,” they mean one of three different things. Microsoft’s docs treat them as one family, but the decision calculus is different for each. <\/p>\n\n\n\n

1. Pre\/Post handlers on methods \u2014 <\/strong>the [PreHandlerFor] and [PostHandlerFor] attributes. These wrap a specific method the same way CoC does, and they’re the direct alternative to CoC for method-level logic overrides. <\/p>\n\n\n\n

2. Data\/form event handlers \u2014 <\/strong>[DataEventHandler] for table events (OnInserting, OnInserted, OnUpdating, and so on), and [FormEventHandler], [FormDataSourceEventHandler], [FormControlEventHandler] for their form equivalents. These are not<\/em> method overrides. They are framework events \u2014 hooks that fire at specific lifecycle points, and CoC has no equivalent for most of them. <\/p>\n\n\n\n

3. Delegate subscribers \u2014 <\/strong>[SubscribesTo]. Microsoft (and well-designed ISV code) publishes delegate declarations at designated extension points. You subscribe to them with the SubscribesTo attribute. This is the cleanest, most forward-compatible form of extension \u2014 when a delegate exists for what you need, use it. <\/p>\n\n\n\n

Conflating these three is the source of most of the “I’ve heard CoC is better” confusion you’ll see in community threads. CoC only competes with category 1. For categories 2 and 3, there is no CoC alternative \u2014 handlers are the only game in town. <\/p>\n\n\n\n

Pre\/Post handler anatomy \u2014 the version that actually competes with CoC<\/strong> <\/p>\n\n\n\n

A Pre or Post handler is a static method on a class, decorated with an attribute that binds it to a specific base method. The handler receives a single XppPrePostArgs parameter that carries this, the method arguments, and (for Post handlers) the return value. <\/p>\n\n\n\n

public static class MyTableEventHandler \n{ \n    [PostHandlerFor(tableStr(SalesTable), tableMethodStr(SalesTable, validateField))] \n    public static void SalesTable_Post_validateField(XppPrePostArgs _args) \n    { \n        SalesTable salesTable = _args.getThis(); \n        FieldId   fieldId    = _args.getArg(\"_fieldId\"); \n        boolean   ret        = _args.getReturnValue(); \n\n        \/\/ additional validation here \n        _args.setReturnValue(ret); \n    } \n} <\/code><\/pre>\n\n\n\n
That’s the pattern. Compared to the CoC version of the same override, note what’s happening: <\/p>\n\n\n\n
    \n
  • The handler is\u00a0static. No instance. No access to protected members of the base class.\u00a0<\/li>\n<\/ul>\n\n\n\n
      \n
    • Arguments are retrieved by string name \u2014\u00a0_args.getArg(“_fieldId”). If Microsoft later renames the parameter, the string still “compiles” but silently returns the wrong value (or null). This is the brittleness Microsoft warns about.\u00a0<\/li>\n<\/ul>\n\n\n\n
        \n
      • Return value is read and written through the\u00a0args\u00a0object rather than by expression. Fine in Post; meaningless in Pre (you can\u00a0setReturnValue\u00a0in a Pre\u00a0handler\u00a0but it\u00a0won’t\u00a0influence the base method \u2014 the base method\u00a0hasn’t\u00a0run yet).\u00a0<\/li>\n<\/ul>\n\n\n\n
        Microsoft’s official documentation on this page (learn.microsoft.com\/…\/xpp-events) contains one of the most useful sentences in the entire F&O dev reference: “Pre and Post handlers can easily break as the result of added or removed parameters, changed parameter types, or because methods are no longer called, or called under different circumstances.”<\/em> That’s Microsoft telling you, on their own reference page, that these handlers are inherently more fragile than CoC. Worth reading twice. <\/p>\n\n\n\n
        Data event handlers \u2014 the non-negotiable use case for handlers<\/strong> <\/p>\n\n\n\n
        Table events like OnInserting, OnInserted, OnUpdating, OnDeleting, OnDeleted, OnValidatedField don’t correspond to a specific X++ method you can wrap. They are framework events raised by the kernel around data operations, many of them implemented in the runtime rather than in X++ code. You cannot CoC-wrap them. A [DataEventHandler] subscription is the only extension mechanism. <\/p>\n\n\n\n
        [DataEventHandler(tableStr(CustTable), DataEventType::Inserting)] \npublic static void CustTable_onInserting(Common _sender, DataEventArgs _e) \n{ \n    CustTable custTable = _sender as CustTable; \n    \/\/ enrich the record before the insert actually runs \n} <\/code><\/pre>\n\n\n\n
        Same pattern for form controls (OnClicked, OnModified) and form data sources (OnInitialized, OnActivated, OnWritten). None of these have a CoC alternative. If someone tells you “always use CoC,” they’ve never had to react to a form-load event. <\/p>\n\n\n\n
        Delegate subscribers \u2014 the cleanest extension point when one exists<\/strong> <\/p>\n\n\n\n
        Microsoft publishes delegate declarations at many designated extension points throughout standard F&O code \u2014 particularly in posting, validation, and pricing flows. These are explicit invitations to extend behaviour cleanly. When a delegate exists for the scenario you need, it is almost always the right answer, ahead of both CoC and Pre\/Post handlers. <\/p>\n\n\n\n
        [SubscribesTo( \n    classStr(FMRentalCheckoutProcessor), \n    delegateStr(FMRentalCheckoutProcessor, RentalTransactionAboutToBeFinalizedEvent))] \n\npublic static void RentalFinalizedEventHandler( \n    FMRental rentalRecord, Struct rentalConfirmation) \n{ \n    \/\/ respond to the published event \n} <\/code><\/pre>\n\n\n\n
        Two properties make delegates the safest choice when available. First, the method signature is enforced at compile time \u2014 a signature change in the base class fails your build instead of silently breaking your handler (unlike Pre\/Post handlers). Second, delegates are Microsoft’s explicit contract that this is a supported extension point<\/em>. They are less likely to move or be re-implemented in future updates than a randomly-chosen internal method. Docentric’s writeup on delegates has the best community-level explanation I’ve found of how return-value-carrying delegates work using EventHandlerResult \u2014 linked below. <\/p>\n\n\n\n
        The capability comparison \u2014 side by side<\/strong> <\/p>\n\n\n\n
        The short table from yesterday was a decision helper. Here’s the fuller capability grid \u2014 each row is something that either tool can or can’t do:<\/p>\n\n\n\n
        Capability<\/strong> <\/td>Chain of Command<\/strong> <\/td>Event Handler<\/strong> <\/td><\/tr>
        Access to protected members of the base class <\/td>Yes<\/strong> <\/td>No \u2014 the classic limitation <\/td><\/tr>
        Runs in the same transaction scope as the method <\/td>Yes<\/strong> <\/td>Different context \u2014 use carefully in ttsbegin blocks <\/td><\/tr>
        Can change return value <\/td>Directly<\/strong> <\/td>Yes, via args.setReturnValue() in Post handler <\/td><\/tr>
        Can change method parameters <\/td>Directly on the arguments to next<\/strong> <\/td>Indirectly, via args.getArg\/setArg <\/td><\/tr>
        Works on framework\/data events (OnInserting, OnModified, etc.) <\/td>No <\/td>Yes \u2014 this is what event handlers are for<\/strong> <\/td><\/tr>
        Works on Microsoft-published delegates <\/td>No <\/td>Yes, via [SubscribesTo]<\/strong> <\/td><\/tr>
        Call order is guaranteed <\/td>No \u2014 random<\/strong> <\/td>No \u2014 attribute-bound, no sequence guarantee <\/td><\/tr>
        Forced to invoke the base behaviour <\/td>Yes (must call next, except on [Replaceable])<\/strong> <\/td>No \u2014 pre\/post are strictly around the base, never instead of it <\/td><\/tr>
        Brittle to base-method signature changes <\/td>Compile-time error if signature drifts<\/strong> <\/td>Silent break: handler stops firing or args resolve wrong <\/td><\/tr><\/tbody><\/table><\/div><\/figure>\n\n\n\n
        Four real scenarios \u2014 and the correct choice for each<\/strong> <\/p>\n\n\n\n
        Scenario 1: “When a sales order is saved, push a message to an integration queue.”<\/strong> <\/p>\n\n\n\n
        Right tool: Data event handler on <\/strong>SalesTable<\/strong> with <\/strong>DataEventType::Inserted<\/strong>.<\/strong> <\/p>\n\n\n\n
        You’re reacting to an event, not overriding logic. You don’t need to change the insert behaviour, read protected fields, or influence a return value. A DataEventHandler is clearer and more maintainable than CoC on insert() or update() \u2014 and as of Platform Update 22, even the insert() CoC option is newer than the DataEventHandler pattern, which has been stable for years. \u26a0 Be mindful that OnInserted fires after the insert commits; if you need pre-commit logic, use OnInserting. <\/p>\n\n\n\n
        Scenario 2: “Validate a custom field on vendor master; reject the save if invalid.”<\/strong> <\/p>\n\n\n\n
        Right tool: Chain of Command on <\/strong>VendTable.validateWrite()<\/strong>.<\/strong> <\/p>\n\n\n\n
        You need to change the return value conditionally and you need access to the full record state including protected members. A Post handler on validateWrite would technically work via _args.setReturnValue(false), but CoC reads dramatically cleaner and is signature-stable. <\/p>\n\n\n\n
        Scenario 3: “Show a warning to the user when a purchase order with a specific item is opened.”<\/strong> <\/p>\n\n\n\n
        Right tool: Form data source event handler on <\/strong>OnInitialized<\/strong> (or a form control event handler depending on exact trigger).<\/strong> <\/p>\n\n\n\n
        This is a framework event. There is no corresponding X++ method to wrap. CoC doesn’t apply. If you find yourself trying to CoC a form method here, step back \u2014 the form-nested CoC support in F&O covers data source and control methods but not every framework event. <\/p>\n\n\n\n
        Scenario 4: “Add custom posting logic during sales invoice posting.”<\/strong> <\/p>\n\n\n\n
        Right tool: check for a Microsoft-published delegate first. If found, use <\/strong>[SubscribesTo]<\/strong>. If none exists, CoC on the specific posting method.<\/strong> <\/p>\n\n\n\n
        Posting flows are one area where Microsoft has published many delegates specifically to avoid people monkey-patching core posting logic. Spend ten minutes looking for one before you CoC a posting method \u2014 the delegate path is dramatically safer for upgrades. <\/p>\n\n\n\n
        The decision flowchart, in prose<\/strong> <\/p>\n\n\n\n
        A quick mental sequence for picking between CoC, Pre\/Post handlers, and data\/framework event handlers. Ask these questions in order and stop at the first “yes”. <\/p>\n\n\n\n
          \n
        1. Is there a Microsoft-published delegate for this scenario? \u2192 Use [SubscribesTo].\u00a0<\/li>\n<\/ol>\n\n\n\n
            \n
          1. Is the thing I want to react to a framework\/data event (OnInserting,\u00a0OnClicked, etc.), not a\u00a0method\u00a0body? \u2192 Use the\u00a0appropriate event\u00a0handler ([DataEventHandler], [FormControlEventHandler], etc.).\u00a0<\/li>\n<\/ol>\n\n\n\n
              \n
            1. Do I need to override the logic of a specific public or protected method? \u2192 Default to CoC.\u00a0<\/li>\n<\/ol>\n\n\n\n
                \n
              1. Is that method marked [Hookable(false)] or [Wrappable(false)] without a\u00a0Wrappable(true) escape? \u2192 Fall back to a Pre or Post handler if the method is still\u00a0subscribable, or redesign.\u00a0<\/li>\n<\/ol>\n\n\n\n
                  \n
                1. Do I need access to protected fields or methods of the base class? \u2192 CoC is the only\u00a0option\u00a0that gives you this cleanly.\u00a0<\/li>\n<\/ol>\n\n\n\n
                    \n
                  1. Am I doing simple before-or-after logic that\u00a0doesn’t\u00a0need protected access, parameter modification, or transaction-scope-matching? \u2192 Either works; prefer Pre\/Post only if you have a reason not to prefer CoC.\u00a0<\/li>\n<\/ol>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    3 tricky interview questions (with verified answers)<\/strong> <\/p>\n\n\n\n
                    As with yesterday’s post, each answer is grounded in named, verifiable sources (linked in the References section). <\/p>\n\n\n\n
                    Q1. A Pre handler and a CoC extension both wrap the same method. Which one runs first?<\/strong> <\/p>\n\n\n\n
                    Trick answer. Microsoft’s documentation is explicit that neither subscribers nor CoC extensions have a guaranteed sequence. The CoC docs say the system “randomly picks”<\/em> among wrapped methods, and the events reference page states: “Since the binding between the publisher and subscribers is done through attributes, there’s no way of specifying the sequence in which subscribers are called.”<\/em> Sertan Yaman’s empirical test, running mixed CoC + event handlers in a real environment, confirms the ordering is non-deterministic across both mechanisms and can vary between environments. Design for order-independence \u2014 assuming “pre handler runs first” is a bug waiting to happen. <\/p>\n\n\n\n
                    Q2. How do you pass state between a Pre handler and a Post handler on the same method?<\/strong> <\/p>\n\n\n\n
                    Both handlers are static methods on a handler class. Na\u00efve option: a static field on that class \u2014 works for single-threaded cases but is fragile under concurrent calls. The cleaner, documented community technique (Ievgen’s AX blog, hosted on community.dynamics.com) uses XppPrePostArgs itself as the carrier: _args.addArg(‘myFlag’, value) in the Pre handler, _args.getArg(‘myFlag’) in the Post handler. The args collection is per-invocation, so state travels with the call rather than sitting in a shared field. \u26a0 This relies on undocumented-but-stable behaviour of XppPrePostArgs; if this is critical path code, wrap it in a comment explaining what you’re doing and why. <\/p>\n\n\n\n
                    Q3. Can you subscribe a Pre\/Post event handler to a protected or private method on a standard class?<\/strong> <\/p>\n\n\n\n
                    Directly, no. By default, only public methods are subscribable. Sertan Yaman documents a legacy workaround: overlayer the standard object and add a [Hookable(true)] attribute on the protected method. This is a relic of the overlayering era and is not recommended for modern F&O \u2014 overlayering on Microsoft packages is unsupported for most of the application, and even where technically possible it compromises upgrade safety. The correct modern answers are: (a) if you have access to protected members via CoC, use CoC \u2014 it sees protected members natively, which is one of its core advantages over Pre\/Post; or (b) redesign to depend on a public method or a published delegate instead. If an interview candidate answers “just overlayer and add Hookable(true),” that’s a signal they learned F&O in the AX 2012 era and haven’t updated their mental model. <\/p>\n\n\n\n
                    What to actually do<\/strong> <\/p>\n\n\n\n
                      \n
                    1. Don’t\u00a0treat “CoC vs event handlers” as one question.\u00a0It’s\u00a0three: (a) method override \u2014 CoC vs Pre\/Post, (b) framework event \u2014 use the\u00a0appropriate data\/form\u00a0event handler, (c) published extension point \u2014 use\u00a0SubscribesTo. The wrong grouping is most of the confusion.\u00a0<\/li>\n<\/ol>\n\n\n\n
                        \n
                      1. Default order of preference for reaction:\u00a0SubscribesTo\u00a0(if a delegate exists) \u2192 data\/framework event handler (if the trigger is an event) \u2192 CoC (if\u00a0you’re\u00a0overriding method logic) \u2192 Pre\/Post (only when CoC is blocked or unavailable).\u00a0<\/li>\n<\/ol>\n\n\n\n
                          \n
                        1. Never rely on call order \u2014 between handlers, between CoC extensions, or between the two. Microsoft’s docs say\u00a0it’s\u00a0random; community tests confirm it; your bug reports will too if you ignore this.\u00a0<\/li>\n<\/ol>\n\n\n\n
                            \n
                          1. Take Microsoft’s own warning seriously: Pre\/Post handlers are more fragile than CoC. Prefer CoC for method overrides when both are\u00a0feasible.\u00a0<\/li>\n<\/ol>\n\n\n\n
                            References<\/strong> <\/p>\n\n\n\n
                              \n
                            • Microsoft Learn<\/strong>\u00a0\u2014 Events and delegates (learn.microsoft.com\/en-us\/dynamics365\/fin-ops-core\/dev-itpro\/dev-ref\/xpp-events). Authoritative. Covers delegate syntax,\u00a0SubscribesTo\u00a0attribute, Pre\/Post handler pattern, and the explicit fragility warning. Last updated February 2025.\u00a0<\/li>\n<\/ul>\n\n\n\n
                                \n
                              • Microsoft Learn<\/strong>\u00a0\u2014 Class extension: Method wrapping and Chain of Command (learn.microsoft.com\/en-us\/dynamics365\/fin-ops-core\/dev-itpro\/extensibility\/method-wrapping-coc). Covers CoC syntax and the\u00a0Wrappable\/Hookable\u00a0attribute semantics.\u00a0<\/li>\n<\/ul>\n\n\n\n
                                  \n
                                • Sertan Yaman<\/strong>\u00a0\u2014 D365 FO Extensibility Part 3: Event handlers and delegates (devblog.sertanyaman.com\/2017\/05\/01\/ax7-extensibility-part-3-event-handlers-and-delegates-hooks\/). The\u00a0PreHandlerFor\u00a0\/\u00a0PostHandlerFor\u00a0example code on\u00a0InventTable, and the overlayer + [Hookable(true)] workaround for protected methods referenced in Q3.\u00a0<\/li>\n<\/ul>\n\n\n\n
                                    \n
                                  • Docentric<\/strong>\u00a0\u2014 Delegates and Event Handlers in D365FO (ax.docentric.com\/delegates-and-event-handlers-in-d365fo\/). Best community-level explanation of delegates, return-carrying\u00a0EventHandlerResult\u00a0pattern, and when to prefer\u00a0SubscribesTo\u00a0over other extension mechanisms. Updated\u00a0February\u00a02026.\u00a0<\/li>\n<\/ul>\n\n\n\n
                                      \n
                                    • Ievgen’s\u00a0AX blog<\/strong>\u00a0\u2014 Trick to pass a value between Pre and Post event\u00a0handler\u00a0using\u00a0XppPrePostArgs\u00a0(community.dynamics.com). Source for the Q2 answer on carrying state between handlers via the\u00a0args\u00a0object.\u00a0<\/li>\n<\/ul>\n\n\n\n
                                        \n
                                      • Mastering D365FO<\/strong>\u00a0\u2014 Event Handlers in D365FO with Practical Examples (masteringd365fo.blogspot.com, April 2025). Practical Table, Form, and\u00a0DataSource\u00a0event handler patterns with current code samples.\u00a0<\/li>\n<\/ul>\n\n\n\n
                                        Next up in this series: The 5 X++ Extension Pitfalls I See on Almost Every Project. Shorter post, opinion voice, list format.<\/em> <\/p>\n","protected":false},"excerpt":{"rendered":"
                                        Reading time: ~9 minutes.\u00a0 Yesterday’s post argued that Chain of Command is usually the right tool for overriding F&O method logic. That was deliberately one-sided \u2014 you can’t teach a decision framework…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-1409","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/posts\/1409","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/comments?post=1409"}],"version-history":[{"count":6,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/posts\/1409\/revisions"}],"predecessor-version":[{"id":1418,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/posts\/1409\/revisions\/1418"}],"wp:attachment":[{"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/media?parent=1409"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/categories?post=1409"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/tags?post=1409"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}