My team is on the receiving end of extensibility requests. We are getting many quality requests, that we approve immediately – and deliver rapidly, typically in the next monthly update. However; we are also getting many requests that are not actionable. These we reject – asking for more details. We also observe some organizations bulk logging non-actionable requests. In these situations, we will also bulk reject them. The Japanese have a word for this: Muda.
This post describes good practices when logging extensibility requests, to ensure they are approved first time.
If all you have is an overlayered 7.x version – then you are not ready to log requests, yet. There is not a 1:1 between overlayered code and extension requests. Typically, overlayerings can be refactored to extensions without any additional support. Our data shows that 80-90% of overlayering are already supported, and thus don't require any extension request to be logged.
Read more: Migrate from overlayering to extensions.
We are providing extensibility requests by the hundreds every month. If you are looking at an old code base like 7.3 – you are looking the wrong place. Do upgrade to the latest monthly update on latest version.
Read more: What's new
The platform provides an immensely rich feature set for building extensions. Dive in, leverage them.
Read more: Creating extensions and X++ the most extensible language on the planet
As part of migrating your solution to extensions; you should locally implement the extension points you need. You should iterate, test, refine, experiment in the process. The result should be crisp extension points that you can request.
Read more: Write extensible code and Relax model restrictions to refactor overlayering into extensions.
Replaceable is tolerable in small doses; but otherwise poisonous. Not much different from sugar and caffeine. Replaceable has the same semantics as overlayering, just without the tooling. We try to avoid it whenever possible. If you request a large method to be replaceable, the request will be rejected. Instead propose a method extraction refactoring that crisply solves your requirements.
Read more: Hookable, Wrappable and Replaceable and Intrusive customizations.
For backwards compatibility reasons we cannot do this. Yes, that is also true for optional parameters. In many cases, you can solve the requirements without the parameters using these techniques. If not, please log the request with proper explanation why – and we'll consider obsoleting the existing method and introduce a new method.
Read more: Method signatures and Breaking changes.
We are looking for what the end-user will experience with the request. A good template to follow is this: "In the <vertical industry> it is required for the <persona> to be able to <detailed description of task>, to support this we enable <detailed description of how the persona will do this, i.e. where to click, what to enter, etc.>"
We will not workflow enable forms one by one in the standard based on extension requests, instead the platform now supports workflow enablement as extensions.