Security – Part 2

Data security policies

Prerequisite – Please note to work through this lab you will need to have Admin rights to the system and have basic AOT navigation skills.

Microsoft have introduced an alternative to the ‘Record level security’ used in AX 2009 which caused huge performance issues. This alternative is known as ‘XDS’ (Extensible Data Security).

The concept is extremely simple and it doesn’t take long to setup a XDS query of your own. In this blog I will start by explaining the ‘concept’ behind XDS after which I will run through a simple lab.

Note – Microsoft have have made extensive notes on this feature. Please find the links at the bottom of this page.


“XDS limits a specific Role to only see a specific set of data within an AX table”  

Above I’ve attempted to summaries in one line the primary function of XDS. In essence the XDS security policy will apply a permanent filter onto a specific table within AX. To understand this better I will work through a simple business requirement.

Company A have two manufacturing sites (Site 1 and 2) they require the Production managers (Worker Z, Worker Y and Worker X) to see specific sets of data.



Site 1

Site 2










Above we are attempting to display that the share the same AX security roles (the ability to access the same forms and preform the same tasks) however they should only be able to see the data from their respective sites.

Requirement gathering for XDS

The first step in setting up an XDS policy is simply identify the table you would like to apply a filter too, the field you are filtering on and the variants of this filer. So working through this for the scenario above you would end up with:

  • Table to be filtered?                                  Production order table
  • Field you would like to filter on?               Site
  • Variants required?                                     1 and 2

Next we will need to identify the Primary table and the Constrained tables. These have been defined below:

Constrained table – The constrained table act as the table you desire the filter to appear upon (Note – There can be multiple constrained tables as long as the primary table and the filtered field can been seen in that constrained table).

Primary table – The primary table can typically be defined as the field used to filter the constrained table.

In order to identify which tables meet the above definitions navigate to the table you desire to filter upon and identify the appropriate table relationships. Below I have worked through the example of filtering the production order table down by site. This should help you to apply the same logic to your desired business scenario.

  1. Open Production control > Common > Production orders > All Production orders.
  2. Make sure you have the field site displayed to do this click View > Dimensions
  3. Select site and save the changes
  4. Firstly we will identify the Constrained table, right click on the field ‘Production order number’ and click ‘Personalize’ in the menu
  5. Within the Personalization screen identify the table used (this can be seen in the screen shot below)
  6. Next we will need to identify the primary table and field. In our case the field ‘Site’
  7. Right click the field ‘Site’ and select ‘Personalize’
  8. Within the Personalization screen identify the table and field used (this can be seen in the screen shot below)
  9. This information has been summarised below:

    Primary table

    Filtered field

    Applier filter

    Constrained table

    XDS – Production orders – Site 1





    XDS – Production orders – Site 2





  10. If you can create an advance query to represent your desired outcome you will also be able to create this using XDS. Also it will help you understand how the relationships work.

Pre-XDS setup

Prior to setting up the XDS policy you will also need to create a new Role within AX. This will generate less maintenance than applying the XDS directly to an existing security role. If you were to apply the XDS security policy directly to the production manager security role you would need to then create two production security roles and therefore maintain two production manager security roles rather than the one security role with an additional XDS role on top of that. Instead I would suggest that you create three new security roles one called ‘XDS_Site_1’, ‘XDS_Site_1_2’ and ‘XDS_Site_2’.

To do this follow these steps:

  1. Open the AOT (Ctrl+D)
  2. Navigate to Security > Roles
  3. Right click on the ‘Roles’ node and select New Role
  4. Name the roles appropriately (remember to change the name and the label)

Setting up XDS

In this next section we will run through the steps you would need to take in order to create the XDS policy.

  1. The first thing you will need to do when creating an XDS policy will be to create a project within the AOT. This will help to keep your work together and simplifies the deployment of code too.
  2. Open the AOT (Ctrl + D)
  3. Open the projects screen (Ctrl+Shift+P)
  4. Right click the ‘Shared’ folder and select New > Project
  5. Select an appropriate name for the project (XDS_PRODUCTION_ORDERS_SITE_1)
  6. Right click and Open the project

