Sanae BEKKAR – My Blog –

SaaS, BPM topic

In Oracle Fusion apps , it’s crucial to understand how workflows like approvals are routed. This is typically influenced by job level, supervisory hierarchy, and position hierarchy , each playing a distinct role. Let’s explore how these differ and when to use which.

Oracle Cloud offers a highly flexible and configurable approval routing system to meet the dynamic needs of enterprise workflows. In addition to job level, supervisory, position hierarchy, and approval groups, there are more granular options like role-based approval and named user approval.

Here’s a comprehensive guide to all six types of approval routing available in Oracle Cloud.

1. Job Level: Functional Equivalence Across Roles

Job level refers to the rank or classification of an employee within the organization based on responsibilities, authority, or compensation level.

Example:
If Mary submits an approval, it goes to Pat. Once Pat approves, the workflow could skip John entirely and move directly to Anita , because John and Pat share the same job level. This skipping mechanism can’t be achieved through supervisory hierarchy alone.

This is the benefit of job level-based configuration , it provides flexibility to define routing rules based on ranges (e.g., invoice amounts) and equivalence, rather than rigid reporting lines.

Approvals are routed based on job levels defined in the HCM module.

Key Benefit:
If two people have the same job level, one of them can be skipped in the approval chain , making the process efficient and flexible.

Best for: Organizations needing dynamic approval logic based on job seniority.

2. Supervisory Hierarchy: The Traditional Line Manager Chain

Supervisory hierarchy refers to the traditional reporting structure « who reports to whom ».

Example:
If Mary’s manager is Pat, any action or approval would naturally route up to Pat, and then continue upwards through the line manager chain. This follows a strict person-to-person reporting model, making it straightforward but less flexible.

This follows the manager-subordinate reporting line defined in the system.

Best for: Traditional organizations with rigid reporting structures.

3. Position Hierarchy: Role-Based, Not Person-Based

Position hierarchy works differently , it evaluates positions in a pre-defined tree, not actual employees or reporting lines.

Example:
Mary submits an approval. Her position is “Consultant.” If KC holds a “Manager” position and Pat a “Senior Manager,” then the system routes the approval based on position levels, not the person Mary reports to.

Even if Mary’s line manager (Pat) is defined, the approval still flows based on the position tree , from Consultant → Manager → Senior Manager, skipping the individual-based hierarchy.

Based on a pre-defined position tree, not the reporting line. Approval routes to the next position up the hierarchy, not necessarily the direct manager.

Best for: Role-centric structures, especially in companies using Human Capital Management (HCM).

Important Note:
Position hierarchy only functions when you’re using Human Capital Management. In contrast, job level and supervisory hierarchies can operate even outside the HCM module.

Like mentioned before , in Oracle Cloud routing approvals isn’t limited to job levels, line managers, or position hierarchies. For more flexible, business-specific needs, Approval Groups offer an ideal solution.

Let’s dive into what Approval Groups are and the different routing options they support: Serial, Parallel, and Voting.

4. Approval Group

An Approval Group in Oracle Cloud lets you define specific users who are authorized to approve a transaction regardless of job level, position, or line management.

Use Case:
Suppose a business doesn’t want to follow organizational hierarchies. Instead, they want a specific group of individuals  to approve a transaction, no matter who initiates it. Approval Groups are perfect in such scenarios.

An approval group can consist of specific users and can follow:

• Serial: One approver after another.
• Parallel – First Responder: Any one of the users approves, and the transaction is completed.
• Parallel – All Must Approve: Everyone in the group must approve.

 Best for: Custom workflows where hierarchy doesn’t matter but specific people must approve.

4.1 Serial vs Parallel Approvals

In Serial mode, approvals happen sequentially , one after another.

Example:

1. First, it goes to Mary.
2. Once Mary approves, it moves to Pat.
3. Only after both have approved (in order), the transaction is processed.

This mode ensures strict order and control in the approval process.

In Parallel mode, approval requests are sent simultaneously to all users in the group.

You have two sub-options here:

First Responder Wins

• As soon as any one user (e.g., Mary or Pat) approves, the transaction is considered approved.
• This is useful when speed is a priority and you don’t need unanimous approval.

All Must Approve

• The transaction is approved only if all users in the group approve it.
• This is ideal for high-risk or high-value transactions requiring consensus.

4.2 Voting-Based Approval

