Whereas security keys control access to functionality within the application, this security access is limited to menu items. To help protect the system at a more granular level, it is important to set up security for table and field access.

All tables and fields are available in the security system, and access can be set up individually for each user group working within a company or domain without affecting other user groups. Table and field access is configured when you set security keys ( > > > on the tab).

The following graphic shows how to access and configure table and field access from the window.

Table and Field Access

Table access

User group access to a table is defined by several factors:

  • The table rights defined for the user group within the domain or company.

  • The table's security key and the user group's security key rights within the domain or company with regard to the table.

  • The setting of the MaxAccessModetable property.

Note Note

The MaxAccessModeproperty affects only access through the user interface. Code can still access the table, even if the MaxAccessModeis set to No access.

These factors are used for the calculation of a user group's permissions to each table in the application.

The following chart shows how table rights are calculated during startup. Tables have two properties: Configuration keyand Security key.

Table access flow

Field access

Like user group table access, user group access to a field is defined by several factors:

  • The field rights defined for the user group within the domain.

  • The field's security key and the user group's security key rights within the domain for the field.

  • The setting of the Visiblefield property.

  • The setting of the AllowEditfield property.

These factors are used for the calculation of a user group's permissions to each field in the application. The calculation is performed during startup.

The following chart shows how field rights are calculated during startup.

Field access flow

After the user group's access to a field has been calculated, this access is compared to the one defined for the table. A user group's access to a field can never exceed the group's access to the table that the field belongs to. The final field access becomes the lesser of the field and table rights.

Best practices

  • Work with managers who oversee the different groups in your organization to determine permission levels. For example, work with a manager in the Finance department to determine permission levels for the Finance groups. The manager knows which groups should have permissions to items like General ledgerand Bank, including permissions on child nodes.

  • If you are uncertain about whether to allow permission to a certain item, leave the permissions level set to . It is better to deny permission to an item and force an individual to request permission for their group than to grant permission to an area that a group should be unable to access.

  • Restrict the number of users who are members of the Administratorsuser group, which has access to all fields, tables, reports, and modules in Microsoft Dynamics AX by default. If users are made members of the Administratorsuser group, they can potentially view reports or data that they should not be able to see, or change configurations and business logic in the system. Ideally, only those individuals who configure and administer Microsoft Dynamics AX should be members of the Administratorsuser group.

Important Important

If you change permissions for a user group, especially if you demote permissions, restart the Microsoft Dynamics AX server and instruct all group members to restart their Microsoft Dynamics AX clients after you make the change. If group members do not restart their clients, they might keep their former permissions. As a best practice, ask members of a group to log off Microsoft Dynamics AX before changing permissions and inform all Microsoft Dynamics AX users of the impending client restart. If it is necessary, select users in the form ( > ) and then click before changing user group permissions. For more information, see Remove users.

After table and field restrictions are applied, consider adding special restrictions to certain records within the database. To learn more about record level security, see Manage record level security.

See Also