About reinstating global address book security in Dynamics 365 Finance and Operations

reinstate global address book security

Quite some questions I see on the Dynamics community forums and from people who reach out to me is about secure global address book in Microsoft Dynamics 365 Finance and Operations. Unfortunately, this is a feature which has not yet been moved by Microsoft from Dynamics AX 2012 to Dynamics 365. In this post, I will answer some of the questions you might have and provide a workaround to enable the feature today.

Global address book security

This first question you might have is: “What is the global address book feature?”

reinstate global address book security

This feature was introduced in Microsoft Dynamics AX to provide record based security within the application related to parties as customers, vendors, employees and contacts. There were various options to tag the parties with address books and setup which teams were allowed to view which address book tag. So, if you were a member of one or more teams, you would see e.g. the customers related to that address book; others are not visible then. Also, there is an option to secure by legal entity, which means that in the global address book form and the names lookup on e.g. customers you will only see records which do have a role in all the legal entities you have access to. More information about this feature can be found in the Microsoft documentation: About security in the global address book.

Microsoft Dynamics 365

In 2016, Microsoft released the cloud based version of Microsoft Dynamics 365 without this feature. From the beginning it was stated that it is a feature which got postponed. You can read it on the next page from Microsoft: AX 2012 features that were postponed – Finance & Operations. But why?

The development environment and the client experience got separated in Microsoft Dynamics 365. In the production environment, you don’t have access to the development environment. Enabling the secure options on the Global address book parameters form did change already exiting AOT objects. It did enable or disable security policies. These security policies were created based on the eXtensible Data Security (XDS) framework. Now there are two reasons why the AX 2012 approach is not possible today in Microsoft Dynamics 365.

  1. For the security policies in the development environment there is no option for extensions. You can’t add tables and you can’t change properties to enable the policy or control the enablement of constrained tables. Overlayering objects is not allowed for standard Microsoft models.
  2. Runtime extensions like the security configuration or custom fields have not been implemented.

Several times I reached out to Microsoft to ask about timelines. However the conversations are pleasant, as of today, there is no date to be announced. In version 7.3, some fixes were delivered to customers, based on overlayering. On LCS Issue search you can find Details for issue 3909290 (requires login). As of version 8.0, the overlayering was blocked and only deployment of extensions were allowed. For this reason, Microsoft is not shipping fixes anymore. To have it prioritized by Microsoft, you can vote for the Microsoft Idea · Re-instate securing the global address book by team as per 2012 (requires login).

I do notice that there is more and more demand for the security of the global address book. For this reason, I proposed an intermediate solution to Microsoft. Microsoft mentioned that this would not be something they could deliver as part of the standard. However, they support the idea when I provide a solution for the meantime.

Intermediate solution

For the time that Microsoft has no solution for moving the global address book security to Microsoft Dynamics 365, it would require a customization. I did create this customization myself and the good news is that I can share it with all of you on personal title. So, Microsoft and To-Increase are not the companies which would give support if something is unclear or not working. The download is available below.

I did some testing myself and it works the same way and on the same tables as were constrained in Dynamics AX 2012. If you want to use the security, there are some actions required.

  1. Download the zip-file from the download section below and extract the files.
  2. Install the software in your Dynamics 365 Finance and Operations environment. There are two options provided. You can install a model file with the solution or import the project package file. For more help, visit the documentation:
    Install a model in a development environment – Finance & Operations
    Import an .axpp file – Finance & Operations
  3. Enable the correct security policies. When you install the software, initially the policies are not enabled. First you have to decide if you want to use the legal entity security, address book security, or both. Where the Global address book parameters did enable the policies, this is in this solution a task in Visual Studio which requires development skills. The solution should be part of your build environment like other customizations or ISV solutions.

    The security policies related to the two options have been grouped in the project. Per group you need to enable all related policies to have the security working correctly. This is 4 policies for the Secure by address book and 2 for the Secure by legal entity.
    For each security policy, open the designer and set the value of the property Enabled to Yes.
  4. (Optional) Add tables and views or disable existing constrained tables. (see below)
  5. Build the solution and synchronize the database. Without a proper database synchronization the security policies are not enabled.
  6. Test the software carefully for functionality and possible performance impact before deploying it in a production environment.

It would be possible to change the Enabled property back to No in case you want to disable the security again.

Add tables and views or disable