Now we have created a suitable work space to create our policy we will now need to build the query that we would like to run. This should mirror the query set-up in step 10 above.

  1. Right click you project and click New > Query
  2. I find it helpful at this point to also name the query to do right click the query and select ‘Rename’ (XDS_InventDim_SITE_1)
  3. Next we need to define the primary table
  4. Expand the query and right click the ‘Data source’ and select New Data Source
  5. This will create a new node called ‘INVALID TABLE_#’
  6. Selecting this node should bring up a properties plane on the right hand side of the development screen
  7. In the properties screen first select an appropriate name and then specify the table you would liking this node should bring up a properties plane on the right hand side of the development screen
  8. In the properties screen first select an appropriate name and then specify the table you would like to filter on.
  9. We have now selected the primary table but we still need to define the ‘Range’ (Criteria) for the filter.
  10. Expand the data source you created and right click on the ‘Ranges’ node and select New Range.
  11. Again using the Properties screen amend the following fields:







  1. Next select the field’s node and again in the properties amend the property ‘Dynamic’ to ‘Yes’.

Now we have set the query up we need to setup the XDS policy to apply the query to the constrained tables and relate to a specific AX role.

  1. Right click the main project ‘XDS_Production_Orders_Site_1’ and then click New > Security > Security Policy
  2. Select the ‘SecurityPolicy1’ node and modify the properties to be:






Restrict Production orders to site 1












All operations

Context Type


Role Name

XDS_Site_1 (setup in step 14)

  1. Next we need to define the constrained table. Expand the security policy node to reveal the ‘Constrained table’ node right click this node and select New > Add table by relation
  2. Within the properties set the following values:



Constrained Table




Table Relation


  1. We have now setup out XDS policy. Remember to COMPLIE THE WHOLE PROJECT! To do this right click the project and click ‘Compile’ this should then remove the red line next the project. (If it doesn’t try closing the window and navigating to it again)

Now we have successfully created the XDS security policy we will need to test that it works to do this you will need a test user account (Don’t apply it to your user as you will then not be able to change yourself back to admin!)

  1. Open System administration > Common > Users > Users
  2. Select the test user you would like to apply the policy too
  3. Select Assign roles and select the roles Production manager and XDS_Site_1
  4. Close your AX application and open again as a different user to do this hold down ‘Shift’ and right click the AX application and select ‘Run as different user’
  5. Navigate to the appropriate area and test that the filter has been applied.


To recap on out original requirements we had 3 users Z, Y and X with the following requirements:


Site 1

Site 2










To achieve the requirements of Z and Y you would need to create two policies as we did in the example above. However, it should be noted that you CANNOT STACK XDS policies by this I mean if you wanted user X to see sites 1 and 2 but not site 3 you should not apply both two policies created above as they will cancel each other out and you will end up with no data displaying you would need to create a new policy with a query such as =”1”,”2” in a new XDS security role.

The final outcome should be as follows:



Production manager




Worker Z



Worker Y



Worker X





Security – Part 1

I’m sure a lot of people will agree that setting up AX and its security is no easy task. Therefore I’ve put together a guide to the information that you need to consider when working with AX 2012 security.

In this first part we will discuss and explain the concept of Role-based security within AX.

1 – Role-based security

At a high level Role-based security works to limit the areas/functions within AX to which a user has the ability to access/Run.

Essentially think of AX as a long corridor with doors on either side, AX security will dictate which doors the user can open and which actions they can take on contents of the that room (AX – records in a table).

These levels can be defined as follows:



Entry points

Entry points define the individual sections of code access.


Privilege’s define the first level of grouping of entry points and should be used to define an individual tasks. Note – The privilege also dictates the level access available to that privilege.  See fig 2.


A Duty combines multiple privileges in order to provide a user with the appropriate access to perform a specific process within AX.


Roles combine multiple Duties in order to allow a user to perform the multiple process necessary to perform their specified day job.


Figure 1

AOT Name Label Description
No Access No Access Does not provide any access to data.
Read View An end-user can view data.
Update Edit An end-user can view and edit data.
Create Create An end-user can view, edit and create new data.
Correct Correction An end-user can view, edit, create new and correct date-effective record without creating new records.
Delete Full control An end-user can view, edit, create new and delete data.

Figure 2

2 – Example

The way I like to think of this is that Microsoft have put together a ‘Library’ of ‘Duties’ which can then be selected and placed into the appropriate roles. This is best explained using an example, take the example of the Buying agent whose role is defined as ‘Documents purchase events and responds to purchase inquiries’. If we find this role within AX we can see that the user is made up of the following:


Figure 3

We can see that Microsoft have used the concept of building a ‘Library of Duty’, we can see this if we investigate the duty  Inquire into import letter of credit which can also be found in the following roles:

  • Accounting manager
  • Accounts payable manager
  • Accounts payable payments clerk
  • Buying agent
  • Chief financial officer
  • Financial controller
  • Purchasing manager
  • Treasurer

Use full links: