Thursday, May 18, 2017

How to programmatically add menu items to favorites menu via X++ in Dynamics AX

The favorites menu is a bit unusual in AX in the way you need to add to it. Most of the way it works appears to be Kernel level, but through some TreeNode usage you can add items to it.

This will add the "SalesTable" menu item to your favorites.

static void JobAddToFavorites(Args _args)
    TreeNode                treeNode;
    TreeNode                menuToAdd = TreeNode::findNode(@"\Menu Items\Display\SalesTable");
    TreeNodeIterator        iterator;
    UserMenuList            userMenu;
    Menu                    menuNode;

    treeNode = infolog.userNode();
    iterator = treeNode.AOTiterator();
    treeNode =;
    if (treeNode)
        userMenu = treeNode;

        // find 'My Favorites' user menu; 
        treeNode = userMenu.AOTfindChild("@SYS95713");

        // Note menuNode is a different object than userMenu
        menuNode = treeNode;


Another table to take note of is SysPersonalization if you're looking at doing this for multiple users. I haven't dug into this deeply, but this code snippet should get you started with what you may want to do.

Friday, May 5, 2017

How to remove the default filter controls on a ListPane in AX 2012

When you create a ListPage, the kernel automatically adds a FormFilterPaneControl with some filtering options. Many think this can't be removed or hidden, but it can!

It is added during the run method's super() call by the kernel, so using this code on the ListPage you can remove it.  The caveat is if you are using the ListPage FormTemplate, it's not possible because you're not able to override the run method.

The last closing comment I'll add is I don't know if the kernel expects the control to be there later on and if this can cause any issues or not. I just was curious if I could get it to go away.

public void run()
    int                 i;
    FormControl         formControl;

    for (i=1; i<; i++)
        formControl =;

        if (formControl is FormFilterPaneControl)

Monday, April 17, 2017

Address Validation in Dynamics AX - QuAAX

I wanted to talk about a new product for address validation and discovery in AX called QuAAX (Quality Addressing for AX), powered by Experian Data Quality. It's more than a simple "is this address valid or not" type of program and allows for address discovery, quick entry, and some fuzzy operations.  It also works internationally with 200+ countries supported.

Disclaimer: I worked on this product.

Addresses in AX can be a headache.  Between data migrations from years of different systems, order imports from external sources, and user entry error you can end up with a mess of postal address records that you have varying degrees of confidence in. This is where QuAAX can help solve many of those issues.

The code is almost entirely X++ and lives in AX, which makes desired customization easy and provides transparency. It's designed to be an easy install via model file with a few overlayered objects to merge.

It is powered by Experian Data Quality web services, so for the configuration you simply put in your Auth Token and set a few minor settings. This means you don't need to update any on-premise software. It also back-fills related tables, so no need to create new zip-codes and it can automatically complete zip+4 codes.

There is a new indicator on the address records throughout the system that visually indicates the status of the address and shortcut buttons to verify addresses.

It will automatically create suggestions for validated addresses that are more well formatted.

When you have an address that is close to correct, it will automatically jump into the edit view with the parts it was able to verify and ask for user input. An example is this address (401 B St, San Diego, CA 92101) where I forgot to enter the suite #. It prompts me to enter it and provides acceptable ranges of input.

There is a fancy engine used for keying in new addresses that lets you very quickly enter data and also suggests inputs as you type.

It also has a bulk processing engine and simple API, so you can perform cleanup on your legacy data or perform validation calls on new addresses input from external sources.

Some final comments. Right now it's supported for AX 2012 and it's coming soon to Dynamics 365 for Operations.  There are plenty more features I wasn't able to cover in this post such as lat/long, address type indicator (residential vs commercial), and more.

More information can be found here:

As always, happy DAX'ing!

Tuesday, March 14, 2017

New features (CDS Integrations) and some clarity on Common Data Services (CDS) and how it will work in the Dynamics 365 Sphere of products

