Actions

Actions

Overview

An action is an instruction to AME to modify a transaction's approval process in the manner you specify. An approval rule's then part (its consequent) consists of one or more actions. Actions that modify a transaction's approver list are Approval actions or simply Approvals. Actions that generate a production (a variable-name or a value pair) are Production actions.

The following graphic illustrates an action in the approval rule:

Typically, AME provides all the action types and actions your implementation will require. There are many action types to choose from, so even if you don't expect to create a new action type or action, you must review the descriptions of the action types, to ensure you understand how to translate your business rules into appropriate actions.

Action Types

Every action belongs to an action type. An action type is a collection of actions having similar functionality. For example, actions in the absolute-job-level action type all require approvals up to a certain job level in the HR supervisory hierarchy. The main difference among the actions are the job level they require.

AME includes a set of predefined action types, many of which enable you to ascend commonly used organizational hierarchies. If none of the predefined action types meet your organization's requirements, you need a custom action type. An AME user with administrative privileges must use the Actions tab to define a new action type. See Chapter 2 of the Oracle Approvals Management Developer's Guide for details.

Action Type Properties

An action type has the following properties:

Name

An action-type name is a string up to 50 bytes in length.

Action-Type Handlers

An action-type handler is a PL/SQL package that implements the action type's functionality. AME calls the package's procedures at run time to determine how to process applicable actions of the corresponding action type.

All action types, except production action types, have handlers specified that are used at run time. Production action types require a handler name to be specified but is not used at runtime. AME does not use the handler name.

See Chapter 2 of the Oracle Approvals Management Developer's Guide for more details about action-type handlers.

Rule Types

An action type's allowed rule type is the type of rule that can use the action type's actions. Every action type has exactly one allowed rule type.

Action-Type Descriptions

An action-type description is a string up to 100 bytes in length. It describes the functionality shared by the action type's actions.

Allowed Approver Types

Action types with an allowed rule type other than substitution or production have one or more allowed approver types. These are the types of approvers that the action type can generate. Action types that use approver groups allow all approver types.

Order Numbers

An action type has an order number, which is always a counting number. The set of all action types for a given allowed rule type is ordered by the action types' order numbers. The order numbers start at one and ascend to at most the number of action types for the allowed rule type. Order numbers are not necessarily unique, so the highest order number may be lower than the number of action types.

AME uses the action types' order numbers to decide the order in which the action types of the applicable rules of a given rule type are processed at run time. This affects the order in which AME notifies the approvers. See Parallel Approval Process for details.

Chain of Authority Ordering Modes

Action types that have the chain of authority allowed rule type specify an ordering mode for the chains of authority generated by the action type's actions. When a single action type generates several chains of authority for a single transaction, the ordering mode tells AME how to order the chains of authority. This affects the notification order of the approvers in the chains of authority. See Parallel Approval Process for details.

Note: The chain of authority rule type includes both the list creation and list creation exception rule types.

Voting Methods

Action types that have the chain of authority allowed rule type specify a voting methods for the chains of authority generated by the action type's actions. This affects the notification order of the approvers in the chains of authority, and how AME treats their responses. See Parallel Approval Process for details.

Required Attributes For Action Types

Some action types require that a transaction type define a use for one or more attributes, to use actions of that type in its rules. These attributes are the action type's required attributes. An action type typically uses the values of its required attributes to calculate how the action type's actions should contribute to a transaction's approval process. The Approvals tab lists each approval type's required attributes.

Action Properties

An action has the following properties:

Action Descriptions

An action description is a string at most 100 bytes long. It must have the form of a complete imperative sentence expressing the action's effect on a transaction's approval process. When you create an action for a predefined action type, the new description must resemble as much as possible those of existing actions of the same type. For example, a supervisory-level action that requires the chain of authority to ascend the supervisory hierarchy exactly 15 approvers must have the description Require approvals up to the first 15 superiors.

Action descriptions are of two types:

• Static

  A static action description is a fixed string that AME provides for a predefined action, or that you enter upon creating an action. Most predefined actions have static descriptions.

