15.3 Superior Approval

The approval process supports stepwise approvals based on hierarchical relationships. Each applicant's request flows through the hierarchy according to the established superior-subordinate structure, making the approval process more flexible and adaptable.

15.3.1 Configuring Approval Relationships

"Application Management → Approval Manager → Approval Relationships" allows you to configure approval relationships by assigning an approval manager, effectively designating the "superior."

Function Button Guide

Successfully created approval relationships will appear in the "Approval Relationships" view. There are two ways to create an approval relationship:

Create a New Approver

Click the New button or right-click on an empty area in the view and select "Create New Approver". The dialog that appears displays the current console's user tree. Checking a user sets them as the approver for their group, including all subgroups.

Create a New Approval Relationship

Click the New button or right-click on an empty area in the view and select "Create New Approval Relationship". In the dialog that appears, choose the requestor and the approver.

When setting an approval relationship, if the requestor is a computer or user group, the selected approver will act as the approver for all objects in that group, including subgroups, at the organizational level. If the requestor is a specific computer or user, the approver will be responsible for that individual computer or user at the user level.

15.3.2 Assigning Positions

In "Request Management → Approver Management → Positions", you can view approvers and the requestors they oversee. By default, approvers have no assigned positions. Setting positions helps streamline management and can also be used in workflows, allowing a request to advance automatically once approved by an approver holding the designated position.

Function Button Guide

15.3.3 Approval Relationship Chain

Once an approval relationship is established, a chain is formed between requestors and approvers, applicable to both desktop requests and encrypted requests.

For a requestor, their approver is considered the "superior", who may also have their own approver, i.e., the superior's superior, and so on. This creates a hierarchical approval chain from the bottom up. The chain ends when the highest-level approver has no further superior.

When a workflow step is set to "Superior Approval", the request flows upward along the approval chain: first to the immediate superior, then to the superior's superior, and so on. At each level, once the approver completes their review, the request continues to the next level until the chain ends or the step's completion criteria are met.

Requestor Matching

When setting an approval relationship, both users and computers can be assigned a superior, meaning each has its own approval chain. When matching a requestor, the user's approval chain takes priority.

For example, if User A logs in on Computer B:

• If User A has an approval chain, it will be used.
• If User A has no approval chain (no superior), Computer B's approval chain will be used.
• If neither the user nor the computer has an approval chain, the requestor is considered to have no superior.

The following explanation uses a user as the requestor example; the process is the same for a computer requestor.

Example:

The user hierarchy is as follows (group names are enclosed in < >, approvers in ( ); approvers listed on a group represent organizational-level approvers, while approvers listed on a computer represent user-level approvers).

Entire Network Structure:

• ——<R&D Department> (Approvers: User A, User B)

  • ——User A

  • ——User B

  • ——User C

  • ——<R&D Team 1> (Approver: User D)

    • ——User D

    • ——User F

  • ——<R&D Team 2> (Approvers: User G, User A)

    • ——User G

    • ——User M

    • ——User H（Approver: User A）

    • ——User P（Approver: User C）

User G has no user-level approver assigned. Therefore, their organizational-level approvers—User G and User A—would normally be considered their superiors. However, since User G is the primary approver for their current group, R&D Team 2, this level is skipped. The request then moves directly to the parent group's approvers, User A and User B. At the organizational level, the primary approver, User A, has no further superior, so the approval chain ends.

Therefore, User G's approval chain is:

User G (Requestor) → User A, User B (Level 1)

User M has no user-level approver assigned. Therefore, their first-level superiors at the organizational level are User G and User A. The second-level superiors are User A and User B. Since the primary approver at the organizational level, User A, has no further superior, the approval chain ends.

Therefore, User M's approval chain is:

User M (Requestor) → User G, User A (Level 1) → User A, User B (Level 2)

User H has organizational-level approvers User G and User A, as well as a user-level approver User A. Since user-level approvers take precedence, User H's superior is User A. At the organizational level, the primary approver User A has no further superior, so the approval chain ends.

Therefore, User H's approval chain is:

User H (Requestor) → User A (Level 1)