When dealing with larger approval groups, serial or full parallel approval may not be practical. This is where Voting comes in.

Voting allows a transaction to be approved based on a defined approval threshold, such as a percentage or a specific number of users.

Example:
If you have an approval group of 10 users and set the threshold to 70%, the transaction will be approved as soon as 7 users approve it, regardless of the order.

Benefits:

• More flexible than requiring all 10 users.
• Faster than waiting for all responses.
• More controlled than allowing any single user to approve.

Available only in Approval Groups, voting allows you to specify a percentage of users that must approve for the transaction to be accepted.

Example:
In a group of 10 users, you can define that 70% must approve. That means once 7 users approve, the transaction is accepted, and you don’t have to wait for all 10.

Best for: Large approval groups where you want balanced consensus and speed.

5. Role-Based Approval

In this model, approval is routed to users assigned a particular role.

• This is a parallel-based approval model.
• Roles must be pre-assigned to users for the routing to function.
• You can’t define a sequence, so all approvers with the role will receive the request at the same time.

Best for: Organizations that want to route based on responsibilities rather than individuals.

6. Named User Approval

Here, you directly specify the user by name (e.g., HR Manager).

• This can be useful when a particular person must always approve certain transactions.
• Often used in use cases like document validation, bank account approvals, etc.

Best for: Explicit accountability in approval routing.

That was about the 6 type of approval routing in Oracle Cloud . When working with position hierarchies in Oracle Cloud, one of the frequent questions is:
How do we handle multiple users in the same position across different departments? This situation creates what some refer to as « side walls » meaning there could be similar roles or positions (e.g., « Manager ») existing in parallel departmental structures (Finance, HR, Sales).

So, how does Oracle Cloud ensure the approval routing targets the right individual or department? So Oracle Cloud doesn’t enforce a rigid structure in this case. Instead, it offers flexibility through conditional logic and position hierarchy design, which must be tailored to the customer’s business structure.

Important. To configure routing effectively, you need to:

1. Define the position hierarchy tree based on business needs, possibly breaking it down by department or function.
2. Specify conditions that ensure routing is restricted to the right department or business unit.
3. Apply rules that reflect how approval should flow within that branch of the hierarchy.

Example Use Case

Imagine two managers both hold the position “Regional Manager,” but one is in Sales and the other in Marketing.

By default, both roles could appear equal in a hierarchy. However, with well-defined routing conditions, Oracle Cloud can ensure that approvals from Sales transactions only go to the Sales Regional Manager.

That’s why it’s essential to:

• Understand the customer’s business structure,
• Design the hierarchy accordingly, and
• Set up routing conditions that prevent cross-functional overlap or misrouting.

When building complex invoice approval flows for example in Oracle Cloud, capturing the business requirements accurately is the first and most crucial step. To simplify the configuration process , especially when using spreadsheets or BPM UI , it’s highly recommended to document your rules in a structured tabular format.

Real-World Scenario

Let’s consider this logic:

• If the invoice matches a PO and the amount is under 5000 USD, the transaction should be automatically approved. No need to invoke cost center or business unit routing , that logic can be skipped.
• If the invoice is unmatched or lacks a requester, the system should auto-reject.
• If the invoice amount is greater than 5000 USD, route based on business unit and cost center.

To capture and translate these rules into a format that Oracle Cloud can understand and apply effectively, we recommend the following format.

Unmatched invoices with no requester (details missing)

Auto Reject

Invoice is not matched to PO; requester details are missing

Invoices > $5000 based on BU and Cost Center

Group Serial

If BU is US1 & CC = 200 → Group A If BU is US1 & CC = 300 → Group B

PO-matched invoices < $5000

Auto Approve

Invoice is matched to PO AND amount < $5000

How to Use This Table

• Column 1: Clearly describe the business logic in simple language.
• Column 2: Indicate the routing type Oracle Cloud should use (e.g., Supervisory, Approval Group, Auto Approve).
• Column 3: List the actual rule conditions that must be met for that route to trigger.

This structure makes it significantly easier to configure approvals in Oracle using:

• Spreadsheets (for upload in FSM)
• BPM Worklist UI (manual configuration)

You can further expand this table to include:

• Exception handling logic
• Special account codes (e.g., asset clearing)
• Voting thresholds (for approval groups)

This wraps up the overview of approval routing fundamentals in Oracle Cloud , I’ll share soon some practical examples in upcoming post.

Thanks for reading !