What about the error 'The corresponding AOS validation failed'

When working in Dynamics Ax, you may come across following error:

   The corresponding AOS validation failed.

The error message is usually accompanied by a reference to some table.  You may get the error message on different occasions in Ax (when opening a form or performing an action), working with for example AIF or batch jobs. 

You may think this is security related.  You are correct.  But that doesn't mean you forgot to give some user group the right permissions for some tables.
Making the user member of a group which has full access to the table referenced doesn't make the error go away.
Maybe when you make the user who gets the error message member of the Admin group, the error stays away.  But of course, making every user member of the Admin group is a bad idea and not the way to solve your problem.  So what now?

First, let's trace the error back to its root.

The error message originates from a table method.  Each table in Dynamics Ax has 4 methods for AOS validation available:

• aosValidateDelete
• aosValidateInsert
• aosValidateRead
• aosValidateUpdate

They are inherited from xRecord and you'll see that most of the time, these methods are not overridden.

For example, table CustTable has no specific AOS validation in place when reading, updating, deleting or inserting records (Customers).  But tables like AifDocumentLog, AifGatewayQueue, BatchHistory do.
Standard Ax 2009 comes with more then 60 of these kind of validations on tables.

Now what are these methods about?

Method	Description
aosValidateDelete	Validates on the server that the specified record may be deleted from a table.
aosValidateInsert	Validates on the server that the specified record may be inserted into a table.
aosValidateRead	Validates on the server that the specified record may be read.
aosValidateUpdate	Validates on the server that the specified record may be updated.

So these methods give the developer extra tools to limit access to a table.  For example decide who can read from a table, who is allowed to update records etc.  So we have separate security settings in place, besides user group permissions and RLS record level security.

Actually, most of the time it is used to administer some kind of record level security.  A user has access to a table action only when being member of a group, or when the user created the record, or the user submitted something or ...

So what is the solution for your error?  A quick summary:

• Open the AOT and find the table that is referenced in your error message.
• Go to the right validation method (are you reading records, updating them, ...)  If you got the error message when opening a form, it is probably the aosValidateRead method which you are after.
• Check out the actual code to see which users are granted permissions.  Check out the conditions and act accordingly, if possible.
  Maybe setup a separate group ('AIF' or 'Batch'), make the user a member and give access through code (if (AifUtil::isGroupMember(curuserid(), 'AIF')) return true;) 

Tip

You might wanna read more about a similar error message on this blog.  It talks about AOS authorization.