• Dynamic

  A few action types must generate descriptions for their actions at the moment the description is displayed. These actions have dynamic action descriptions. An action type that produces dynamic action descriptions does so by executing an SQL query that is registered with AME when the action type is first created. The query must return a single row that is a string at most 100 bytes long. It may use either or both of the bind variables ':parameterOne' and ':parameterTwo'. AME assigns these variables the values of the action's parameters. See Chapter 2 of the Oracle Approvals Management Developer's Guide for details.

Action Parameters

An action's parameters tell the action type's handler how to process the action. Each action type has its own approval-parameter syntax rules. You must adhere carefully to these rules when you create a new action for a predefined action type.

Predefined Action Types

This topic provides the following information about each action type:

• What approver type(s) the action type uses

• What attributes it requires

• How the action type works

• The syntax and semantics of the action's parameters

The action types are sorted by allowed rule type and are broadly categorized as:

• Chain of authority action types

• List Modification action types

• Substitution action types

• Production action types

Chain of Authority (List Creation and List-Creation Exception) Action Types

The predefined action types that generate chains of authority do so by ascending the HR supervisory hierarchy or HR position hierarchy, or by treating an approver group as a chain of authority. In most cases one or more required attributes determine the first approver in the chain, and the particular action determines where the chain ends.

Action Types for the HR Supervisory Hierarchy

All of the action types that ascend the HR supervisory hierarchy require the TOP_SUPERVISOR_PERSON_ID attribute. This attribute's value should be the person ID of the employee at the top of the hierarchy, typically the CEO of a corporation. When this attribute has the appropriate value, a chain of authority can end with the top supervisor without AME raising an exception, even if the rules require a longer chain. If, however, the TOP_SUPERVISOR_PERSON_ID attribute does not identify the top supervisor, or if an employee is not the top supervisor but has no supervisor assigned to them, then AME raises an exception if it needs to generate a longer chain than the hierarchy allows.

Absolute-Job-Level Action Type

The absolute-job-level action type generates a chain of authority by ascending the HR supervisory hierarchy starting at a given approver and continuing until an approver with a sufficient job level is found. The HRMS per_all_assignments_f, per_jobs, and per_all_people_f tables and view define the supervisory hierarchy.

First Approver

By default, the first approver (starting point) in an absolute-job-level chain is the supervisor of the person identified by the required number attribute TRANSACTION_REQUESTOR_PERSON_ID. If the required number attribute JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID has a non-null value, however, the value identifies the first approver in the chain.

Note: An integrating application can override both of these first approvers via AME's programming interface. See Appendix A of the Oracle Approvals Management Developer's Guide for details.

Final Approver

The absolute-job-level action type's ascent up the supervisory hierarchy stops when it reaches one or more approvers having a sufficient job level. A job level is a value in the authority_level column of the Oracle HRMS table per_jobs. What sufficient means varies according to following:

• The job level required by the action. AME predefines actions for job levels one through 10.

• Whether the action is an at-most action or an at-least action.

• The value of the required attribute INCLUDE_ALL_JOB_LEVEL_APPROVERS.

If one or more approvers in the appropriate supervisory chain have the required job level, the chain's final approver does not depend on whether the action is an at-most action or an at-least action. In this case, if INCLUDE_ALL_JOB_LEVEL_APPROVERS is false, the chain includes and ends with the first approver with the required job level. If INCLUDE_ALL_JOB_LEVEL_APPROVERS is true, then the chain includes and ends with the last approver with the required job level.

If no approver in the appropriate supervisory chain has the required job level, and the action is an at-most action, then the chain includes and ends with the last job level before the first approver having a job level exceeding the required job level. If the action is an at-least action, then the chain instead ends with the first job level exceeding the required job level. In either case, whether the action type includes all of the approvers at the final job level depends on the value of INCLUDE_ALL_JOB_LEVEL_APPROVERS.

