{"id":1450,"date":"2026-04-30T06:14:35","date_gmt":"2026-04-30T06:14:35","guid":{"rendered":"https:\/\/cloudclif.com\/blogs\/?p=1450"},"modified":"2026-05-01T15:54:18","modified_gmt":"2026-05-01T15:54:18","slug":"delegates-in-x-the-underused-pattern-for-clean-extensibility","status":"publish","type":"post","link":"https:\/\/cloudclif.com\/blogs\/2026\/04\/30\/delegates-in-x-the-underused-pattern-for-clean-extensibility\/","title":{"rendered":"Delegates in X++: The Underused Pattern for Clean Extensibility\u00a0"},"content":{"rendered":"\n

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

Delegates are the cleanest extension mechanism in X++. They are also the least taught. Most F&O developers reach for CoC or event handlers first, write working code, and never seriously consider whether a delegate would have been the better answer \u2014 or whether the situation called for publishing one of their own. This post is about both halves: subscribing to delegates that already exist, and writing delegates in your own code so other extensions can plug in cleanly. <\/p>\n\n\n\n

If you\u00a0haven’t\u00a0read the foundation posts: CoC mechanics Chain of Command in D365 F&O<\/a>, events vs CoC\u00a0Event Handlers vs Chain of Command<\/a>.\u00a0<\/p>\n\n\n\n

What a delegate actually is<\/strong> <\/p>\n\n\n\n

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

A delegate in X++ is a method declaration whose body is empty by design. The publisher of the delegate isn’t writing logic \u2014 they’re declaring an extension point. When code execution reaches the call site, the delegate fires, every subscriber’s handler runs, and execution continues. <\/p>\n\n\n\n

Microsoft Learn’s Events and delegates reference shows the canonical shape: <\/p>\n\n\n\n

\/\/ In the publisher class \u2014 declares the extension point \ndelegate void RentalTransactionAboutTobeFinalizedEvent( \n    FMRental fmRentalRecord, struct RentalConfirmation) \n{ \n} \n\/\/ In a subscriber class \u2014 handles the event when it fires \n[SubscribesTo( \n    classstr(FMRentalCheckoutProcessor), \n    delegatestr(FMRentalCheckoutProcessor, RentalTransactionAboutTobeFinalizedEvent))] \n\npublic static void RentalFinalizedEventHandler( \n    FMRental rentalRecord, Struct rentalConfirmation) \n{ \n    \/\/ your custom logic runs when the publisher fires the delegate \n} <\/code><\/pre>\n\n\n\n
Two non-obvious things on that snippet. First, the delegate’s body is empty \u2014 that’s not a stub, it’s the entire definition. Second, delegates always have void return type. Microsoft is explicit on this in the migration-delegates reference: “delegates do not have a return value, an EventHandlerResult is passed as a parameter to provide access to the needed result value after the delegate has returned.”<\/em> That void-only rule shapes everything about how delegates carry information back to their caller \u2014 covered in the next section. <\/p>\n\n\n\n
EventHandlerResult \u2014 how a delegate returns a value without returning a value<\/strong> <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Because delegates can’t return values directly, the publisher passes a result-carrier object as a parameter. Subscribers populate it; the publisher reads it after the delegate fires. The pattern is documented across Microsoft Learn’s Respond by using EventHandlerResult and EventHandlerResult classes references.<\/p>\n\n\n\n
The carrier comes in three\u00a0flavours, all from the platform:\u00a0<\/p>\n\n\n\n
    \n
  • EventHandlerResult\u00a0\u2014\u00a0generic;\u00a0subscriber calls\u00a0_result.result(value)\u00a0to set whatever value type matches the agreed contract.\u00a0<\/li>\n\n\n\n
  • EventHandlerAcceptResult\u00a0\u2014 restricted to accept-only\u00a0signalling; subscriber calls\u00a0_result.accept(). You cannot\u00a0reject through\u00a0this type.\u00a0<\/li>\n\n\n\n
  • EventHandlerRejectResult\u00a0\u2014 the inverse, restricted to\u00a0_result.reject(). You cannot\u00a0accept.\u00a0<\/li>\n<\/ul>\n\n\n\n
    Why three? Because delegates can have multiple subscribers, and one subscriber can overwrite another’s result. Microsoft Learn’s EventHandlerResult page describes the problem directly: “If the response is gathered by using an EventHandlerResult object, the second subscriber that validates and replies with Boolean true might overwrite the Boolean false from the first subscriber.”<\/em> The accept-only and reject-only types narrow what each subscriber can express, which makes the multi-subscriber case behave more predictably. <\/p>\n\n\n\n
    There’s also a stricter mechanism: EventHandlerResult::newSingleResponse(). When the publisher instantiates the result this way, the framework throws an exception as soon as a second subscriber tries to provide a result. This is the right choice when the publisher genuinely needs at most one subscriber to answer \u2014 overlapping ISVs becomes a fail-fast scenario instead of a silent overwrite. <\/p>\n\n\n\n
    Three legitimate uses of delegates<\/strong> <\/p>\n\n\n\n
    Delegates are general-purpose, but in practice they get used for three distinct things. Recognizing which one you’re doing matters because the contract you publish should match the intent. <\/p>\n\n\n\n
    1. Notify-only \u2014 “this just happened”. <\/strong>The publisher fires the delegate to tell anyone listening that something occurred. No response expected. No EventHandlerResult parameter. Subscribers can do whatever they want \u2014 log it, push it elsewhere, ignore it. This is the cleanest contract: the publisher is genuinely indifferent to subscriber behaviour. <\/p>\n\n\n\n
    2. Request-and-respond \u2014 “someone please answer this”. <\/strong>The publisher needs information that subscribers might supply. The delegate signature includes an EventHandlerResult-family parameter. The publisher reads the result after the delegate fires. This is the pattern in Microsoft Learn’s InventWarehouseEntity validateWarehouseTypeDelegate example. Use this when the answer might depend on logic the publisher can’t reasonably know. <\/p>\n\n\n\n
    3. Request-and-reject \u2014 “please veto this if you have a reason”. <\/strong>Specialized version of #2 using EventHandlerRejectResult. The publisher proceeds unless a subscriber rejects. Useful for plug-in validation: any subscriber can block, none has to say yes. <\/p>\n\n\n\n
    The pattern Microsoft tells you not to write<\/strong> <\/p>\n\n\n\n
    Microsoft Learn’s EventHandlerResult page has an unusually direct warning, with a code example labelled “This example is an example of code that you should not write.” Worth reading in full because it’s the single most-broken delegate pattern on real projects. <\/p>\n\n\n\n
    Microsoft’s exact words: <\/strong>“Before the subscribing logic responds, it should not evaluate whether the result object parameter already contains a result.”<\/em> <\/p>\n\n\n\n
    Rephrased: don’t write a subscriber that does “if some other subscriber already answered, I’ll skip”. Don’t write one that does “if no one else answered, I’ll provide a default”. Either of those couples your subscriber to the assumed behaviour of other subscribers, which you don’t control and shouldn’t reason about. <\/p>\n\n\n\n
    The correct shape: each subscriber answers if and only if its own conditions are met. Each subscriber’s logic stays self-contained. The framework \u2014 or the newSingleResponse constructor \u2014 handles what happens when multiple subscribers try to answer. Don’t write defensive code against the multi-subscriber case in your own subscriber. That’s the framework’s responsibility. <\/p>\n\n\n\n
    When to publish your own delegate<\/strong> <\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Most discussion of delegates focuses on subscribing \u2014 finding a Microsoft delegate that fires near the point you need to extend, and hooking into it. But the more interesting question is when to publish one in your own code. <\/p>\n\n\n\n
    Publish a delegate when: <\/p>\n\n\n\n
      \n
    • You’re\u00a0writing code that other extensions will want to plug into. ISV solutions, partner-published frameworks, internal libraries used across multiple projects \u2014 all need explicit extension points.\u00a0<\/li>\n\n\n\n
    • The right extension point is in the middle of a method, not before or after it. CoC and Pre\/Post handlers can only\u00a0wrap\u00a0whole methods; if subscribers need to intervene at a specific point inside the method, a delegate fired from that point is the only clean answer.\u00a0<\/li>\n\n\n\n
    • You want the contract to be discoverable. A published delegate shows up in tooling and code searches as an explicit extension point, more visible than an internal method waiting for someone to\u00a0CoC\u00a0it.\u00a0<\/li>\n\n\n\n
    • You want\u00a0forward-compatibility. Microsoft can change a\u00a0method’s\u00a0internal logic across versions; a delegate fired from inside that method is a stable contract\u00a0you’ve\u00a0made with subscribers, decoupled from the implementation around it.\u00a0<\/li>\n\n\n\n
    • Don’t\u00a0publish a delegate when:\u00a0<\/li>\n\n\n\n
    • There’s\u00a0already a Microsoft delegate firing close to the same point. Two delegates\u00a0means\u00a0subscribers\u00a0have to\u00a0know which to subscribe to.\u00a0<\/li>\n\n\n\n
    • The right answer is a\u00a0method\u00a0override. If subscribers genuinely need to replace your method’s\u00a0behaviour, CoC on a public method is the cleaner path.\u00a0<\/li>\n\n\n\n
    • You’re\u00a0tempted to fire one as a notification just so subscribers can read\u00a0state. Refactor that\u00a0state\u00a0into a public read-only property instead.\u00a0<\/li>\n<\/ul>\n\n\n\n
      3 tricky interview questions (with verified answers)<\/strong> <\/p>\n\n\n\n
      Q1. A delegate has the signature delegate void myDelegate(int x, EventHandlerResult result). Two subscribers respond. What value does the publisher see?<\/strong> <\/p>\n\n\n\n
      Whatever the second subscriber set \u2014 last write wins. Microsoft Learn’s EventHandlerResult page is explicit: “the EventHandlerResult class can only contain a single result. If multiple subscribers provide their individual results, the last respondent wins and overwrites the results from the previous subscribers.”<\/em> Worse, you can’t predict which subscriber runs second \u2014 there’s no guaranteed sequence. “There is not a defined order in the processing of handler methods”<\/em>, per Microsoft’s delegates-migration reference. The fix is either to design the contract so only one subscriber can plausibly respond (use EventHandlerAcceptResult or EventHandlerRejectResult to constrain the response), or use EventHandlerResult::newSingleResponse() to get a fail-fast exception when more than one subscriber answers. <\/p>\n\n\n\n
      Q2. Can a delegate have a non-void return type?<\/strong> <\/p>\n\n\n\n
      No. “Delegates in X++ must have the return type void”<\/em> \u2014 Docentric’s delegates and event handlers writeup states this directly, and Microsoft Learn’s solve-dependencies-with-delegates reference confirms “due to the fact that delegates do not have a return value, an EventHandlerResult is passed as a parameter to provide access to the needed result value.”<\/em> A candidate who tries to declare delegate boolean myDelegate(…) is showing they haven’t actually written a delegate before. The right pattern is the EventHandlerResult parameter. <\/p>\n\n\n\n
      Q3. Should a delegate handler check whether result.result() is already populated before responding?<\/strong> <\/p>\n\n\n\n
      No, and Microsoft Learn explicitly labels this as bad practice. The exact words: “Before the subscribing logic responds, it should not evaluate whether the result object parameter already contains a result.”<\/em> Each subscriber should answer based on its own conditions, independently of whether other subscribers have answered. Coupling your subscriber to other subscribers’ behaviour is a fragile dependency you don’t control. The framework manages multi-subscriber contention via EventHandlerAcceptResult, EventHandlerRejectResult, or newSingleResponse. A senior candidate adds: if a delegate handler in production code is doing this check, it’s a signal the contract is ill-defined and should be redesigned, not patched. <\/p>\n\n\n\n
      What to actually do<\/strong> <\/p>\n\n\n\n
        \n
      1. Before\u00a0reaching for\u00a0CoC on an internal Microsoft method, search the area for an existing delegate. Microsoft has published many in posting, validation, and pricing flows specifically to provide cleaner extension points. Right-click a class name in Visual Studio and use “Find references” to surface delegates and\u00a0SubscribesTo\u00a0handlers in that area.\u00a0<\/li>\n<\/ol>\n\n\n\n
          \n
        1. When you do subscribe to a delegate, write each handler self-contained.\u00a0Don’t\u00a0check whether other subscribers\u00a0already\u00a0answered.\u00a0Don’t\u00a0provide a default for the multi-subscriber case. Each handler responds based on its own conditions only.\u00a0<\/li>\n<\/ol>\n\n\n\n
            \n
          1. When the contract\u00a0genuinely needs\u00a0at most one subscriber, use\u00a0EventHandlerResult::newSingleResponse() in the publisher. Fail-fast on\u00a0contention beats silent overwrites.\u00a0<\/li>\n<\/ol>\n\n\n\n
              \n
            1. When publishing your own delegates in framework or ISV code, prefer\u00a0EventHandlerAcceptResult\u00a0or\u00a0EventHandlerRejectResult\u00a0over generic\u00a0EventHandlerResult\u00a0when the response is binary. The narrower type prevents whole classes of multi-subscriber confusion.\u00a0<\/li>\n<\/ol>\n\n\n\n
                \n
              1. Treat published delegates as part of your public API. Renaming, signature changes, or removal will\u00a0break\u00a0every subscriber. The same compatibility discipline\u00a0you’d\u00a0apply to a public class method applies.\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 reference for delegate syntax, the\u00a0SubscribesTo\u00a0attribute, and the\u00a0FMRentalCheckoutProcessor\u00a0example used above. Last updated February 2025.\u00a0<\/li>\n<\/ul>\n\n\n\n
                    \n
                  • Microsoft Learn<\/strong>\u00a0\u2014 Respond by using\u00a0EventHandlerResult\u00a0(learn.microsoft.com\/en-us\/dynamics365\/fin-ops-core\/dev-itpro\/extensibility\/respond-event-handler-result). Source for the explicit “do not write this” warning and the\u00a0InventWarehouseEntity\u00a0validateWarehouseTypeDelegate\u00a0example. Last updated May 2025.\u00a0<\/li>\n<\/ul>\n\n\n\n
                      \n
                    • Microsoft Learn<\/strong>\u00a0\u2014\u00a0EventHandlerResult\u00a0classes in request or response scenarios (learn.microsoft.com\/en-us\/dynamics365\/fin-ops-core\/dev-itpro\/dev-tools\/event-handler-result-class). Source for\u00a0EventHandlerAcceptResult,\u00a0EventHandlerRejectResult, and\u00a0newSingleResponse. Documents the last-write-wins\u00a0behaviour.\u00a0<\/li>\n<\/ul>\n\n\n\n
                        \n
                      • Microsoft Learn<\/strong>\u00a0\u2014 Solve dependencies among models by using delegates during code migration (learn.microsoft.com\/en-us\/dynamics365\/fin-ops-core\/dev-itpro\/migration-upgrade\/delegates-migration). Source for the void-return-type rule and the no-defined-order statement on subscriber processing.\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 when to use delegates vs other extension\u00a0mechanisms;\u00a0covers\u00a0EventHandlerResult\u00a0patterns with current syntax. Updated\u00a0February\u00a02026.\u00a0<\/li>\n<\/ul>\n\n\n\n
                          Next up in this series: Best Practice Checks \u2014 Fighting the Warnings You’ll Actually See in Every Build. [PASTE DAY 7 URL HERE]<\/em> <\/p>\n\n\n\n
                          <\/p>\n","protected":false},"excerpt":{"rendered":"
                          Reading time: ~8 minutes.  Delegates are the cleanest extension mechanism in X++. They are also the least taught. Most F&O developers reach for CoC or event handlers first, write working…<\/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":[35],"tags":[],"class_list":["post-1450","post","type-post","status-publish","format-standard","hentry","category-d365-fo"],"_links":{"self":[{"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/posts\/1450","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=1450"}],"version-history":[{"count":9,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/posts\/1450\/revisions"}],"predecessor-version":[{"id":1467,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/posts\/1450\/revisions\/1467"}],"wp:attachment":[{"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/media?parent=1450"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/categories?post=1450"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudclif.com\/blogs\/wp-json\/wp\/v2\/tags?post=1450"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}