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.

1. Don't log requests until you are ready

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.

2. Don't requests things that are already supported

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

3. Understand the platform's extensibility features

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

4. Understand what extension points are

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.

5. Don't request Replaceable methods

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.

6. Think twice before requesting additional parameters to existing methods

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.

7. Describe the business scenario

We are looking for what the end-user will experience with the request. A good template to follow is this: "In the it is required for the to be able to , to support this we enable "

8. Don't request specific forms to be workflow enabled

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.