Two job-level actions may combine in an interesting way. Suppose, for example, that one rule requires approvers up to at least job level five, and another requires approvers up to at most job level six. If the hierarchy skips from job level four to job level seven, then AME can only satisfy both rules by including in the chain of authority one or all of the approvers with job level seven (depending on the value of INCLUDE_ALL_JOB_LEVEL_APPROVERS). In this case, the at-least action is more stringent than the at-most action, even though the at-most action requires a higher nominal job level. AME always satisfies the most stringent action, so be aware that job-level gaps can have surprising consequences.

Required Attributes

Following are the required attributes for this action type:

• JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID

• INCLUDE_ALL_JOB_LEVEL_APPROVERS

• TOP_SUPERVISOR_PERSON_ID

• TRANSACTION_REQUESTOR_PERSON_ID

Action Parameters

The parameters of absolute-job-level actions have the syntax

n{+,-}

where n is a positive integer representing the job level, a plus sign indicates an at-least action, and a minus sign indicates an at-most action. For example, the action with the description 'Require approvals up to at least level 1.' has the parameter '1+'.

Difference between At Least and At Most

At most specifies an action that has to be satisfied so that ascending the hierarchy requires an approver to be returned with a value “at most” to the level specified. For instance if the hierarchy has approvers with job level 2,3,5,6 and the rule stated Absolute job level require approvers up to at-most level 4 then the approvers with job level 2 & 3 would be returned but not the approver at level 5 even though at most level 4 was specified. However if the action is defined as “at-least” level 4 then approver 2,3,5 would be returned since we require an approver to at least level 4 and since this job level didn’t exist the approver with level 5 was returned.

Relative-Job-Level Action Type

The relative-job-level action type behaves exactly like the absolute-job-level action type, except its actions' parameters represent the difference between an approver's job level and the requestor's job level. For example, the relative-job-level action with the parameter '3+' ascends the chain of authority until it reaches a job level at least three levels higher than the requestor's job level. If the requestor has a job level of two, the action would ascend at least to job level five.

Required Attributes

The action type has the same required attributes as the absolute-job-level action type, and uses them in the same way. Following are the required attributes for this action type:

• INCLUDE_ALL_JOB_LEVEL_APPROVERS

• JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID

• TOP_SUPERVISOR_PERSON_ID

• TRANSACTION_REQUESTOR_PERSON_ID

Action Parameters

The action parameters have the same syntax, with the integer value described as explained above.

Manager-then-Final-Approver Action Type

The manager-then-final-approver action type is another variant of the absolute-job-level action type. Instead of requiring approval from every person in an ascent up the supervisory hierarchy, this action type only includes the first and final approvers.

Required Attributes

The action type's required attributes are the same as those of the absolute-job-level action type. Following are the required attributes for this action type:

• INCLUDE_ALL_JOB_LEVEL_APPROVERS

• JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID

• TOP_SUPERVISOR_PERSON_ID

• TRANSACTION_REQUESTOR_PERSON_ID

Action Parameters

The action type's action-parameter-syntax rules are the same as those of the absolute-job-level action type.

Final-Approver-Only Action Type

The final-approver-only action type is also a variant of the absolute-job-level action type. Instead of requiring approval from every person in an ascent up the supervisory hierarchy, this action type only includes the final approver.

Required Attributes

The final-approver-only action type's required attributes are the same as those of the absolute-job-level action type. Following are the required attributes for this action type:

• INCLUDE_ALL_JOB_LEVEL_APPROVERS

• JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID

• TOP_SUPERVISOR_PERSON_ID

• TRANSACTION_REQUESTOR_PERSON_ID

Action Parameters

The action type’s action-parameter-syntax rules are similar. The syntax is

{A,R}n{+,-}

For example, ‘A3+’ means the final approver should have an absolute job level at least three levels above the requestor’s.

Dual-Chains-of-Authority Action Type

Some transactions require approval from two chains of authority, each starting with a different approver in the supervisory hierarchy. For example, an employee transfer may require approval from chains of authority starting at the employee's old and new supervisors. In such cases, use the dual-chains-of-authority action type.

First Approvers

