Approvals and Escalations
Core Process
About Approvals and Escalations
Approvals and escalations are used to interrupt a business process. Both approvals and escalations are used when someone else needs to take action. For example, your manager might need to approve any purchase order over $500.00. Or, an account manager might want to contact a customer whenever that customer opens a high priority request
You can use approvals and escalations for the following:
- Simple approvals based on dollar amounts
- Simple escalations for informational purposes
- Multiple‐level formal approvals using escalation hierarchies
Based on parameter settings, once a record is approved, you can prevent further changes by freezing the record. After a record is frozen, the only persons with the appropriate functions specified on their Role record can change the frozen record.
About Simple Approvals Approvals are used to prevent someone from posting a specified record without having it reviewed by someone of higher authority. For records that have a monetary amount specified, when attempting to post, if the approval limit for the person is not specified or is less than the amount specified on the record, a message appears and the approver specified is changed to the value of the next approver for the person. This process repeats sequentially until a person with a high enough approval limit can approve the record.
For records with no monetary amount, such as engineering change orders or solutions, the approval limit is ignored, and the next approver specified on the Person record is the only approver for that person. The last person in the chain has no approver specified and is the final approver.
The alternate approver can also approve if the approver is not available. Once the record is finally approved, it can then be posted.
Approvals are enabled at the organization level by setting an application parameter, ENABLE_SIMPLE_APPROVALS. The following values can be specified singly or in combination:
- Contract
- Engineering Change Order
- Purchase Order
- Quote
- Solution
About Simple Escalations
Escalations are records that are created because something happens that requires the attention of a person with higher authority or greater expertise. Escalations are typically created as exceptions or checkpoints in the normal business process. Typically, escalations are created for customer issues, internal process controls, and approvals.
Escalations can be created manually but are usually created automatically using business rules. You can automatically create escalations based on information in the following records:
- Request
- RMA, RMA Line
- Task
- Quote
- Purchase Order
- Project
- Contract
- Part Need
We recommend that you use one field on any of the above screens to determine whether the related record requires an escalation. For example, you can use the Action field on the Request screen to determine whether the request requires escalation. The table below lists the recommended fields to use when creating escalations. Use the View Information entry on the Help menu to get the table and column name for the field.
Screen |
Recommended Fields |
Request | Action |
RMA | Status |
Task | Status |
Quote | Status, Approval Status |
Purchase Order | Status, Approval Status |
Project | Action |
Contract | Contract Status, Approval Status |
Part Need | Quantity BacK Ordered (original value greater than zero, new value zero) |
Rules are typically set up to create a new escalation when one of the fields referenced above changes. For example, you can set up a business rule to create an escalation when the purchase order status is changed to Submit, indicating that the purchase order is ready for review. You can assign escalations in one of two ways. You can specify a team to assign, and anyone on the designated team can be assigned to resolve the escalation. Although it can result in extra administration, you can also specify a person to assign on the escalation. If you choose, you can also set up notifications. Notifications are not based on the escalations but rather the conditions that created the escalation. For example, if you use a value in the Action field of a request to create an escalation, you can also use an event to create a notification to the request owner. After the escalation is created, it is assigned, reviewed, and resolved. Resolving escalations includes following your organization’s procedures and then changing the status of the escalation to Completed.
About Approvals Using Escalation Hierarchies
There are two key elements of approvals using escalation hierarchies: the Position record and the escalation hierarchy. The position corresponds to a person’s job, for example, software development manager. The Position record has the following attributes:
- A person ID is specified for the position. A position can have only one person, although a person can be assigned to multiple positions.
- A position can have one or more approval limits. An approval limit can be an amount or a percentage, for example a maximum discount percentage, or both an amount and a percentage. You specify the table for the appropriate record, the currencies, and the values for amount or percentage. An optional approval limit type can describe the specified limit.
- A position can be delegated, for example, when the person holding that position is on vacation. You can choose to delegate to another position or to a specific person. The delegation can have a start and end date and time and has an option to select whether the delegation is active.
- Multiple classification fields enable you to group positions for reporting purposes. For example, you can specify organizational or physical services groups, as well as category, class, type, and status.
The escalation hierarchy determines which positions, and consequently persons, are notified that an approval is required. An escalation hierarchy contains each position and the sequence determines the order in which the positions approve. You can specify that approvals occur sequentially, in parallel, or any combination of the two. For example, a manager can approve first, followed by three other positions in parallel. Assigning the same sequence number to multiple positions indicate that they approve in parallel.
When an escalation is rejected, any parallel escalations and all subsequent escalations are canceled. After any changes, the approval must be resubmitted.
The Position screen enables you to set up positions and assign persons to them. The Escalation Hierarchy screen enables you to set up escalation hierarchies. The Approval Limit Financial Rules screen enables you to set up rules that determine the value of a record, such as a contract, which can be used to compare with approval limits.
Approvers can use e‐mail to respond to a notification to approve or reject. After receiving a notification, the approver can reply using specified keywords and IFS Field Service Management (FSM) performs the approval based on the reply.
Three keywords are used to signify the reply to the approval:
- Escalation ID
- Response Message
- Note
An e‐mail reply containing the first two keywords, and optionally the third, is processed by FSM appropriately. Values for each keyword are specified using a colon followed by a space and the value within single quotes. For example, a reply may contain the following:
- Escalation ID: '100101'
- Response Message: 'Reject'
- Note: 'Over budget'
In this example, the escalation 100101 is rejected for the reason of “over budget”.
A response message can contain one of three values: approve, reject, or hold. Case of the response message is ignored. You can choose to create your e‐mail notification with these values prefilled; the approver can then reply with the default values to approve and make the necessary changes to hold or reject.
Setting Up Approvals and Escalations
About Code Tables
Table Name |
Location |
Desciption |
approval_status | FSM Codes | Contains values for escalation status. |
esc_status | Code Tables | Contains values for escalation status. |
About Important Records
Person
DetailsThese fields are used for simple approvals.
Field Label |
Description |
Approval Limit | Identifies the maximum whole number amount, in corporate currency, that the person can post. |
Next Approver | Identifies the next approver to assign when the person cannot post. |
Alternate Approver | Identifies who can approve when the person specified in the Next Approver field cannot post. |
Positions
These fields are used by escalation hierarchies.
Field Label |
Description |
Position ID | Identifies the position related to this person. |
Position Name | Describes the position. |
Active | Indicates whether this person is currently active in this position and can perform approvals. |
Team
Simple escalations are usually assigned to teams. Create the appropriate teams to handle escalations and make sure team members are active.
About Application Parameters
ENABLE_SIMPLE_APPROVALS.
Set this value to the records for which you want to require approval using simple approvals. Values are CONTRACT, ECO, PURCHASE_ORDER, SOLUTIONS, and QUOTE. Multiple values can be specified, separated by a comma and no spaces.
ESCALATION_STATUS_CANCELED.
Set this value to the escalation status to set when an escalation is canceled. Values are defined on the esc_status code table.
ESCALATION_STATUS_COMPLETED.
Set this value to the escalation status to set when an escalation is completed. Values are defined on the esc_status code table.
ESCALATION_STATUS_ERROR.
Set this value to the escalation status to set when an escalation causes an error. Values are defined on the esc_status code table.
ESCALATION_STATUS_NEW.
Set this value to the status you want to assign to a new manually‐created escalation. Values are defined on the esc_status code table.
FREEZE_CONTRACT_APPROVAL_STATUS.
Set this value to the contract approval status that prevents changing of a contract and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_ECO_APPROVAL_STATUS.
Set this value to the ECO approval status that prevents changing of an ECO and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_INVOICE_APPROVAL_STATUS.
Set this value to the invoice approval status that prevents changing of an invoice and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_NON_PART_USAGE_APPROVAL_STATUS.
Set this value to the non‐part usage approval status that prevents changing of non‐part usage and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_PROJECT_APPROVAL_STATUS.
Set this value to the project approval status that prevents changing of a project and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_PURCHASE_ORDER_APPROVAL_STATUS.
Set this value to the purchase order approval status that prevents changing of a purchase order and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_QUOTE_APPROVAL_STATUS.
Set this value to the quote approval status that prevents changing of a quote and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_REQUEST_APPROVAL_STATUS.
Set this value to the request approval status that prevents changing of a request and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_REQUEST_LINE_APPROVAL_STATUS.
Set this value to the request line approval status that prevents changing of a request line and and related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_REQUEST_UNIT_APPROVAL_STATUS.
Set this value to the request unit approval status that prevents changing of a request unit and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_SOLUTION_APPROVAL_STATUS.
Set this value to the solution approval status that prevents changing of a solution and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
FREEZE_TASK_APPROVAL_STATUS.
Set this value to the task approval status that prevents changing of a task and any related child records. Values are defined on the approval_status FSM code table. Multiple values can be specified and must be separated by commas without spaces.
About Business Rules
Required Business Rules
Generate Request Escalation (Process 48)
This process creates an escalation based on request information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from requests. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as priority, severity, or place ID to create an escalation record.
Generate Task Escalation (Process 49)
This process creates an escalation based on task information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from tasks. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as priority, severity, or place ID to create an escalation record.
Generate Purchase Order Escalation (Process 50)
This process creates an escalation based on purchase order information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from purchase orders. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as approval status or purchase order status to create an escalation record.
Generate Project Escalation (Process 51)
This process creates an escalation based on project information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated. You can specify input parameters from projects. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as priority, severity, or place ID to create an escalation record.
Generate Contract Escalation (Process 52)
This process creates an escalation based on contract information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from contracts. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as approval status or contract status to create an escalation record.
Generate Request Line Escalation (Process 53)
This process creates an escalation based on request line information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from request lines. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as priority, severity, or place ID to create an escalation record.
Generate Quote Escalation (Process 54)
This process creates an escalation based on quote information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from quotes. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as approval status or quote status to create an escalation record.
Generate Parts Available Escalation (Process 79)
This process creates an escalation based on part need information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated. Before an escalation can be created, there can be no backordered part needs on the same request.
You can specify input parameters from part needs. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Create a rule that has two parameters: the old value of the quantity backordered and the new value of the quantity backordered. When the following occurs, the rule evaluates as true and the escalation is created:
- The old value of the quantity backordered is more than zero
- The new value of the quantity backordered is zero
Generate Request Unit Escalation (Process 80))
This process creates an escalation based on request unit information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from request units. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as priority, severity, or place ID to create an escalation record.
Generate Non-Part Usage Escalation (Process 85)
This process creates an escalation based on non‐part usage information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from non‐part usage. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as line code, quantity, or price to create an escalation record.
Generate Invoice Escalation (Process 90)
This process creates an escalation based on invoice information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from invoices. The output parameter is a new escalation record.
We recommend the following when setting up this rule:
- Use information such as posting group or place ID to create an escalation record.
Generate Mobile Error Escalation (Process 96)
This process creates an escalation based on FSM mobile message error information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from FSM mobile message errors. The output parameter is a new escalation record.
Generate ECO Escalation (Process 97)
This process creates an escalation based on ECO information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from engineering change orders. The output parameter is a new escalation record.
When recommend the following when setting up this rule:
- Use information such as priority, severity, or place ID to create an escalation record.
Generate Solution Escalation (Process 107)
This process creates an escalation based on solution information. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify input parameters from solutions. The output parameter is a new escalation record.
Recommended Business Rules
Escalation Event Generation (Process 88)
This process creates escalation events. Rules are evaluated after specified information is inserted or updated on the database and all rules are evaluated.
You can specify any information on an escalation as an input parameter. You can also specify information on the related record for which the escalation is created. The output parameter is an event type.
We recommend the following when setting up this rule:
- Use status changes to create escalation events.
- Use changes to important fields, such as wanted by date, to create escalation events.
Escalation Event Notification (Process 89)
This process creates notifications based on escalation events. Rules are evaluated after specified information is inserted on the database and all rules are evaluated with all matching values returned.
The input parameter is an event type of an escalation event. The output parameters are a distribution list ID and a message name.
We recommend the following when setting up this rule:
- Create notifications for creation of escalations.
- Create notifications for escalations that are not approved or rejected within a certain time period by using the service monitor feature.
About the Position Screen
The Position screen is used to set up positions used by escalation hierarchies.
Header
Buttons
- New—used to create a new position
- Delete—used to delete a position
- Save—used to save the position
- Refresh—used to reload the position information from the database
Significant Fields
Field Label |
Description |
Position ID | Identifies the position |
Position Name | Describes the position. |
Access Group | Identifies who can view this position record. |
Parent Position ID | Describes the position. |
Access Group | Identifies the position that is the manager of this position. |
Active | Indicates whether this position record is active for selection. If a position is already part of an escalation hierarchy and the position is not active, the persons assigned this position cannot approve. |
Approval Limits
The following are used to specify an approval limit:
Buttons
- New—used to create an approval limit
- Delete—used to delete an approval limit
Significant Fields
Field Label |
Description |
Table Name | Identifies the record for which you are specifying a limit. |
Sort Order | Identifies in which order multiple rules for the same table are evaluated. |
Max Amount | Identifies the maximum amount that this position can approve. |
Currency | If you specify a maximum amount, identifies the currency that corresponds to the specified amount. Multiple amounts with different currencies can be specified. |
Max Percent | Identifies the maximum percentage of discount that this position can approve. |
The following are used to constrain an approval limit:
Buttons
- New—used to create a new constraint
- Delete—used to delete a a constraint
Significant Fields
Field Label |
Description |
Table Name | Identifies the table that contains the constraint. |
Column Name | Identifies the column that contains the constraint. |
Constraint Value | Identifies the value that must be matched for the approval limit to apply |
Delegates
Buttons
- New—used to create a new delegation
- Delete—used to delete a a delegation
Significant Fields
You can specify only one of position ID or person ID.
Field Label |
Description |
Delegate to Position ID | Identifies the position that can approve for this position |
Delegate to Person ID | Identifies the person who can approve for this position. |
Start | Identifies the start of the time period for when the delegation occurs. |
Delegate to Person ID | Identifies the person who can approve for this position. |
End Date/Time | Identifies the end of the time period for when the delegation occurs |
Delegate to Person ID | Identifies the person who can approve for this position. |
Active | Indicates whether this delegation is active, within the specified time period. |
About the Escalation Hierarchy Screen
This screen is used to set up escalation hierarchies. They are used to automate approvals by multiple persons.
Header
Buttons
- New—used to create a new escalation hierarchy
- Delete—used to delete an escalation hierarchy
- Save—used to save the escalation hierarchy
- Refresh—used to reload the escalation hierarchy information from the database
Significant Fields
Field Label |
Description |
Hierarchy ID | Identifies the escalation hierarchy. |
Access Group | Identifies who can view this escalation hierarchy record.. |
Auto Approval | Indicates whether the parent object can be immediately and automatically approved if submitter has the required approval limit. |
Escalate Direct | Indicates whether the escalation goes through the hierarchy directly to the persons with the required approval limits. |
End Date/Time | Identifies the end of the time period for when the delegation occurs |
Escalate Upfront | The value of the escalate upfront option determines whether all escalations for the hierarchy are created when the escalation process is initially triggered. |
Assign Upfront | Indicates the escalations for the hierarchy are assigned upon creation. |
Include Manager | Indicates whether to create an escalation for the submitterʹs manager when the approval is initially submitted. |
Manager Required | Indicates whether the submitterʹs managerʹs approval is required. |
Manager Sequence | Identifies the position within the hierarchy to insert the managerʹs escalation. |
Start After Submitter | Indicates whether the escalation hierarchy chain begins with the sequence directly after the sequence for the person who submitted the item for approval. |
Check Approval Limits | Indicates whether approval limits on the Person record are considered. |
Approval Limit Type | Identifies the approval limit on the Person record to consider when the check approval limits option is selected. |
Escalation Hierarchy List
Buttons
- New—used to add a new escalation hierarchy list entry
- Delete—used to delete an escalation hierarchy list entry
Significant Fields
Field Label |
Description |
Sequence | Identifies the position of this approver in the escalation hierarchy. If the manager sequence is specified above, that sequence number cannot be used in this field. |
Person ID | Identifies the person who can approve for this sequence. Only entered when position and team is not specified. |
Position ID | Identifies the position who can approve for this sequence. Only entered when person and team is not specified. |
Team ID | Identifies the team whose members can approve for this sequence. Only entered when person and position is not specified. |
Required | Indicates whether approval is required for this sequence. |
Table Name | If you want to constrain the approval, identifies the table that contains the constraint. |
Column Name | If you want to constrain the approval, identifies the column that contains the constraint. |
Column Value | If you want to constrain the approval, identifies the value used to constrain the approval. |
About the Approval Limits Financial Rules Screen
This screen is used to set up approval limits based on rules. A rule is one more records with the same rule ID. Rules are applied in addition to any other limits specified and apply to individual records.
Header
Buttons
- New—used to create a new approval limits financial rule
- Delete—used to delete an approval limits financial rule
- Save—used to delete an approval limits financial rule
Significant Fields
Field Label |
Description |
Approval Limit Rule | Identifies the rule. |
Table Name | Identifies the table, or record, that the approval limit applies to. |
Rule Parameters
Buttons
- New—used to create a new rule parameter
- Delete—used to delete a used to delete a rule parameter
Significant Fields
Field Label |
Description |
Table Name | Identifies the table that contains the parameter. |
Column Name | Identifies the column that contains the parameter. |
Rule Operator | If you want to constrain application of the rule, identifies the operator used to compare the constraint to the parameter. |
Column Value | If you want to constrain application of the rule, identifies the constraint. |
Parameter Type | Identifies how the parameter is applied to the limit. |
Simple Approvals Setup Procedure
To set up simple approvals, do the following:
- Specify the appropriate combination of values of contract, purchase_order, or quote for the ENABLE_SIMPLE_APPROVALS application parameter.
- Identify the persons to whom you want to assign approval limits.
- Identify the persons who can approve.
- Set an approval limit and approvers on the appropriate Person records.
- If you want to use escalations to manage approvals, set up the appropriate business rules.
Simple Escalations Setup Procedure
To set up simple escalations, do the following:
- Create a team and assign a team leader to perform escalations. Usually this team consists of customer support, managers, or problem resolution specialists. Team members must be active to be assigned escalations.
- Determine which fields to use to generate an escalation, for example, Action or Status.
- Set up the appropriate business rules. Specify a team, type, reason, status, and a duration. Specify any other information you want applied to escalations.
- If you want to send notifications, use the information you used as parameters for escalation business rules and set up the corresponding event and notification rules.
Approvals Using Escalation Hierarchies Setup Procedure
To set up approvals using escalation hierarchies, do the following:
- If you want to use e‐mail replies for approvals, enable the SMTP listener in your application server configuration file.
- Set up position records with the appropriate individual assigned to the position. If you want to assign approval limits to positions, you must also set up approval limit financial rules.
- Set up the appropriate application parameters.
- Set up the appropriate business rules.
- Set up the appropriate escalation hierarchies.
Using Approvals and Escalations
About the Unassigned Escalations Screen
This screen is used by team leaders to review and assign escalations to team members. When you access this screen, a queue of unassigned escalations for each team appears.
Header
Buttons
- Save—used to save the escalation
Escalations
Significant Fields
Field Label |
Description |
Escalation ID | Identifies the escalation and is also a link to the Escalation screen for this escalation. |
Owner | Identifies who owns the escalation and is responsible for resolving it. |
Escalation Status | Identifies the status of the escalation. |
Due Date | Identifies when the escalation is expected to be resolved. |
Overdue | Indicates whether the escalation is overdue. |
Table Name | Identifies the table or primary record that is the source of the escalation. |
Resolved | Identifies when the escalation is resolved. |
Members
The Members tab shows you the active members of this team and who is currently logged in to FSM.
About the My Team Escalations Screen
This screen is used by managers to review escalations assigned to team members.
Header
Buttons
- Save—used to save the escalation
Significant Fields
Field Label |
Description |
Person ID | Identifies who owns the listed escalations. |
Active | Indicates whether the person is currently an active team member. |
Escalations
Significant Fields
Field Label |
Description |
Escalation ID | Identifies the escalation and is also a link to the Escalation screen for this escalation. |
Owner | Identifies who owns the escalation and is responsible for resolving it. |
Escalation Status | Identifies the status of the escalation. |
Due Date | Identifies when the escalation is expected to be resolved. |
Overdue | Indicates whether the escalation is overdue. |
Table Name | Identifies the table or primary record that is the source of the escalation. |
Resolved | Identifies when the escalation is resolved. |
About the Escalations Screen
This screen is used by team members to search for and resolve their escalations.
Header
Buttons
- New—used to create a new escalation
- Delete—used to delete an escalation
- Save—used to save the escalation
- Refresh—used to reload the escalation information from the database
Significant Fields
Field Label |
Description |
Escalation ID | Identifies the escalation. |
Type | Identifies the type of escalation. |
Approval Status | For approval escalations, identifies the status of the approval part of the escalation. |
Escalation Status | Identifies the status of the escalation as set by the person who is working the escalation. |
Status | Identifies the status of the escalation as set by the person who is working the escalation. |
Resolution | The value of the resolution field identifies whether the escalation was resolved. |
Position ID | For approval escalations, identifies the position that can approve this escalation. |
Resolved | Identifies when the escalation is resolved. |
Owner | Identifies the person assigned to resolve the escalation. |
Delegated By | For approval escalations, if the escalation was delegated, identifies the person who delegated the approval. |
Overdue | Indicates whether the escalation is overdue. |
Using Simple Approvals
Simple approvals are performed on the appropriate screen:
- Contract
- Purchase Order
- Quote
1. A person with an approval limit creates a record that requires approval.
2. After clicking Post, a message appears and the Approval Status field is set
to Pending.
3. If escalations are set up, an escalation appears in the approver’s escalation
queue.
4. The approver does one of the following:
- The Approval Status field is set to Approved and the record is posted.
- The Approval Status field is set to Rejected and the record is saved.
It is possible that the approver also has an approval limit set. If the value of the record to be approved exceeds the limit of the current approver, the Approval Status field remains set to Pending and the next approver in line must attempt to approve the record.
Using Simple Escalations
1. An escalation is created in one of the following ways:
- An escalation is manually created.
- An escalation is automatically created using business rules.
2. The team leader uses the Unassigned Escalations screen to review and
assign escalations for the team.
3. Each team member uses the Escalations screen to review and resolve
escalations:
- Sort the Escalations screen by clicking column headings such as Overdue, Days Open, or Due Date to locate the most significant escalations.
- Click the Escalation ID link to open the record that caused the escalation to be created.
- Perform the necessary work and update the escalation as appropriate. You can use the Escalation tab on the screen that appears or return to the Escalations screen to update the escalation.
4. Complete the escalation. An escalation type of Approval signifies that an approval is required, for example an approval of a purchase order, quote, or contract.
Using Approvals Using Escalation Hierarchies
The following high‐level procedure describes how approvals using escalation hierarchies are created and resolved. The following steps assume that business rules create escalations and notifications.
1. The submitter creates a record that requires approvals, for example a
contract. Based on how business rules are set up, escalations are created
for the approvals.
2. Each approver receives a notification. The approver then approves or
rejects the escalation. If any approver rejects, all escalations are rejected
and the record must be submitted again.
3. After all approvers approve, business rules perform the appropriate action
based on your processes. If you have set up application parameters to
freeze the record during approvals, the record can then be posted.