Create approval rule

To create a new approval rule:

1. From the main menu, select Administration > Instance Management > Module - Workflow Rules.

   The Module - Workflow Rules screen appears.

2. Click the New Approval Rule link.

   The Create New Approval Rule window appears.

3. Use the following field descriptions to create your rule:

   Field	Description
   Description	Type a meaningful name for this rule. This value will appear as the name of the rule within the workflow tree diagram and will be seen by approvees and approvers.
   Apply Rule Against	These two drop-down fields allow you to define what this rule applies to. The first drop down list relates to either card transactions, card statements or expense reports. The second is the account type you want to apply the rule to. If you are creating an expense report approval rule, see the information on expense reports workflow at the end of this procedure.
   Account Type	The account type options available for selection are determined by the selection made in the Apply Rule Against field. If the rule you are setting up for a transaction or statement is further restricted by a specific account type, select it here.
   Issuer Type	The issuer type options available for selection are determined by the selection made in the Apply Rule Against field. If the rule you are setting up for a transaction or statement is further restricted by a specific issuer type, select it here.
   Parent Rule	If you are creating a transaction approval rule (ie. you selected Transactions from the Apply Rule Against drop-down list) and you want to set up a parent-child relationship between it and an expense report approval rule, select the expense report approval rule from the Parent Rule drop-down list. In a parent-child relationship, changes to the approval status of an expense report (parent) are immediately reflected in the approval status of its linked transactions (children).
   Group Member	If this rule relates to an existing group of rules, select the group from the drop-down list box. If you do not select a value, the rule will become an independent rule.
   Behaviour	The Behaviour field determines how this approval rule will behave in relation to other rules. There are two options in the drop-down list: Dominant. The transaction will always require approval for each dominant rule triggered for the transaction, ie. if two dominant rules are triggered by a single transaction, two approval rules will be required. Submissive. A submissive rule will be overridden by a dominant rule should it occur on the same transaction, ie. if two rules are triggered on the same transaction, one dominant and one submissive, the dominant rule will apply.
   Process Order	Where this rule fits within the process order in the group. The process order number determines the priority of the rule as selected by the system and therefore displayed to the approver. The number must be unique within the group, and the group's process ordering must be sequential, eg. 1,2,3,4 not 1,3,4,5.
   Dependency Order	The rule dependency order allows you to line a series of rules into a chain of approvals. For example, if you have a transaction which has been hit by three approval rules that all require approval: Approval rule X Approval rule Y Approval rule Z By adding a rule dependency order to the approval rules, you can chain these so that one rule has to be approved before another one will be available for approval, so instead of being independent they are 'chained'. For example if you had: Approval rule X - Order = 1 Approval rule Y - Order = 2 Approval rule Z - Order = 3 In this case only approval rule X will be available for approval to start with, Y/Z will not be available for the approver(s) to approve until X is approved. Once X is approved, Y is up for approval, and so-forth. Another version of this is maybe: Approval rule X - Order = 1 Approval rule Y - Order = 2 Approval rule Z - Order = 2 In this case, like the first example, approval rule X will be available for approval to start with, Y/Z will not be available for the approver(s) to approve until X is approved. However once X is approved, both Y and Z become available for approval, and can be approved in any order.
   Approver Grouping	A transaction can have one or many different approval rules attached to it. Each approval rule can then have one or many approvers to approve it. Approver groups are defined in the Workflow Roles area of the solution. These groups are firstly broken into the different approval roles, and then if applicable into further sub-groups based on the subject rule of the approval rule itself. The approval grouping options allow you to determine how groups are used. For example, a transaction with a charge code-based rule has been split across two transaction lines and coded to two projects: PRO1 and PRO2. This transaction has hit a coding, project-based approval rule, and therefore approval is required for the managers of the two projects. In this case Andrew is the manager for PRO1, and Diane and John are the managers for PRO2. With this set up, there are effectively two approver groups for this approval rule, the first group contains Andrew, and the second group contains Diane and John. Each approval group that a transaction triggers can be set to be subject to combined approval or independent approval. Combined Approval - When this option is selected, only one approver is needed to approve the rule. So, in the example above, if Andrew, Diane or John approve the rule, the approvals of the other two are no longer required. The others can at any time add comments or change the approval status if they want. Independent - Single Level - When this option is selected, one approver per group is required to approve the rule. So, in the example above, Andrew and either Diane or John have to approve the rule. If Diane approves the rule, John no longer has to, but Andrew does. At any time, any approver can add comments or change the approval status if they want. It is also possible to apply an approval threshold to each manager in a group. For example, if there are three managers (Diane, John and Joel) and their respective thresholds are $0, $500 and $1000, Diane can approve anything over $0, John can approve anything over $500 and Joel can approve anything over $1000. In this mode, the system will choose the manager whose threshold is up to and closest to the transaction amount. If the spend is $550, John would be chosen in this case. Independent - Dual Level - This is the same as the Independent - Single Level option, except it forces the system to choose two managers per group with thresholds up to and closest to the transaction amount, ie. John and Diane in the above example. Independent - Dual Level Minimum - This option only allows the approver to approve transactions with spend below their specified threshold. For example, if the three managers (Diane, John and Joel) have respective thresholds of $100, $500 and $1000, Diane can approve anything below $100, John can approve anything below $500 and Joel can approve anything below $1000. Warning: Advanced threshold limit options should only be used in consultation with your implementer.
   Single Approval	When this option is enabled, the user has the ability to select the approver he wants to approve his transaction. If the option is not enabled and there are multiple approvers available, all approvers will receive the transaction for approval.
   Transaction Status	This determines the stage at which a transaction will get forwarded to the approver to action. Independent. The transactions will be forwarded to the approver as soon as they are loaded into Shared Travel Services, irrespective of whether they have been coded or viewed by the user. Coded. The transactions will be forwarded to the approver if they have been correctly coded by the user, ie. they have a icon showing for the transaction status, or they have been default coded (they have a icon showing). Strictly Coded. The transactions will only be forwarded to the approver if they have been correctly coded and viewed by the user, ie. only when they have a icon showing for the transaction status.
   Automatic Rerouting	Transaction approvals can be rerouted if they are not actioned on in a specific time frame by entering the number of hours in the No. of Hours Before Rerouting field.
   Amount Rule	The Amount Rule and Amount Value fields allow you to build how the approval rule will function. This drop-down list contains the following options: Blank. If left blank, this rule will take effect for any transactions of this type, regardless of transaction value. Amount less than. The rule will be triggered if the transaction value is less than the amount specified in the first Amount Value field. Amount greater than. The rule will be triggered if the transaction value is greater than the amount specified in the first Amount Value field. Amount between. The rule will be triggered if the transaction value is greater than the value specified in the first Amount Value field and less than the value specified in the second Amount Value field.
   Amount Value	These values are used in combination with the Amount Rule field to define the circumstances under which this approval rule is enabled.
   Approval Rule Dates	These fields determine when a rule will be applied. Enter only the Start Date if the rule is effective from a specific date but does not expire. Enter only the Expiration Date if the rule is effective immediately but expires on a specific date. Enter both dates if the rule is effective only for a specific period. Leave both fields blank if the rule is effective immediately and never expires.

4. Click Save.

   The new rule box will appear as a light purple box in the workflow tree diagram.

Expense report approval rules

There is no transaction-level approval status for transactions that fall under an expense report approval rule. The approval status is associated with the expense report, not the transaction.

It is possible to incorporate the following into expense report approval rules in situations where a combination of transaction and expense report approval rules exist: Group Member, Behaviour, Process Order, Dependency Order, and Approver Grouping.