The dual-chains-of-authority action type requires two attributes: FIRST_STARTING_POINT_PERSON_ID and SECOND_STARTING_POINT_PERSON_ID. These attributes' values identify the first approver in each chain of authority generated by the action type, so they must always have non-null values when rules using the action type apply to a transaction.

At Least One Action per Chain

The dual-chains-of-authority action type is unique in requiring that multiple actions apply to a transaction, at least one for each chain of authority generated by the action type. Typically dual-chains actions apply to a transaction in pairs, with one action in the pair for the first chain and the other for the second chain. In such cases, make each pair of actions part of the same rule. For example:

If
                TRANSACTION_CATEGORY in {TRANSFER}
then
        Require approvals at most 3 levels up in the first chain.
        Require approvals at least 2 levels up in the second chain.

Final Approvers

As usual, when multiple dual-chains actions for the same chain apply, AME determines which has the most stringent requirement for that sub chain, and enforces that requirement.

Required Attributes

Following are the required attributes for this action type:

• INCLUDE_ALL_JOB_LEVEL_APPROVERS

• FIRST_STARTING_POINT_PERSON_ID

• SECOND_STARTING_POINT_PERSON_ID

• TOP_SUPERVISOR_PERSON_ID

• TRANSACTION_REQUESTOR_PERSON_ID

Action Parameters

The parameters of dual-chains-of-authority approvals have the syntax:

{1,2}{A,R}n{+,-}

The first integer (a one or a two) identifies the (first or second) chain. The letter (an 'A' or an 'R') indicates whether n (a positive integer) should be interpreted as an absolute or a relative job level. The plus or minus sign is interpreted as it would be for the absolute- or relative-job-level action type, as appropriate. For example, the action with the description 'Require approvals at most 8 levels up in the second chain.' has the parameter '2R8-'.

Line-Item Job-Level Chains-of-Authority Action Type

The line-item job-level chains-of-authority action type is included in the current version of AME for backwards compatibility. It generates one chain of authority for each line item. These chains of authority are associated with the header item (as in previous versions of AME, which did not generate separate approver lists for items in subordinate item classes), not with the line items, in the transaction's approver list.

First Approvers

The line-item-level required attribute LINE_ITEM_STARTING_POINT_PERSON_ID identifies the first approver in each chain of authority. Because this attribute has a distinct value for each line item, each chain can be unique, and can start at a distinct job level.

Final Approvers

The line-item job-level chains-of-authority action type generates chains in the same way as the absolute-job-level action type. Because the same actions generate all of the chains, the chains all end at the same job level. The required attributes INCLUDE_ALL_JOB_LEVEL_APPROVALS has the same function for this action type as for that one.

Required Attributes

Following are the required attributes for this action type:

• INCLUDE_ALL_JOB_LEVEL_APPROVERS

• LINE_ITEM_STARTING_POINT_PERSON_ID

• TOP_SUPERVISOR_PERSON_ID

Action Parameters

The line-item job-level chains-of-authority action type's action parameters have the same syntax and interpretation as for the absolute-job-level action type.

Supervisory-Level Action Type

The supervisory-level action type ascends the HR supervisory hierarchy, generating a chain that has a fixed number of approvers in it. Note that there is no precise correlation between the number of supervisors ascended and the job level. Job levels can be skipped, or can occur several times, in a supervisory chain of authority.

First Approver

By default, the first approver in the chain is the supervisor of the employee identified by the required attribute TRANSACTION_REQUESTOR_PERSON_ID. However, if the required attribute SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID is non-null, the chain starts with the approver identified by this attribute instead. (As always, an integrating application can override both of these first approvers via AME's programming interface. See Appendix A of the Oracle Approvals Management Developer's Guide for details.)

Final Approver

The chain of authority generated for a given action contains the number of approvers specified by the action's parameter, when it is possible to ascend the HR supervisory hierarchy that many approvers. When the hierarchy contains fewer approvers than the action requires, the result depends on whether the action is an at-most action. If it is, and if the last approver is identified by the required attribute TOP_SUPERVISOR_PERSON_ID, the chain ends with this approver. However, if this attribute's value is null, or if the action is not an at-most action, AME raises an exception.