For the last year how the Common Data Services (CDS) will actually work and play in the Dynamics 365 sphere of products has been a fairly gray area. It has been often promised that "it just works", without providing any details to what is going on behind the scenes. Hopefully I'll be able to provide some grain of clarity on that.

The following is still under development by Microsoft and hasn't been officially announced, but it's what I've gathered from speaking with the various product members.

How does the Common Data Model get filled by the CDS? - Microsoft is building 1st class integrations

Is it flow? - No

New configuration section - "Integrations":

So this doesn't yet exist yet, but there is supposed to come a new section in the PowerApps Admin Center where you can configure your environment integrations with the Common Data Service. It's also important to note that it lives in the PowerApps Admin Center for now only because they haven't come up with a better place, even though it doesn't seem to make total sense to me.

So things like:

  1. Dynamics 365 for Sales (CRM) to
  2. Common Data Services to
  3. Dynamics 365 for Operations (AX)

This order is important because "you have to crawl before you can walk" and Microsoft's first goal is to go from Sales => CDS => Operations. Eventually, they'll go both ways.

Flow Templates:

If you're like me and tried to figure it out on your own, you may have stumbled upon some pre-configured Flow Templates that might fit the need:

How are flow templates different than integrations?

Integrations to the Common Data Service will be more robust and "first class" integrations by Microsoft for bulk data moving and syncing, while Flow Templates are for purpose built, row-by-row needs.

What technologies do integrations use under the hood?
The integrations use a combination of Data Import Export Framework (DIXF), OData, and M-Engine which sits under Power Query.  These allow the integration to push bulk amounts of data between the systems on an unspecified syncing schedule.

This is an exciting time as these technologies are bleeding edge and new things are expected to release very soon! As always, happy DAX'ing! Or D365'ing?

Wednesday, February 15, 2017

Unlimited private agents for Visual Studio Team Services!

In January Microsoft announced via e-mail good changes to Build & Release Private Agents. They introduced the concept of "Private Pipelines" in Visual Studio Team Services.

What are Agents?
An agent is basically a task-runner that you can pass build activities to, such as PowerShell scripts, executables, etc. The agent can either be Hosted (in the cloud on Azure) or on-premise (installed on your private servers).

When you run a build/release process from VSTS, it sends your tasks to an Agent to do your work.

What's new?
The concept of a "pipeline" is introduced, which is essentially the number of concurrent agents running tasks at the same time.  Previously, you were allowed one on-premise agent (for free) and if you wanted more agents on different servers you had to buy additional ones ($15/ea).

Now, you can have unlimited on-premise agents! You are given one private and hosted pipeline free with your VSTS account. So this means you can still only run operations on one agent at a time unless you buy additional pipelines.

Why is this a good thing?
If you have Dev/Test/Prod systems, you may want to place an agent on each machine where each has certain privileges and setup your build processes to communicate with each agent. And you may have no need for many concurrent build/release operations, but you want to have your agents (task runners) on different machines. This is VERY convenient.  Previously, the work around was to just figure out ways to have your agent run on a single machine and execute operations remotely to the other machines, which you can imagine is a hassle.

Here is the full contents of the email:
Starting later this month and running through the end of February, we will be gradually deploying a change to how we count Build & Release Private Pipelines (previously called Private Agents) in Visual Studio Team Services.  It does not change your bill.

Up to this point, you have needed a Private Pipeline for each separate private build agent or private release agent that you configure in your Team Services account.
Going forward, you can configure as many private agents as needed in your Team Services account without incurring extra charges.  You'll only need as many Private Pipelines as the number of concurrent builds you want to run or releases you want to deploy using your own machines. With this new way of counting Private Pipelines you may be able to purchase fewer Private Pipelines than you do today. 
Learn more about the impact of this change on your builds and releases.
If you have any questions, please contact us through the Visual Studio Developer Community ( or via customer support (