User P has organizational-level approvers User G and User A, but also a user-level approver User C. Since user-level approvers take priority, User P's superior is User C.User C does not have a user-level approver, so their organizational-level approvers are User A and User B. At this level, the primary approver User A has no superior, so the approval chain ends.

Therefore, User P's approval chain is:

User P (Requestor) → User C (Level 1) → User A, User B (Level 2)

15.3.4 Configure Approval Workflows

In "Request Management → Desktop Request Management → Workflow Management", you can configure approval workflows. At each workflow step, you may enable the Superior Approval mode. In this mode, there is no need to manually assign approvers—the request will follow the existing approval chain and move upward step by step.

Superior Escalation Within a Step

When a request enters a step in Superior Approval mode, the following applies:

• At approval level N, once the required number of approvers approve, the request advances to level N+1.
• If the required number of approvals is not met and any approver rejects, the request moves back to level N-1.
• Approvers at level N-1 do not need to review again:
  • If any approver clicks Reject, the request returns to level N-2.
  • If any approver clicks Comment and provides an approval explanation, the request returns to level N.

If a request is rejected at level 1:

• When the current step is not the first step, the request returns to the previous step. If that step is also in Superior Approval mode, the request flows to the last approver in that step's approval chain.
• When the current step is the first step, the same applies: the request returns to the previous step, and if it is in Superior Approval mode, it flows to the last approver in that step's approval chain.

Once the approval chain for a step is fully completed, the request proceeds to the next step. If it was the final step, the request is closed.

For any request under approval, an administrator with Rejection Authority can deny the request at any point. Once rejected, the request is immediately marked as Denied and will not return to any previous step. For requests that have been approved but not yet executed, a rejection prevents execution.

Superior Approval Settings

Consecutive Approval Levels

This option is enabled by default with a level of 1 and supports integers from 1 to 10. The request follows the approver chain and stops once the specified level is reached, completing the current step.

Example:

If a requestor's approval chain has 3 levels:

• If the level is set to 2, once level 2 approves, the request does not proceed to level 3 and the current step ends, moving to the next step.
• If the level is set to 5, the request continues until level 3 approves (the last level in the chain), and then moves to the next step.

Multi-Level Approval Until Specified Group Level

Enable this option to stop the request once it reaches or exceeds the specified group level. The default level is 1, supporting integers from 1 to 10.

The level refers to the hierarchy in the organizational tree: the top-level group is level 1, its subgroups are level 2, and so on.

Example:

A requestor's approval chain has 4 levels:

• Level 2 approver manages a group at level 4.
• Level 3 approver manages a group at level 2.
• Level 4 approver manages a group at level 1.

If the level is set to 4, once level 2 approves, the chain has reached the 4th-level group. The request stops and moves to the next step.

If the level is set to 3, after level 2 approves, the chain has not yet reached the 3rd-level group, so it continues to level 3. Once level 3 approves, the chain reaches the 2nd-level group, exceeding the specified level, and the request ends, moving to the next step.

Multi-Level Approval Until Specified Position

Enable this option and enter one or more position names, separated by commas (,) or semicolons (;). Multiple positions are treated as alternatives. Once a request is approved by an approver holding any of the specified positions, the current step ends.

Example:

A requestor's approval chain has 4 levels:

• Level 2 approver holds the position Supervisor.
• Level 3 approver holds the position Director.

If the specified positions are "Supervisor, Director", the request stops after level 2 (Supervisor) approves, ending the current step and moving to the next.

15.3.5 Workflow Fault Tolerance

During workflow execution, the following situations may prevent a step from completing:

1. The requestor has no superior.

2. Consecutive Approval Levels is selected, but the approval chain has fewer levels than specified.

3. Multi-Level Approval Until Specified Group Level is selected, but the chain does not reach the specified group level.

• The specified group level has no approver;
• The request flows to the end of the approval chain without reaching or exceeding the specified group level.

4. Multi-Level Approval Until Specified Position is selected, but:

• None of the approvers in the chain have an assigned position;
• The assigned positions do not match the specified positions;
• There are approvers with matching positions, but the approval condition "All approvers must approve" is not selected, and none of the eligible approvers have approved.

When configuring a workflow step, you can set fault tolerance for scenarios where the step cannot complete.