Feature recommendation notifications under the hood

For several years, Microsoft does have a dashboard with new and enhanced features that can be enabled by administrators to first evaluate the added value or impact on the current implementation. This will give organizations some time to choose when to enable new features. Features can also be turned on by default as a decision by Microsoft or made mandatory at a specific point in time. As mentioned in my previous blog about feature management, some features are like a black box, even with documentation provided by Microsoft. This blog provides guidance if you want to learn more about how to reverse engineer features and in particular Feature recommendation notifications.

Feature recommendation notifications

For a new feature called Feature recommendation notifications, Hylke Britstra asked several questions on LinkedIn and reached out to other Microsoft MVPs. As I did reverse engineering some features in the past, I offered Hylke some help and took a look under the hood at what this feature is about. Hylke and I decided to jointly write about this feature. I’m happy to announce we created a dual blog:

Functional: Hylke has written about how this new feature works functionally, and the outcome of this part can be found on LinkedIn: How does the feature ‘Feature recommendation notifications’ work in D365FO?

Technical: This blog is written by me, and I will guide you on how I approached reverse engineering and find out how it works and what features are supported for the feature recommendation notifications.

Reverse engineering

Reverse engineering would require development skills. You need to be able to navigate through the Dynamics 365 F&O application objects in Visual Studio and read x++ code. As mentioned in my previous blog about adding your own features to feature management, the classes involved do have a particular header with attributes and a specific suffix. Looping all these classes would be cumbersome. I usually start by searching the related label in the application. To do this, in Visual Studio, open the Find labels… option via the Dynamics 365 extension menu. Then type the literal feature label as listed on feature management.

Once the label is found, in many cases, the option to find references does not give a hit. In that case, you can use the Metadata search to find where the label is used in the application. In the search bar, type a filter on the object type class and the label ID (without the at-symbol) to be searched in code. Example of this feature:

type:”class” code:” FeatureManagement:FeatureManagementFeatureRecommendationNotificationLabel”

Almost guaranteed, it will give you a hit on the feature class that is managing the feature.

The name of the class is the instance name for the feature. In other parts of the application, this class is referenced to check if the feature is enabled. Then it would make a call with this class name. You can use the metadata search to find where in coding this class name is used.

In this example, it gives 15 hits where the last two are most interesting to continue diving into the details. One method is used to add a feature recommendation notification to the user and the second is to create a request notification to the administrator.

This aligns with the brief documentation provided by Microsoft: Feature management overview – Finance & Operations | Dynamics 365 | Microsoft Learn

But when will a user get what recommendation and how will administrators be notified?

Add recommendation notification

Let’s start finding out where the feature recommendation notifications are used and learn when and what features are currently supported.In case the cross-references are not updated, it would be recommended to use the metadata search to check where the static method FeatureManagementNotifications::addFeatureRecommendationNotification is used.

The search results in 3 features in version 10.0.36 and one additional one is added in version 10.0.37. The first preview of the 10.0.37 version was released end of last week. The search results show duplicate entries for the forms. When opening the code for one of the listed forms, we can see how the notification is called from the forms. This will also be a hint to the exact feature being recommended to the user.

In the init() method of the forms, it first checks if a particular feature is enabled. If it is not enabled, it will call the logic to insert the notification to the user. Interesting to read is that a GUID is defined. This makes the recommendation unique and ensures a recommendation notification will be sent only once to each user.

PS. In case this human resources feature is enabled, it will open a new version of this form instead of the current one.

To know the feature details being recommended, you can go to the feature class named in the init() method. The feature class has a method called label() where you can find the functional name.

With the information found now, you can go to the Feature management workspace and search for details about this feature. If you aren’t sure what the feature is about, you can again start reverse engineering this feature. The functional details of these 4 features are listed in the blog from Hylke. The link to his post is shared above.

Notification to the administrator

So far, we know that a notification will be sent to the user, but where would the user see this notification? To answer that question, I searched where the static method FeatureManagementNotifications::createFeatureRequestNotificationToAdmin() is used and I looked at the code in the method FeatureManagementNotifications::addFeatureRecommendation() and followed the objects being called in that method.

When a recommendation notification is sent to the user, this contains a link to the form FeatureManagementRequestFeatureEnablement. This is also the form found when checking the details of the code used in the method that creates the notification to the administrator. Ensure you will read Hylke’s blog to learn the complete flow from getting a recommendation feature, asking for a request to enable it, and how an administrator can respond to that request.

These details completed the initial elaboration, but as usual, I was curious about what exactly defines the administrator in this feature. In case an organization wants to limit the number of system administrators, how can you bring the notification for requests to a key user?

When checking the details of the coding for creating the request notification, there is one line with the next statement:


When you go to the method called for the roles, I found that not only users being part of the system administrator role will get the notification, but also users having the role Feature manager or Feature viewer. Unfortunately, all methods for adding the roles and the notification this is having internal methods or attributes that do not allow for an extension of the number of roles.

There is more…

Despite having the GUID to control if a user already got the recommendation notification, the user can request multiple times for the feature to be enabled as the side panel form with feature information does not close automatically and the request button is then still activated. The administrator will then receive all individual requests. This would be something that can be improved by Microsoft.

Hylke writes in his post that he noticed the notification is still alerted when you read the notification even when you restarted the application. When he mentioned that behavior, I verified the coding. Both the recommendation and the requests will expire after 7 days.

As I wrote in my previous post, that you can add your own features to feature management, this is also valid for recommendation notifications. By doing so, ensure you will have a unique GUID to be used in your code. You can for example use the next website to get a GUID: Free Online GUID Generator

Having the feature recommendation notifications as an option in Dynamics 365 would be good to alert users of important new features. I don’t think all features should be recommended to users as they will be then overwhelmed with notifications. This notification and request framework is not capable of managing a workflow across different environments. Requesting a feature in a production environment does not mean that you should directly enable it in the production environment. In my opinion, this should be evaluated and tested in a non-production environment first.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.

That’s all for now. Till next time!

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.