Required Attributes

Following are the required attributes for this action type:

• TOP_SUPERVISOR_PERSON_ID

• SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID

• TRANSACTION_REQUESTOR_PERSON_ID

Action Parameters

Supervisory-level actions have parameters of the form

n[-]

where n is a positive integer indicating how many approvers the chain should contain, and the optional minus sign makes the action an at-most action when present.

Action Types for the HR Position Hierarchy

There are two action types for the HR position hierarchy (residing in per_pos_structure_elements, per_pos_structure_versions, and per_position_structures). The difference between them is how they decide where to end a chain of authority.

hr position level action type requires the TOP_POSITION_ID attribute, which is wholly analogous to the TOP_SUPERVISOR_PERSON_ID attribute for the action types that ascend the HR supervisory hierarchy.

Both action types also require the NON_DEFAULT_POSITION_STRUCTURE_ID attribute. By default, the chain of authority ascends the primary position structure of the business group of the transaction requestor. However, if NON_DEFAULT_POSITION_STRUCTURE_ID is non-null, the chain will follow the position structure identified by the value instead.

‘hr position’ Action Type

The ‘hr position’ action type generates a chain of authority ending with a specified position. Note that position actions have dynamic descriptions.

First Approver

By default, a position chain of authority starts with the position above the position identified by the required attribute TRANSACTION_REQUESTOR_POSITION_ID. If however the required attribute NON_DEFAULT_STARTING_POINT_POSITION_ID is non-null, the chain starts with this position instead.

Final Approver

The final approver is the position specified by the action's parameter.

Required Attributes

Following are the required attributes for this action type:

• TRANSACTION_REQUESTOR_POSITION_ID

• NON_DEFAULT_POSITION_STRUCTURE_ID

• NON_DEFAULT_STARTING_POINT_POSITION_ID

Action Parameters

A position action's parameter is the wf_roles.name value of the position at which the chain should end. Currently positions in wf_roles have name values such as 'POS:471', where the positive integer following the colon is a position ID.

Position-Level Action Type

The position action type generates a chain of authority having a specific length.

First Approver

The position-level action type starts its chains the same way the position action type does.

Final Approver

The position-level action type ascends the position hierarchy a fixed number of positions (in analogy with the supervisory-level action type for the HR supervisory hierarchy).

Required Attributes

Following are the required attributes for this action type:

• TOP_POSITION_ID

• TRANSACTION_REQUESTOR_POSITION_ID

• NON_DEFAULT_POSITION_STRUCTURE_ID

• NON_DEFAULT_STARTING_POINT_POSITION_ID

Action Parameters

The parameters of position-level actions have the syntax

n+

where n is a positive integer representing the number of positions the action requires.

Actions Types for Approver groups

There are three predefined action types that use approver groups, one for each sub-list in an item's approver list. All three approval-group action types require the ALLOW_EMPTY_APPROVAL_GROUPS attribute. When this attribute is false, AME raises an exception if a group's has no members at run time.

Approver-Group Chain of Authority Action Type

The approver-group chain of authority action type treats an approver group as a chain of authority. AME ignores the approver group's voting regime and uses the action type's instead. When the action type uses the serial voting regime, the serial order is consistent with the group members' order numbers.

Required Attributes

ALLOW_EMPTY_APPROVAL_GROUPS is the required attribute for this action type.

Pre- and Post-Chain of Authority Action Types

The pre-chain of authority action type inserts approver groups before the authority sub-list of an item's approver list. The post-chain of authority action type inserts approver groups after the authority sub-list of an item's approver list. The notification order is not necessarily the same as the order in the approver list. Both use approver groups' voting regimes.

Required Attributes

ALLOW_EMPTY_APPROVAL_GROUPS is the required attribute for this action type.

List-Modification Action Types

There are two predefined list-modification action types, and they have opposite effects. One grants signing authority to someone who normally lacks it; the other revokes the signing authority of someone who normally has it.

