There are a few things to think about when creating alert rules:
Create alert rules
New or modified alert rules are only accepted if users have access to all tables and fields that are required to use the rules.
For example, if a user creates a rule on a table for which he currently has adequate security permissions, he can create this rule. Subsequently, his security permissions are limited and he then cannot access the table he created.
The rule remains visible in the form, but no alerts are generated or sent to the user based on this rule.
The same situation occurs if a rule is created on a table, and in the filter of the rule there is a reference to another table. If a user's permissions to the referenced table are removed or denied, the user's alert rule becomes obsolete, and no alerts are generated from this rule.
Create alert rules based on templates
When a new rule is created from a template, only templates for the parts of Microsoft Dynamics AX that individual users have permission to use are available to those users.
Create alert rules that involve setup of an inquiry
When a rule is created with a filter in an inquiry form, the owner of the rule has the same rights and the same limitations as he normally would when using the inquiry feature where all tables in the list have either a 1:n or an n:1 relationship with the initially-selected table.
Create alert rules on foreign keys
A rule set up on a foreign key does not generate alerts if the foreign key is renamed as part of a rename-primary-key operation. A foreign key is a field that is referenced in one form, and that field represents a primary key in another form. The rename-primary-key operation implies that the field is renamed in the form in which it originates.
For example, you have a service agreement which is attached to the service agreement group called "Denmark." You set up an alert rule on the service agreement in the form to be alerted if the service agreement group called "Denmark" changes. When the service agreement group is later changed to another existing group, for example "Sweden," you get an alert. However, you do not receive an alert if the service agreement group "Denmark" is changed by a rename-primary-key operation. With the rename-primary-key operation, the name of the service agreement group is changed in the form where it is set up; that is, the form. In this example, the service agreement group name might have been changed from "Denmark" to "DK," but this change does not trigger an alert.
Alert rules must be set up on each company within a virtual company. You cannot set up one alert rule to apply to more than one company within a virtual company.
If a user is deleted, all alert rules owned by this user are deleted, too.
To preserve an alert rule created by a user to be deleted, you need to change the user identification of the alert rule before you delete the user. Alternately, to preserve all rules of a user to be deleted, you could consider disabling the user instead. In that case the alert rules of the user are preserved.