My Dynamics 365 Business Central priorities for Microsoft in 2022

June 20 2022

I was quite shocked this week when someone asked why I hadn’t done a 2022 version of my 2021 and 2020 priorities for Microsoft. Then when two separate people from Microsoft mentioned it, I thought I’d better get it done.

I’m righting this in my hotel room at the close of Days of Knowledge Nordics. Six hundred plus people over two days seemed to agree that Microsoft Dynamics 365 Business Central is in a pretty good place right now. Lots of the blockers that were preventing adoption of SaaS are gone. Projects are going in smoothly, the upgrade train from the legacy versions is more bullet speed that diesel shunter, all in all our world is as good as I can remember.

When I endeavour to share my unvarnished opinions in an article, I’m never certain whether or not people think ‘Hh, that James going off on one again’. The thought occurs that this year I should be writing a list for the partner community, not Microsoft. Bluntly, more of today’s issues focus on the channel and progress often seems slow. I guess the overriding issue is the lack of skills among partner teams, combined with a failure to invest sufficient time in not just learning but then adapting the modern toolset that Microsoft have built. I find it ironic that, having complained for years that we were the poor relations compared to our C#, JavaScript, and even PHP cousins, when that toolset does catch up, for instance with beautiful capability for CI/CD,  then lots won’t use it (yes JRM, I’m thinking of you!) despite Microsoft simplifying it to the level of GitHub and go.

Don’t be fooled into thinking that I don’t have work items in my backlog for Microsoft though. Just because we have bigger issues on our side of the fence right now, doesn’t mean they can’t crack on.

So let’s list that out…

    1. Base application improvements. Yep, I know that you’ve done lots of the BCIdea asks, but as I’ve articulated before, the ones that get the maximum votes don’t really stretch the boundaries very far do they?

      But please also be careful about going the other direction and, say, refactoring the whole of sales and purchase documents. That approach would break so much, not just for ISV but for customers as well. In fact, I’d say the objective should be not to deprecate but to give priority to what I might describe as gap filler on top of what exists now.

      That means looking at the functionality that the custom per-tenant extensions are consistently ‘filling’. You’ll find a bunch of apps in AppSource as well because all the mature partners have reacted to feedback and created their own ‘gap filler apps’ long ago. It all adds to the cost of deployment. And more importantly, the new partners don’t know how to react to the complaints, instead concluding that the base application is not good enough.

      Want an example? SharePoint integration (sorry Erik); drag and drop object storage through into SharePoint, to be exact. You gave it away back in the 2013 days, although it was from a third party. It’s a basic expectation for every client, so we all use either our own or a third party every time.

      Comments is another, valued by clients but I’m mystified as to what your strategy is these days. What I do know is a basic text line of limited characters with no word wrap is not good enough. Even Waldo (obviously I’m trying to upset all my friends) came up with his WaldoPad three years ago, Euro AJ tells me.

      How about some improvements to sales and purchase documents, like for example the ability to convert some lines of a quote to an order rather than all of them. I’m sure your telemetry will confirm that sales documents, in particular, are one of THE MOST USED parts of the system. Yet when was the last time it got some love?

    2. Then again, part of me wants new additional functionality. Please, something shiny and new rather than another refactor or link between two existing bits. But don’t be too ambitious here, you don’t need to come up with a whole new ledger or process manufacturing, for example.

      Following the theme of improvement of order processing, how about adding a ‘subscription’ type document that allows us to create repeat orders in the same way as a recuring journal creates a journal. One of your developers offered to test that extensible Enum that you use for document type, but I chickened out. Why don’t you give it go and prove the point?

      I know that there are a couple of ISVs that have subscription solutions, but if they are any good and true specialists, their product will be way more advanced than what you put in. In fact, there is an argument that, you providing a base validates their product and will expand the market for them.

    3. Suspend application deprecations for the next three releases. We are all working flat out on migrating legacy NAV systems onto SaaS, and the more you deprecate the harder that gets because it becomes refactoring on refactoring. Give us some space to get the backlog of C/AL to AL squashed before you steepen the mountain even more.

      A logical point to start deprecations again (and I know they are needed and will come) is when BC14 goes out of support. Then you officially only have to think about BCCurrent, as we call it. Until then, let’s take as many with us as we can by keeping the functionality delta between BC14 and BCCurrent as small as we can.

      And can I sneak a 3.1 in here? Can you open up feature management to ISVs, please? We have the same challenges, and it makes no sense that we create our own equivalent.

    4. User-defined query tool. Yep, another that’s been a previous ask but doesn’t seem to have appeared. This would enable so many improvements for so many areas that I believe it would become one of the most widely used tools in the system. Power BI, custom role centre tiles, custom APIs without code, that’s just for starters.

About James Crowter

I'm passionate about how businesses can improve their efficiency by getting process optimal more of the time. For the last twenty five years I've worked to help organisations of all sizes and types implement the ERP & CRM software that typically they decide they need when things are going wrong. I've seen that work unbelievably well and enabled those organisations to rapidly grow but I've also had some hard projects over that time where it's felt more like warfare at times.

Since 1996 (and version 1.01) I've been working with a small Danish product called Navision that's now become Microsoft's Dynamics NAV and I've also been using and consulting around Microsoft CRM since 2005. As managing Director of one of the longest established first Navision and now Microsoft Dynamics partners I've been involved in the complete history including numerous product councils and system design reviews. It's my privilege to know many of the key Microsoft executives and product designers and have insight into both where the products are now and their future direction.

More about James Crowter

Comments

hlamb's picture

Very good list, James! 100% agree!


james.crowter's picture

Thanks Hauke, lets's wait till Hamburg and see what we get?


Georgemocanu's picture

Please add
Make queries left,right join work as t-sql


james.crowter's picture

Yes, the tool will need to support all types of join but where the join is on an unindexed field on a large table causing a complete table scan for every parent record then I'd want the query score to be too big and the system to prevent it being run. My point is that convenience can't cause too much collateral damage and not all users understand the implications of what they are asking for, they need to be protected.