Personalized Community is here!
Quickly customize your community to find the content you seek.
Latest TechTalk Videos
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2023 Release Wave 1Check out the latest updates and new features of Dynamics 365 released from April 2023 through September 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | All TechTalks | Architecture Insights
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 it is required for the to be able to , to support this we enable "
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.
Business Applications communities