Final-Authority Action Type

The final-authority action type effectively grants a target approver signing authority in contexts where they usually lack. It does so by truncating each chain of authority containing the target approver, after the approver. (If the target approver forwards without approving, the action type truncates the chain of authority after the last forwardee following the target approver.) The action type has only one action, which has a null parameter.

Non-Final-Authority Action Type

The non-final-authority action type effectively revokes a target approver's signing authority in contexts where they normally have it. It does so by extending a chain of authority ending with the target approver beyond the target approver, up to some absolute or relative job level, depending on the particular action's requirement. Because the actions depend on job levels, the target approver must be an HR employee, and the HR implementation must use job levels.

Non-final authority actions' parameters have the syntax

{A,R}n{+,-}

The 'A' or 'R' indicates whether n (a positive integer) represents an absolute or relative job level. The plus or minus sign is interpreted as for the job-level action types. For example, the action having the description 'Require approvals at most 2 levels up.' has the parameter 'R2-'

Substitution Action Type

There is just one predefined substitution action type. It replaces the target approver with the approver identified by the substitution action. The parameters for substitution approvals are wf_roles.name values. When you create or edit a substitution action, the AME user interface lets you select an approver type and then query for an approver, so you don't have to create or edit the parameter or action-description directly.

Production Action Type

There is just one predefined production action type. Each production action causes AME to output to the integrating application the variable-name/value pair in the action's parameters. The variable name and value are strings up to 50 bytes long.

Production Levels

If a production action is used by a rule that also has one or more approver-generating actions, the production is associated with each approver generated by the rule's approver-generating actions. Such actions are approver-level productions. Production actions in production rules are associated with the transaction as a whole, and so are transaction-level productions

Choosing an Action

Choosing the right action for a rule requires three choices. The subsections below explain them.

1. Choose a rule type.

   See Rule Types for a complete explanation of the rule types. Here are brief explanations of when to use each:

   • Use list-creation rules to generate chains of authority.

   • Avoid using list-creation exceptions. Use list-creation rules and rule-use priorities instead. See Rule Priorities and Using Rules for details about rule-use priorities.

   • Use pre- and post-chain of authority rules to let groups of subject-matter experts approve a transaction before or after management.

   • Use list-modification rules to grant unusual signing authority, or to revoke usual signing authority, in special cases.

   • Use substitution rules to replace one approver with another in special cases, or for short periods of time (such as vacations or leaves of absence).

   • Use combination rules when several of your business rules apply to exactly the same cases. There are two kinds of combination rules: those combining multiple list-creation, pre-chain, and/or post-chain actions; and those combining multiple list-modification and/or substitution actions.

   • Use production rules when an integrating application uses AME productions. Consult your integrating application's documentation to learn whether the application uses productions.

2. Choose an approver type

   Most of the rule types have just one predefined action type available to them. There are two action types available to list-modification rules; which to use depends on whether you want to grant or revoke signing authority. List-creation rules have many action types available to them. Before you can choose one of them, you must decide which approver type should occur in the chains of authority your list-creation rule will generate. AME current supports three approver types: HR employees (sometimes called persons/HR people in the AME UI), HR positions, and FND (Oracle Applications) users.

3. Choose an action type.

   Once you have chosen an approver type for your list-creation rule, you can choose an action type that generates a chain of authority containing that approver type, and having the structure you want. The following tables list the action types that generate chains of authority, sorting them by approver type, and indicating the structure of the chains of authority they generate.

   Action Type	Chain Structure for HR Employee (Person) Approver Type
   absolute job level	The chain ends with one or more approvers at, just under, or above a fixed job level.
   relative job level	The chain ends with one or more approvers at, just under, or above a job level a fixed number of levels above the requestor's job level.
   manager then final approver	The chain includes the first and last approvers in the chain that would be generated by a similar absolute or relative-job-level action.
   final approver only	The chain includes just the last approver in the chain that would be generated by a similar absolute or relative-job-level action.
   dual chains of authority	There are two chains of authority, each with its own first approver, and each having an absolute- or relative-job-level structure.
   line-item job-level chains of authority	There is one chain of authority per line item. All of the chains are in the header item's approver list. To generate line-item-specific chains of authority within the line items' approver lists, use one of the other action types for HR employees, and associate your rule with the line-item item class.
   supervisory level	The chain contains a fixed number of HR employees.

   Action Type	Chain Structure for HR Position Approver Type
   hr position	The chain ends with an approver having a fixed position.
   hr position level	The chain contains a fixed number of positions.

   Action Type	Chain Structure for All Available Approver Types
   approval-group chain of authority	The approver group allows all available approver types.

