Suppose you have two different roles, Manager and Employee, for which you are designing a menu system. The menus will look much the same but with a few key differences. For example, you might have a reports folder that contains different versions of the same report depending on the user. You could define the menus like this:

You can easily see how a situation like this can become difficult to maintain. Currently, the only difference between the two WebActionGroups is one report.

The UI Meta Model allows for you to define an action and then define one or more "variations" for that action which will be resolved based upon the user requesting the menu. As an example, we could define the base "PhoneBook" report and then define a variation that will only be used by the Manager role as in the following example:

This allows us to maintain a single "Reports" folder which is used in both RoleTypeUiConfig. With this configuration, we could define additional variations based on many different properties (in ascending order of specificity): RoleName, RoleTypeName, EntName, OrgName, or even as specific as ValueChainId.

What if we wanted to add another report that only managers should get? Without any kind of variation at the WebActionGroup level, you would end up with a UI Meta Model which looks like this:

Again, we are back in a situation where you would need to define a separate WebActionGroup for each role when the only difference is one additional report.

Fortunately, you can also define variation on WebActionGroups, as the next example shows:

Note that when defining WebActionGroupVariations, you can include any child elements you would normally include in a WebActionGroup, including WebActionRefs, WebActionGroups, WebActionGroupRefs, and MenuDividers.

With this new variation, we can have one WebActionGroup which contains different actions based on which user is looking at it. Additionally, you can see that both variations, the default, and the Manager version, contain a WebActionRef to an action that also has a variation. All of these variations will be resolved when the UI requests the menu; all variations will be resolved to the most specific variation. This allows for a high degree of flexibility and reuse when you define your menus.