Overview of Security Policies for Table Records

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Security policies enable developers and administrators to block access to subsets of data rows in tables. A policy is roughly similar to a where clause in an SQL select statement. A security permission increases the access a user has to data, but a security policy decreases access to data.

In the Application Object Tree (AOT), policies are displayed under Security > Policies.

Security policies are enforced in the Application Object Server (AOS). All access mechanisms that route through the AOS are subject to policy enforcement. These access mechanisms include forms, Enterprise Portal webpages, SSRS reports, and calls from class methods.

An Extensible Data Security Model

Microsoft Dynamics AX uses an extensible data security (XDS) model. XDS extends data security from a single table to the tables and views that contain related data.

Security policies are part of an overall extensible data security model. The conceptual model in the following illustration shows the influence of context on security policies.


The conceptual model of extensible data security

The following table defines the concepts of the XDS model.



Constrained tables and views

A security policy could constrain the data access of the SalesTable to only those records that have one particular CustAccount foreign key value. You can define constrained tables and views in the AOT at Security > Policies > YourPolicy > Constrained Tables.

Primary table

You can use a primary table to secure the content of the related constrained table. For example, in a policy that secures all sales orders based on the CustGroup foreign key value, the Customer table would be the primary table.

Policy query

You can define a policy query by specifying a value for the Query property in the AOT at Security > Policies > YourPolicy. You can use a policy query to secure the constrained tables specified in a given security policy. The query selects data from a primary table. The values in that data are then used to restrict the data returned from the constrained table.


A policy context controls the circumstances under which a given policy applies. The policy is not enforced unless the context is set.

The types of policy contexts are as follows:

  • Role context – can enable policies that are based on the roles to which the user is assigned.

  • Application context – can enable policies that are based on information which is set by the application.

For more information about policy contexts, see Security Policies Properties.

See also

Security Policies Properties

Walkthrough: Creating a Simple Default Security Policy

Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.