Creating rules and rule use are the main steps in the AME implementation process. Rarely will an organization's business rules match any rules that are predefined with a transaction type. Instead, you must translate the business rules you documented into AME rules yourself.
Rule associate one or more conditions with an approval in an if-then statement. Before you can create rules, you must create conditions for the rules to use. You may need to create (or have a system administrator create) some custom attributes and/or approvals. You may also need to create some approver groups. Thus, while creating rules is your ultimate goal, it is also the last thing you do when you set up AME.
There are eight rule types in AME. Seven of them provide rules that participate in generating transactions' approver lists; these are the approver-generating rule types. The eighth generates productions.
List-creation rules
List-creation exceptions
List-modification rules
Substitutions
Pre-list approval-group rules
Post-list approval-group rules
Combination Rules
Production Rules
Different rule types use different condition and action types, and have different effects on a transaction's approver list.
List-creation rules generate chains of authority. They use action types that ascend an organizational hierarchy to generate one or more chains of authority. A required attribute typically identifies the first approver in each chain, and the specific action determines how many approvers are in each chain.
List-creation rules can use any of the following action types:
Absolute job level
Relative Job Level
Dual chains of authority
Final approver only
Manager then final approver, relative job level
Supervisory level
Approver group chain of authority
Line-Item Job-Level chains of authority
HR position
Position level
See Predefined Action Types for descriptions of each action type.
This is an example of a list-creation rule:
Rule A
If TRANSACTION_AMOUNT < 1000 USD, then require approvals up to at least job level 2.
Rule A has one condition, on the attribute TRANSACTION_AMOUNT. The approval is of the absolute-job-level type. So if the condition is true for a given transaction, AME will extend the transaction's chain of authority from the transaction requestor's supervisor up to the first approver in the supervisory hierarchy who has a job level of at least 2.
If several list-creation rules of the same action type apply to a transaction, AME enforces the most stringent approval required by those rules. For example, if two absolute-job-level rules apply to a transaction, the first requiring approvals up to at least job level 2 and the second requiring approvals up to at least job level 3, AME will extend the chain of authority up to the first approver with a job level of at least 3. So, when you want to create an exception to a list-creation rule, and the exception should require extra approval authority of the same type as the list-creation rule, the exception should itself be another list-creation rule.
List-creation exceptions also generate chains of authority. The difference between a list-creation rule and a list-creation exception is that an exception suppresses selected list-creation rules.
Sometimes you want to create an exception to a list-creation rule that decreases the level of, or changes the type of, the approval authority that the list-creation rule would otherwise require. In this case, you need a list-creation exception (or simply an exception). An exception contains at least one ordinary condition and at least one exception condition (see Conditions for an explanation of condition types), as well as an approval. An exception can use any of the approval types available for list-creation rules.
The circumstances under which an exception overrides a list-creation rule are somewhat subtle. The two rules do not have to have the same ordinary conditions. Instead, both rules' ordinary conditions have to be defined on the same attributes, and both rules' conditions must all be true (including the exception's exception conditions). In this case, AME ignores the list-creation rule, and the exception has suppressed the list-creation rule.
There are several reasons AME does not require that an exception have the same ordinary conditions as a list-creation rule that it suppresses. First, one exception may be designed to suppress several list-creation rules. In this case, the scope of the exception's ordinary conditions must be broad enough to encompass that of each list-creation rule it suppresses. Second, an exception may be designed to apply to a more narrow set of cases than a list-creation rule. Third, it is sometimes desirable to adjust the scope of either the exception or the list-creation rule(s) that it suppresses, without simultaneously adjusting the scope of the other(s).
This is an example of an exception that suppresses Rule A:
Rule B
If TRANSACTION_AMOUNT < 500 USD and Exception: COST_CENTER is in {0743}, then require approvals up to at least job level 1.
(In Rule B, the first condition is an ordinary condition, and the second condition is an exception condition.) Note that the ordinary condition is defined on the same attribute (TRANSACTION_AMOUNT) as the condition in Rule A, but the two conditions are different. Rule B carves out a exception to Rule A for transactions with totals under $500 U.S. for a certain cost center. In this narrow case, the exception requires less approval authority (of the absolute-job-level type) than what Rule A would otherwise require, which is why the rule must be an exception, rather than a list-creation rule.
Note: The list creation and list creation exception rules are together referred as chain of authority rule type.
Sometimes you want to make exceptions regarding the approval authority granted to specific approvers, rather than the approval authority required for specific kinds of transactions. To do this, you need a list-modification rule. AME applies list-modification rules to modify the default chain of authority generated by all applicable list-creation and exception rules. A list-modification rule can have (but need not have) ordinary conditions. However, it must have exactly one list-modification condition (see Conditions for an explanation of condition types).
There are two common uses for list-modification rules: reducing an approver's signing authority, and extending an approver's signing authority. In the former case, the list-creation rules might effectively grant a certain level of signing authority to managers having a given job level, and you might want not to grant that authority to a certain manager, in spite of their having the requisite job level. To do this, you tell AME to extend the chain of authority past the manager by using the nonfinal-authority approval type in conjunction with the job level action types only. In the latter case, just the opposite is true: the list-creation rules require approvals beyond a given job level, but you nevertheless want to grant a certain manager at that job level signing authority. To do this, you tell AME to truncate the chain of authority after the manager by using the final-authority approval type. In both cases, you can limit the scope of the list modification to a broad or narrow set of ordinary conditions.
Here are some examples of list-modification rules that illustrate the possibilities:
Rule C
If PURCHASE_TYPE is in {OFFICE FURNISHINGS, OFFICE SUPPLIES} and any approver is: Kathy Mawson, then grant the approver final authority. (In Rule C, the third condition is a list-modification condition.) Rule C grants Kathy Mawson final authority for a narrow scope of purchase types.
Rule D
If TRANSACTION_AMOUNT > 1000 USD and the final approver is: Kathy Mawson, then require approvals at least one level up.
(In Rule D, the second condition is a list-modification condition.) Rule D revokes Kathy Mawson's signing authority for a broad set of transaction amounts.
Sometimes you want to delegate one approver's authority to another approver. To do this, you need a substitution rule. AME applies substitution rules to the chain of authority after modifying it by applying any applicable list-modification rules. Like a list-modification rule, a substitution rule can have (but need not have) ordinary conditions. However, it must have exactly one list-modification condition. So a substitution rule differs from a list-modification rule only in its use of the substitution approval type.
This is a sample substitution rule:
Rule E
If TRANSACTION_AMOUNT < 500 USD and CATEGORY in {MISCELLANEOUS OFFICE EXENSES} and any approver is: John Doe, then substitute Jane Smith for the approver.
(In Rule E, the third condition is a list-modification condition.) Rule E delegates John Doe's authority to Jane Smith, for the class of transactions defined by the rule's ordinary conditions.
The four rule types described above generate a transaction's chain of authority. You may want to have one or more groups of functional specialists approve a transaction before or after the chain of authority does. In such cases, you need a pre- or post-list approval-group rule. An approval-group rule must have at least one ordinary condition, and must use either the pre- or post-chain of authority-approvals approvals type. For example:
Rule F
If TRANSACTION_AMOUNT < 1000 USD and CATEGORY_NAME in {Marketing Event}, then require pre-approval from Marketing Approvals Group.
Combination rules combine actions from action types having different allowed rule types. There are two kinds of combination rule. One kind allows action types for list-creation rules, list-creation exceptions, production rules, pre-chain of authority rules, and post-chain of authority rules. The other kind allows action types for list-modification and substitution rules. Use a combination rule when several of your business rules apply to exactly the same cases. Doing so collects the business cases in a single rule for convenience. It also reduces runtime performance overhead.
Production rules output productions to the integrating application. Each integrating application uses productions in its own way. Consult your integrating application's documentation for information about what AME productions (if any) the application uses.
A rule has the following properties:
Actions
Each rule must have one or more actions. Generally a rule's type determines which action types it can use. There are three exceptions:
Production rules can only use the production action type.
All of the approver-generating rule types can have production actions. The productions produced by these rules are approver-level productions.
Combination rules combine actions from different rule types.
Start and End Dates
A rule's start and end dates determine its lifespan, the period in which the rule can be used. When you select the current date as a rule's start date, AME sets the start date at the current time as well. When you select a future start or end date, AME sets that date to 12:00 a.m. (the beginning of the day).
A rule's start and end dates are not the same as the start and end dates of a rule use for the rule. The rule use's lifespan determines when the rule is in force for the rule use's transaction type, not the rule's lifespan. The rule's lifespan merely determine when the rule is available for use. Give a rule a future start date if you want it only to be available in a future period. Give a rule an end date of 31-DEC-4712 if you want it to be available indefinitely, after the rule's start date.
Note: A rule cannot be created with a past date.
Description
A rule's description can be up to 100 bytes long. The description should be general enough to make sense in all transaction types that might use the rule.
Item Class
A rule used by a transaction type contributes to the approver lists of the items in the rule's item class. Note that header-level rules may have conditions on attributes belonging to at most one subordinate item class, and subordinate-item-class rules may have header-level conditions. Thus, the rule
If TRANSACTION_TOTAL < 1000 USD and COST_CENTER in {481, 6012} then require approvals up to absolute job level 4.
could be either a header-level rule or a cost-center-level rule. In the former case, the rule would generate a chain of authority up to job-level four for the header item. In the latter case, if the header-level condition were satisfied, the rule would generate a chain of authority for the approver lists of cost centers 481 and 6012. Be careful to use rules assigned to the item classes you intend, when the rules have conditions on multiple item classes.
The purpose of rule priorities is to prioritize a transaction type's rules and, at run time, remove from the set of rules that would otherwise apply to a transaction, those rules of insufficient priority. A rule priority is a positive integer associated with a rule within a transaction type. (Each transaction type that uses a rule can assign the rule a different priority.)
Note: The priority increases as the priority value (number) decreases: two has priority over three, etc.
When rule priorities are enabled for a given rule type (within a given transaction type), the Rules tab and the rules details pages display rules' priorities; and one can edit a rule's priorities as one would edit any other rule property. When priorities are disabled, they are neither displayed nor modifiable.
The Administrator and Business Analyst dashboards have special pages for editing the rulePriorityModes configuration variable's value. The value contains a priority mode and threshold for each rule type. There are three possible priority modes: absolute, relative, and disabled. A threshold is a positive integer, and it only has meaning for the first two priority-mode values. See Configuration Variables for details of each of these modes.
Let us look at the following rule priority processing example:
Requirement
It is required that transactions be routed to specific approver groups for a limited selection of cost centers otherwise route to a default group. For example if the stated requirement is:
If transaction cost center is 1234 require post approval from approver group A
If transaction cost center is ABCD require post approval from approver group B; otherwise require post approval from approver group Z
Solution
From the Configuration Variables, Rule Priority Modes, enable absolute priority mode for the rule type Post List Approver Group and set the rule priority threshold of 1. For each rule where there is a cost center approval group, assign priority of 1 to the rule. For your exception rule, assign priority 2 to the rule.
For example:
Rule 1: Where cost center = 1234, require post approval from A, rule priority 1
Rule 2: Where cost center = ABCD, require post approval from B, rule priority 1
Rule 3: Require post approval from Z, rule priority 2
By setting the relative rule priority to 1, AME will determine how many rules of each priority value are active and discard any that fall outside of the configuration setting. Therefore, if any rule with priority 1 is active, then this rule would be used and the over-arching case Z would be discarded and the group A or B selected. If no rule for priority 1 is active, then the over-arching rule will not be discarded and so approver group Z will be notified.
The deployment of a rule depends upon its use. It is possible to have multiple use for a rule, each one spanning a specific data range which allows rules can be switched on/off as required.
A rule use can also span transaction types, effectively sharing rules between them. In both cases, any such use is marked on the UI to indicate either future dated rules or rules shared across transaction type use.
Once a rule is created, it is available for use in all transaction types. A rule use tells AME that a given transaction type should use a given rule for a given lifespan. A rule use involves the following:
Transaction Type
You always create a rule use within your current transaction type in the AME user interface. This is the transaction type to which the rule use is assigned.
Rule
There are two ways to create a rule use. First, you can create a use for a rule when you create the rule. Second, you can create a use for a rule that was created previously. In the second case, you can create a use for a rule already used by your current transaction type (for a lifespan that does not overlap with those of pre-existing uses for the same rule, in the current transaction type), or for a rule used by another transaction type.
Start and End Dates
A rule use's start and end dates make the rule active for the use's lifespan, in the use's transaction type. As for rules' start and end dates, when you select the current date as a rule use's start date, AME sets the start date at the current time as well. When you select a future start or end date, AME sets that date to 12:00 a.m. (the beginning of the day). When you create a new rule use, make sure its lifespan does not overlap the lifespan of another use for the same rule in your current transaction type.
Priority
When the current transaction type has enabled rule priorities for the type of the rule in a rule use, the use must define a priority for the rule. (See the description of the rulePiorityModes configuration variable in Configuration Variables for information about enabling rule priorities.) The priority must be a counting number (positive integer).
Each transaction type can enable or disable rule priorities for each rule type, using the rulePriorityModes configuration variable. When this variable enables priorities for a given transaction type and rule type, the configuration variable's value specifies whether AME should interpret priority values as absolute or relative. The configuration variable also specifies a threshold value. How AME interprets the threshold at run time depends on whether the priority mode is absolute or relative.
When absolute priorities are enabled, all rules use with priorities that are numerically higher (larger) than the threshold are suppressed. For example, suppose
The threshold for list-creation rules is one.
The priority mode is absolute.
Two list-creation rules' conditions are satisfied.
The satisfied rules' use has priority one and two, respectively.
In this case, only the first rule (whose use has priority one) applies. The second rule (whose use has priority two) will be suppressed.
When relative priorities are enabled, if the threshold is t, AME determines the t numerically lowest (smallest) priorities among the rules of the relevant rule type that otherwise would apply. All rules of this type having a priority that is numerically higher (larger) than the numerically lowest priorities are suppressed. For example, suppose
The threshold for list-creation rules is two.
The priority mode is relative.
Four list-creation rules' conditions are satisfied.
The satisfied rules' use has priorities three, four, three, and seven, respectively.
In this case, the first three rules (whose all use have one of the two lowest priorities) apply. The fourth rule (whose use has priority seven, which is not one of the two lowest priorities) will be suppressed.
Approver Category
When for-your-information (FYI) notifications are enabled for a given transaction type, the transaction type's rule use for all approver-generating rule types must specify an approver category (FYI or approval). The approver category is assigned to each approver generated by the rule in the use. This lets a rule generate approval approvers in one transaction type, and FYI-notification recipients in another transaction type.
Sometimes an approval consisting of several rules of different types may require that a given approver appear in different places in a transaction's approver list. AME assumes that an approver should only approve a transaction once, so it has to decide which rule(s) requirements prevail. There are two common cases of this problem. Here are brief descriptions of each case, and explanations of how AME handles them:
A list-creation, exception, list-modification, or substitution rule includes the approver in the chain of authority; and a pre- or post-approval rule requires the approver's pre- or post-approval. In this case, AME only includes the approver in the chain of authority. The reason is that omitting the approver from the chain of authority might change the identity of the approvers that follow the approver, in the chain of authority; and AME assumes that preserving the chain of authority is more important than preserving the default approver order.
Two approval-group rules include the approver in different (pre or post) approver groups. In this case, AME includes the approver in the first approver group in the approver list. AME here assumes that the approver should approve at the earliest opportunity.
Suppose you already have a rule requiring managerial approvals up to a manager with a job level of at least six for purchase requisitions totaling less than 5000 USD. You want to create an exception to this rule that requires approvals only up to a job level of at least four, when the requisition is for computer equipment. The rule you want would be of the exception type (not the list-creation type), because it decreases the level of approval authority required. So you would follow these steps to create the rule:
The pre-existing list-creation rule for the normal case would already have required a TRANSACTION_AMOUNT currency attribute, and a condition defined on that attribute. However, the Purchase Requisition transaction type might not include a suitable predefined attribute for a transaction's category. Supposing it does not, create a string attribute named (say) 'CATEGORY'. (If the attribute name already exists, share the attribute name. If not, create it with a sufficiently generic description for other transaction types to share the name, because the attribute name itself is sufficiently generic for several transaction types to want to use it.) Enter for the attribute a (dynamic) use that selects a Purchase Requisition's category from the appropriate tables or views.
Create an exception condition on the CATEGORY attribute having only one allowed value, (say) 'COMPUTER EQUIPMENT'.
You can now create the rule itself:
Enter the description 'computer equipment up to 5000 USD'.
Select the list-creation exception rule type.
Let the start date default to today.
Leave the end date blank, so the rule is in force indefinitely.
Select the absolute-job-level approval type.
Select the approval, 'Require approvals up to at least job level 4.'
Select the ordinary-condition attribute TRANSACTION_AMOUNT.
Select the ordinary condition, '0 <= TRANSACTION_AMOUNT < 5000'.
Select the exception-condition attribute CATEGORY.
Select the exception condition, 'COMPUTER EQUIPMENT.'
You must always create a use for a rule in the process of creating the rule.
To create a rule
Use the Create New Rule page.
Click the Rules tab to display the Rules 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 Rules link
Click Create to open the Create New Rule page.
Enter the rule details. The information you must enter varies with the rule type you select.
Note: Before you create a production rule, you must ensure the following:
Allow productions for your transaction type by selecting an appropriate value for the productionFunctionality configuration variable. See: Configuration Variables
Include the production action type for your transaction type. See: Predefined Action Types
Add the production actions, if required. See: Creating an Action
If you are creating a List Creation, Combination: List Creation, List Creation Exception, Pre-List Approver Group, Post-List Approver Group rules, then provide the following information:
Enter the rule name. Ideally, you can include the required approval action in the rule name.
Select the type of rule to enable AME to generate the transaction's approver list or productions.
Select the item class to enable the rule to generate approver lists of the items in the rule's item class.
Select the approver category if you have enabled for-your-information notifications for a given transaction type. AME assigns the approver category to each approver that the rule generates in its use. This enables a rule to generate approval approvers in one transaction type, and FYI-notification recipients in another transaction type.
Note: This feature will be available if the integrating application has implemented FYI Notifications. See: Configuration Variables
If you have enabled rule priority, then enter a priority. AME uses the rule priority to prioritize a transaction type's rules while generating the approver lists or productions.
Select the start and end date for the rule to determine its lifespan and indicate the period in which you can use the rule.
For List Modification and Substitution rule, you do not require item class and approver category details.
Click Next to add conditions.
Click Add Conditions to display the available conditions.
Select the required condition and click Continue to add the condition to the rule.
Note: You can create new conditions using Create or update an existing condition using the Update icon. The changes to an existing condition are applicable wherever this condition is used.
Click Next to add actions.
Select the action type and action.
Note: For a production rule, ensure you select the production action type and production action.
Click Next to review the rule details.
Click Finish to use the rule in your transaction type and also make it available for all transaction types.
To use a rule, from another transaction type, in the current transaction type
Click the Rules tab.
Click Use Existing Rule to open the Use Existing rule: Create Usage page.
Query the transaction type already using the required rule.
Select the start and end dates to determine the rule use's lifespan.
Note: Ensure the new use's lifespan does not overlap the lifespan you noted in step two above.)
If the rule has FYI notifications enabled, then select the use's approver category.
If the rule has use priorities enabled, then enter the use's priority.
Click Finish to add the rule use to the current transaction type.
To reuse an existing rule in the current transaction type
Click the Rules tab to display the current and future rules in the current transaction type.
Click the Duplicate icon for the required existing rule.
Select the lifespan, approver category, and priority for the new use.
Click Apply to add the new rule use to the current transaction type.
Use the Update Rule page.
Click the Rules tab to display the current and future rules in the current transaction type.
Click the Update icon for the rule you want to edit.
Modify the rule properties of interest.
Note: If you want to add a condition or an action, then click Add Condition or Add Action and enter the required details.
Modify the lifespan, approver category, and priority of the rule use and click Apply.
To delete a rule, you must ensure that the rule is not used in any transaction type. When the rule is not used in any transaction type, AME automatically deletes the rule.
To delete a rule use
Use the Rules page.
Click the Rules tab.
Click the Delete icon for the specific use of rule that you want to delete.
Confirm the deletion when prompted.
You can reinstate an inactive rule to use it in your transaction type.
To reinstate an inactive rule
Use the Use Existing Rule page.
Click Use Existing Rule in the Rules page to open the Use Existing Rule page.
Query the required transaction type.
Query the inactive rules in the transaction type.
Select the inactive rule and click Continue.
Enter rule life span details and click Finish to reactivate the rule in the transaction type.