Fusionadvanced
Fusion Approval Management: BPM Task Configuration
Explain how Fusion configures approval workflows through BPM Worklist and Task Configuration, contrasted with AME in EBS
Approvals in Fusion run on the BPM engine, and are configured through BPM Worklist's task configuration screens. In EBS the equivalent was AME.
Fusion's BPM-based approval routing is like a mailroom with conditional sorting rules: envelopes above a certain size or value (transaction amount) automatically get routed through an extra security check (Finance Director approval) in addition to the standard delivery route (management chain), all based on pre-configured sorting criteria rather than a mailroom clerk manually deciding each time.
Key Concepts
1
Each approvable transaction has a task definition — requisitions, expense reports, absence requests,
journals — describing how it routes.
2
Three routing styles, combinable in stages.
Management chain up the supervisor hierarchy, dynamically.
"Two levels up" resolves per employee.
Position hierarchy up the position structure rather than the
person's manager.
Rule-based conditions on the transaction's attributes.3
stage 1: management chain, 2 levels
stage 2: IF amount > 500,000 THEN Finance Director4
Stages run in order, so the common path is the manager chain with extra approvers added for exceptions.
5
Rules are built in a visual editor.
IF ExpenseReport.Amount > 5000
AND ExpenseReport.Category = 'TRAVEL'
THEN approver = FinanceDirector6
No BPMN or XML for ordinary routing. BPM Composer exists for cases the rule builder cannot express, and is a
developer tool with a deployment process.
7
Compared with AME. The philosophy is the same — attribute-driven conditional routing, evaluated per
transaction. What changed is the tooling: AME needed technical rule-building even for straightforward
routing, while common Fusion scenarios are configured by a functional administrator.
8
Two things worth knowing that catch implementations out.Management chain routing depends on HR data being right. An employee with no supervisor, or a broken
hierarchy, produces an approval that cannot be routed. The transaction sits there and the cause is in HCM,
not in the approval configuration.
9
There must always be an approver. A rule set where no condition matches and no default exists leaves the
transaction unrouted. A catch-all final stage is what prevents it.
10
Debugging an approval that has not arrived. Check the transaction's approval history first — it shows
which stage it reached and who it went to. If it shows nothing, the routing failed to resolve an approver,
and that is an HR hierarchy or a rule gap rather than a BPM fault.
11
What the interviewer is probing.1. "How are approvals routed?" Probing: the model. Stalls: "A hierarchy." Moves up: rules
in BPM worklist against task attributes, choosing participants by supervisory hierarchy, position
hierarchy, job level or a named list.
12
2. "What is a participant type?" Probing: the vocabulary. Stalls: "An approver." Moves up:
single, parallel, serial or FYI — which decides whether approvals happen together, in sequence, or
are notifications only.
13
3. "What happens if no approver is found?" Probing: the failure mode. Stalls: "It approves."
Moves up: the task errors or goes to an administrator depending on configuration, which is why a
default and an error handler must be set.
14
4. "How do you test an approval change safely?" Probing: the process. Stalls: "In
production." Moves up: in a test environment with representative hierarchy data, since routing
depends on live organisational data rather than the rule alone.