Extensible Data Security examples

This post will guide you how to restrict access to relevant records only in the form Legal Entities by using the Extensible Data Security (XDS). It will explain the steps to create the security and how to deal with some unwanted side effects.

When setting up the security in Microsoft Dynamics AX2012 you can assign one or more roles to a user. Per role you can restrict company access by assigning organizations. You can grant single companies or also a part of an organization hierarchy with the children.

In this sample I assigned the Accountant role to Annie and assigned some companies based on a single entry and a part of a hierarchy. You can see the result of the granted Legal entities in the fact box. Now when Annie starts Microsoft Dynamics AX, she will only have Accountant permissions in the selected legal entities. Within this role she is allowed to maintain records in the Legal Entities form. But within this form you will see all Legal Entities and she can even change data on the Legal Entities she does not have permission to.

I was asked several times if it is possible to restrict this list of Legal Entities based on the security setup for the users. This is possible with help of the Extensible Data Security (XDS). XDS was introduced in AX2012 as a replacement for Record Level Security (RLS) from earlier Dynamics AX versions. Although RLS is still available in AX2012 it will be depreciated in a next release.

XDS is more powerful in constraining data and operations. A very nice thing is constraining related tables. So in fact you can restrict Customer groups and then have it inherited to related Customers, Quotations, Sales orders and Invoices.

Well let’s start to restrict legal entities..

XDS requires to create a Query and a Security Policy. The query contains the data source with filters to manage data that will be allowed for the user. The Security Policy will take care of applying the constraints with the use of the query.

A link to more detailed information on this framework is provided at the end of this post.

The base table used on the Legal Entity form is CompanyInfo.

To create a query, go to the Application Object Tree (AOT). Search the node Queries. Right click this node and click New query.

In the properties of the new query, specify the properties Name (e.g. CompanyInfoRestrictView) and Title.

Expand the tree of the new query. Right click the node Data Sources and choose the option New Data Source.

The value of the property Table will be CompanyInfo. This will be the primary table to restrict records.

Expand the node Fields and set the value of the property Dynamic to Yes.

Now expand the Table (CompanyInfo) tree and point to the second node Data Sources. Right click this node and choose again for New Data Source.

Fill the Table property with the value MyLegalEntities. This is a temporary table were the data is managed in a method called XDS. When using this table it will contain data for the current session and user.

Expand the node Fields and set the value of the property Dynamic to No.

There is no relation created between the CompanyInfo and MyLegalEntities tables so we have to define the relation ourselves.

Right click the Relations node and click the option New Relation.

On the new node fill both the properties Field and RelatedField with the value DataArea.

The query will now look like this:

So it seems we are half way there, as we only need to create a Security Policy.

In the AOT, browse for the node Security. Expand this node and point to Policies.

Right click the Policies node and click New Security Policy.

Fill the properties like the sample below. Note that it is best practice to use a label ID in the Label property.

When selecting the value for the property Query, AX will check if the first table in the Data Sources of the Query matches the property PrimaryTable.

The property ConstrainedTable is used to determine if the primary table should be restricted as well or that we will add some related constrained tables.

The Operation property has options to restrict only selections, insert, update or delete actions or in this sample All operations. So the users are not allowed to see or to create, update or delete other legal entities.

With help of the properties ContextType, ContextString and RoleName we can define where this Security policy is active. When you don’t specify anything it is applicable for all users, regardless the Role. Note that the System administrator is a special role in AX2012 and bypasses all security. So an XDS policy is not applicable for system administrators.

The result and side effects

When the new objects are saved and compiled, the restriction is applied to Annie. This is fun, don’t you think?

Well Annie starts working and encounters two problems.

The first problem is when she opens the Main Account Details form. The user gets the next warning:

After some research this is caused by records in the table MainAccountLegalEntity.

The second problem is on the Financial Dimension Values form. On certain dimensions when changing the value of the field Select the level of dimensions to display to Companies the next error can pop up.

After researching this error it appears to be caused by records in the table DimensionAttrValueLedgerOverride.

The above mentioned warning and error will not pop up when the security policy is not enabled. So it is related to the new policy. To solve these problems we have to add the two tables as constrained tables as well.

Add additional Constrained Tables

In the AOT search your security policy and select the Constrained Tables node.

Right click this node and select the option Add table from relation.

Specify the value MainAccountLegalEntity in the property Table and fill the value of the property TableRelation with CompanyInfo.

The second table does not have a direct link with the CompanyInfo table so we need an additional step. In this case the table Ledger would be neccessary as this table contains the relation to the CompanyInfo and the record ID of this table is the key for the table DimensionAttrValueLedgerOverride.

On the Constrained Tables node right click and add a table from a relation. Fill the property Table with Ledger and the property TableRelation with PrimaryForLegalEntity. In this case you can also set the property Constrained to No.

Now right click the Ledger node and add a table from a relation. Now we can specify the Table DimensionAttrValueLedgerOverride with the value Ledger for the property Relation.

The Security Policy will look like the next picture. Note that the tables CompanyInfo, MainAccountLegalEntity and DimensionAttrValueLedgerOverride do have the value Yes in the Constrained property.

With adding these tables the problems encountered by Annie are solved. I hope this real life sample can help you in your implementations and you will know how to restrict legal entities.



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!