Approver Groups

Overview

An approver group can either be an ordered set of one or more approvers (persons and/or user accounts) or it can be a list, which is dynamically generated at rule evaluation time. A typical pre- or post-approval rule adds an approver group's members (in order) to a transaction's approver list. Typically approver groups represent functional approvers outside a transaction's chain of authority, such as human-resource management and internal legal counsel, that must approve a transaction before or after management has done so. However, it is possible to insert an approver group into a chain of authority if required.

When you create an approver group, AME creates for you the corresponding actions of the pre- and post-approval action types automatically. These actions are available to all transaction types.

You can nest approver groups or in other words it is possible to make one approver group a member of another approver group. The following graphic illustrates the example discussed below:

the picture is described in the document text

For example, a purchasing department might define the following groups to handle post-approvals of computer-hardware purchases:

COMP_APP_1 = {Jim Small} COMP_APP_2 = {COM_APP_1, Jane Smith} COMP_APP_3 = {COMP_APP_2, Liz Large}

AME would evaluate the membership of COMP_APP_3 to be (Jim Small, Jane Smith, Liz Large}, in that order.

You can add all the members of an existing group to the new group to create a nested approver group. To create a nested approver group, select the approver type as Nested Group and select the required group in the Create New Approver Group page. The select list that appears on the Create New Approver Group page only includes a group under three conditions:

It is not the target group itself.
It does not contain the target group (either explicitly or implicitly).
It is not contained in the target group already.

The first two of these requirements prevent an infinite loop in the resolution of nested groups. The third prevents redundant group members only in the narrow sense that if group A already contains group B as a member, you cannot add group B to A again. However, if group A contains B, and group C also contains group B, you can add C to A. In this case, the ordering of A's members would place B's members before C's members other than those in B, in A's membership list. Thus:

B = {1, 2} C = {3, 4, B} A = {B, C} = {{1, 2}, {3, 4, B}} = {{1, 2}, {3, 4, {1, 2}}} = {1, 2, 3, 4}

Nested approver groups let you build an approvals matrix using AME approver groups. For example, the purchasing department defining the computer-hardware approver groups above might define three corresponding post-approval rules:

If ITEM_CATEGORY in {COMPUTER_HARDWARE} and ITEM_AMOUNT <= 1,000 USD then require post-approval from the COMP_APP_1 group.

If ITEM_CATEGORY in {COMPUTER_HARDWARE} and 1,000 USD < ITEM_AMOUNT <= 10,000 USD then require post-approval from the COMP _APP_2 group.

If ITEM_CATEGORY in {COMPUTER_HARDWARE} and 10,000 USD < ITEM_AMOUNT then require post-approval from the COMP_APP_3 group.

These rules effectively define a hierarchy of per-item dollar-amount signing authorities for three subject-matter approvers. You can predefine a hierarchy of nested approver groups containing no members other than nested groups, along with a set of approval rules like those above; and your customers can easily populate the groups with person or user approvers upon installation.

It is possible to nest a dynamic group in a static group, but it is not possible to nest either a dynamic or static group in a dynamic group. Dynamic groups can only include persons and users.

AME maintains a non-recursive approver list for each approver group, so that the engine does not need to evaluate group nestings at run time. Rather, the engine fetches all static members and all dynamic members' queries in a single query, and then executes the dynamic members' queries in turn, substituting the results into the membership list. This means you can nest groups to arbitrary depth without impacting AME performance adversely, but you should take care to limit the number of dynamic groups nested in a single group.

Empty Approver groups

The action types that use approver groups share the required boolean attribute ALLOW_EMPTY_APPROVAL_GROUPS. When this attribute has the value 'true', AME allows an approver group not to have any members at run time. When the attribute has the value 'false', AME raises an exception if an approver group does not have any members.

Deciding When to Use an Approver Group

There are action types that let you use approver groups for pre-approvals, chain of authority approvals, and post-approvals. The following factors enable you to decide when to use an approver group:

Using Approver groups for Pre- and Post-Approvals

Typically approver groups represent functional or subject-matter-expert approvers outside a transaction's managerial chain of authority, such as human-resource management and internal legal counsel that must approve a transaction before or after management has done so.
Using Approver groups for Chain of Authority Approvals

Sometimes you need AME to generate chains of authority containing several approver types, or containing an approver type that lacks a hierarchical structure. In these cases you can use nested approver groups to construct an approver hierarchy, and then use the hierarchy with the approver-group chain of authority action type.

Approver Group Properties

Approver groups have several properties:

Name

An approver group's name can be up to 50 bytes long. Typically an approver group's name should avoid referring to a specific transaction type or approver sub-list (pre-approval, chain of authority, post-approval). This is because an approver group can be used in any transaction type and any sub-list, even if it was originally created for a specific transaction type or sub-list. Likewise, an approver group's name should avoid indicating whether the group's membership is (currently) dynamic or static, because this property might change. Instead, an approver group's name should reflect the group's position or function in the organization. For example, 'Office-Furniture Purchasing' is better than 'Office Furniture Requisitions Dynamic Pre-Approvers'.