The first version of this global address book security has only the constrained tables which were also set to constrained in Microsoft Dynamics AX 2012 R3. I have not reviewed which tables potentially needs to be included to support all standard functionality in Microsoft Dynamics 365 Finance and Operations. If you find a table, a developer can review which security policy to update with a new table. You can also add your custom tables as constrained table. As all objects are delivered in a model which is not restricted, you can change any detail of the solution.

Besides reviewing tables, you might also want to restrict data being read or updated via data entities. You can read my other blog about Extensible Data Security and data entities – Microsoft Dynamics 365 for Finance and Operations to learn how to add data entities as constrained table.


Finally, we landed at the section with the download option. Feel free to use it at any project where you need to use it. If you have feedback or questions, please use the Contact form or leave a comment below.

There is more…

A bit more background how I created the solution, if you are interested…

For this solution, I copied all standard security policies related to the global address book security; including the queries and mycontruct tables. I will explain why.

  • Security policies copied as it is not possible to extend security policies today in Microsoft Dynamics 365 Finance and Operations.
  • Some myconstruct tables did have a call to a table DirPolicyPartition which was used in Microsoft Dynamics AX 2012 to indicate per partition if the global address book security was active or not. In AX 2012, it still checked all security, but the myconstruct tables did then return e.g. all address books or all legal entities. For that reason it looked like it was disabled, but actually it could have a small performance penalty. In this solution, I have made the decision to fully skip this table as the partitions are deprecated in Microsoft Dynamics 365 Finance and Operations. For that reason also the temporary tables with a list of allowed values per user have been copied.
  • As some myconstruct tables were copied as new object, also the related queries needed to be replaced. As a follow up, also the new copied security policies needed to be updated with the new queries.
  • With copied objects in a new model, there is no restriction for any organization to adjust the security policies to their needs.

When you compare the current standard security policies related to the global address book security with AX 2012, you will notice that the properties Constrained table, Constrained and Use Not Exist Join do have different values. The values from AX 2012 are correct and implemented in the download above.

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!

8 replies
  1. Martin Winkler
    Martin Winkler says:

    Thanks a lot for your solution! All tests were good, we are now implementing it at a customer who knew the solution from AX2012 and who (rightly) saw it as go-live critical to have it in D365FO.
    If we need to extend / change the solution in some way which could be relevant to the community, we will inform you.

    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Thank you, Martin!
      Love to hear when it can help people around the world. If you have anything as feedback or enhancements I would like to hear it, so we can improve the GAB security even further.

  2. Mary
    Mary says:

    Hello André we have installed the package into one of our customers that requires this solution for Dyn365, unfortunatly seems that this package reduce the performance during for example the process of posting invoices, we went into debug with the developer and found that the procedure will check about all permission for all parties that the user can see,
    did you had similar issues in other customers that implement your solution? did you made maybe any upgrade on in it?
    Thank you

    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Mary,

      In the past, I had seen performance degradations, but also improvements when implementing XDS policies. This heavily depends on what tables are constrained and how many records are in various tables. The policies I shared are exact copies of the global address book policies which were available in AX2012 without adding or removing constrained tables based on my experiences. Indeed, I have removed some tables in the past to mitigate some issues. The download is provided as-is. It includes the source code, so you would be able to make adjustments based on your requirements.
      Before suggesting what to do in your scenario, it would be good to know the exact table or tables used in the process for invoicing. I don’t know if you refer to sales invoices, free text invoices, project invoices, or purchase invoices. Maybe by removing some constrained tables, the performance can be improved. As an example, I removed the project journal-related tables before.

  3. Mary
    Mary says:

    Hello André
    many thanks for your support and for the quick answer, when we have installed the package we had performance issues into project invoices, in particular when there were multiple lines to be invoiced, we can try to review that part of coding in order to optimize the timing, in particular we can try remove the related tables of project journals and see if become faster,

    If you have any more suggestion please let me know, I really appreciate your support
    Thank you

    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Mary,

      Thanks for your reply. Please update your findings. I think it would be good to gather some feedback and check where to improve these policies. In my opinion, on a line level, the policy could be too expensive considering the performance. To exclude the table from the list of constrained tables, would need a small investigation of forms and reports if they would present data from these tables without considering the headers or related master data. If this is not the case or particular users would not get access to this type of forms or reports, these tables can be excluded from the policy.


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.