Creating an Action Type

Creating an action type involves a significant programming exercise, as well as registering the new action type with AME. These tasks are beyond the scope of this guide. See Chapter 2 of the Oracle Approvals Management Developer's Guide for details.

To create an action type

Use the Create New Action Type page.

1. Click the Action Types tab to display the Action Types 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 Action Types link.

2. Click Use Existing Action Type to open the Use Existing Action Type page.

3. Click Create to open the Create New Action Type page.

4. Enter a name.

5. Enter the action type's handler to implement the action type's functionality. AME uses the handler information to determine how to process applicable actions of the corresponding action type.

6. Select the rule type to specify the allowed type of rule that can use the action type's actions.

7. Enter the action type description to explain the functionality shared by the action type's actions.

8. Select the allowed approver type to enable the action type to generate the specified types of approvers.

9. Select the dynamic action description. If you select Query Generate, then enter the action description query and click Validate to ensure the query is well formed.

10. Click Apply to make the action type available to all the transaction types.

Editing an Action Type

To update an action type

1. Click the Action Types tab to open the Action Types page.

2. Click Use Existing Action Type to display the available action types.

3. Select the action type and click the Update icon to edit.

4. Change the action type's properties as appropriate.

5. Click Apply to submit your changes.

   Note: You cannot edit predefined action types' properties; you can only add and delete user-defined actions.

Deleting an Action Type

To delete an action type

1. Click the Action Types tab to open the Action Types page.

2. Click Use Existing Action Type to display the available action types.

3. Select the action type and click the Delete icon.

4. Confirm the deletion when prompted.

   You can delete several action types at once.

   Note: You cannot delete predefined action types.

Using an Existing Action Type

To use an existing action type into your current transaction type

Use the Use Existing Action Type page.

1. Click Use Existing Action Type to open the Use Existing Action Type page.

2. Select an action type and click Continue.

3. Review the attributes that appear.

   Note: The Use Existing Action Types Review page displays the required attributes that are not currently available but will appear in your transaction type based on the selected action type.

4. Click Finish to use the selected existing action type in your current transaction type.

Creating an Action

To create an action for an existing action type

Use the Create Action page.

1. Review the action type's parameter syntax and semantics rules.

2. Click the Action Types tab.

3. Select the action type to which you want to add actions.

4. Click Create to open the Create Action page.

5. Enter the new action's parameter(s) and description.

6. Click Apply to add the action to the selected action type.

   Note: You never need to add actions to the approver-group action types. AME creates these actions automatically when an approver group is created.

Editing an Action

To edit an action

Use the Update Action page.

1. Click the Action Types tab to open the Action Types page.

2. Select the action type whose action you want to edit.

3. Select the action and click the Update icon to edit.

4. Change the action's properties as appropriate.

5. Click Apply to submit your changes.

   Note: You cannot edit predefined actions, or approver-group actions. AME maintains approver-group actions automatically.

Deleting an Action

To delete an action

Use the Action Types page.

1. Click the Action Types tab to open the Action Types page.

2. Select the action type whose action you want to delete.

3. Select the action and click the Delete icon.

4. Confirm the deletion when prompted.

   You can delete several actions at once.

   Note: You cannot delete a predefined action, but you can delete an action that has been added to a predefined action type. Also, you cannot delete approver-group actions. AME deletes these automatically when you delete the approver group.