Description

An approver group's description can be up to 100 bytes long. The same caveats that apply to approver groups' names apply to their descriptions.

Order Number

Every approver group has an order number. Approver-group order numbers determine how the approver groups in the same sub-list are ordered. Do not confuse an approver group's order number with the order numbers of the group's members. (See “Membership” below.)

Voting Regime

An approver group has a voting regime assigned to it. A voting regime determines the order in which a group's members are notified, and how the group makes approval decisions. The following four regimes are available:

Serial Voting

In serial voting, the members are notified one after the other, in an order consistent with the members' order numbers. AME breaks ties arbitrarily. All members must approve for the group to approve.
Consensus Voting

In consensus voting, the members are notified in parallel. All members must approve for the group to approve. Members' order numbers are ignored in this instance.
First-Responder-Wins Voting

In first-responder-wins voting, the members are notified in parallel. The response of the first member to respond to the notification requesting approval becomes the group's approval decision. AME logs the responses of the remaining group members, but otherwise ignores their responses. Members' order numbers are ignored in this instance.
Order-Number Voting

In order-number voting, the members are notified in the order of their order numbers. Members having the same order numbers are notified in parallel. All members must approve for the group to approve.

Active List

An approver group can have two membership lists. Only one of the lists is active (in force) at any given time. You only need to define one list or the other, but you may define both. The two membership lists are:

Static Membership List

You choose an approver group's static members using AME's approver-query wizard, while creating or editing the group.
Dynamic Membership List

AME generates an approver group's dynamic members by executing an SQL query you enter while creating or editing the group. Each row fetched by the query must have one of two forms.

First, it can consist of one of the approver-type labels 'person_id' and 'user_id', followed by a colon, followed by a valid ID for an appropriate approver type. Note: The case of the labels is not important so 'Person_id' is equivalent to 'person_id.'

Second, it can consist of wf_roles role type (orig_system), followed by a colon, followed a valid wf_roles.orig_system_id.

The order of the rows returned by the query determines the dynamic members' order numbers, at run time. The query can reference the transaction-ID placeholder : transactionId.

Creating an Approver Group

You create, edit and delete approver groups using the Approver Groups tab.

To create an approver group

Use the Create New Approver Group page.

Click the Approver Groups tab to display the Approver Groups page. If you are navigating from the Business Dashboard, then select the required transaction type in the Approval Process Setup available in the Business Dashboard and click the Approver Groups link.
Click Create to open the Create New Approver Group page.
Enter the group's name and description.

Note: Avoid referring to a specific transaction type or approver sub-list such as pre-approval, chain of authority, post approval as you can use the approver group in any transaction type or approver sub-list.
Enter the order number to determine how the approver groups in the same sub-list are ordered.
Select the voting method to determine the order in which AME notifies the group's members and how the group makes approval decisions.
Select the group's use type to determine the group's membership list. If you select the dynamic use type, then enter an SQL query and click Validate to ensure the query is well formed. If you select the static use type, then you must enter members for the static approver group in the Group Members region. You can add all the members of an existing group to the new group to create a nested approver group. To create a nested approver group, select the approver type as Nested Group and select the required group.

Note: Oracle strongly recommends that SQL queries used to retrieve information must use only base tables and not secure views. The SQL query must also not include any context-sensitive logic.

The SQL query for a dynamic approver group can generate different approvers for each subordinate item in a transaction. To enable this feature, you must ensure the dynamic query for the dynamic approver group includes item class and item ID variables in addition to the transaction ID. For example, your query can be:
```
select
                'PER:'||person_id from invoice_table
                where transaction_id = :transactionId
                and item_class = :itemClass
                and item_id = :itemId
```
Click Create Another to create another approver group.
Click Apply to add the approver group to your transaction type and to make it available for other transaction types.

Note: The new approver group will appear on the list in the order of its approver-group order number. Note that when you create an approver group, AME creates for you the corresponding approver-group actions automatically.

Editing an Approver Group

There are several kinds of changes you can make to an approver group. You can change the description of an approver group and delete group members. You cannot update the approver group name.

To update an approver group

Use the Update Approver Group page.

Click the Approver Group tab.
Select the Update icon for approver group you want to edit.
Change the properties of interest.

To add members to an approver group's static membership, click Add Another Row in the Group Members region.

To delete one or more members of an approver group's static membership, click the Delete icon next to the approver(s) and confirm the deletion.
Click Apply to submit your changes.

Deleting an Approver Group

You can delete an approver group only if it is not used in any current or future rule and it is not a predefined group.

To delete one or more approver groups

Use the Approver Groups page.

Click the Approver Groups tab.
Select the Delete icon for the approver group you want to delete.

Warning: If an inactive rule is using the deleted approver group, then you cannot reinstate that rule.
Confirm the deletion when prompted.