Oracle Fusion Technical: Reports, Data, Integrations and Extensions · Module 14 · Approvals and BPM workflow
How approvals are actually structured
Lesson 137 of 177 · 2 min
Four words, and the model underneath the rules editor. A TASK is one thing needing a decision — approve this invoice, approve this requisition. It is the unit that appears in somebody's worklist. A PARTICIPANT is who is asked, and it is resolved at RUNTIME rather than being a name in the configuration: a supervisor chain, a position hierarchy, a named role, a specific user. A RULE SET decides which participants apply, based on the transaction — amount, business unit, category. This is where the client's policy actually lives. A STAGE groups participants that resolve together, and stages run in sequence. Two stages means the second is asked only after the first is satisfied. THE MODEL UNDERNEATH: the engine resolves a LIST OF PARTICIPANTS from the rules, then routes the task to them in the shape the stage specifies. Everything in this module is either about how that list is…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Fusion Technical: Reports, Data, Integrations and Extensions, with a certificate on completion and a fourteen-day refund window.
In this module: Module 14 · Approvals and BPM workflow
- 1How approvals are actually structured
- 2Approval rules and how they are evaluated
- 3Supervisory and position hierarchies
- 4Parallel, serial and FYI participants
- 5Delegation, escalation and timeouts
- 6Notifications and what they say
- 7Testing an approval rule properly
- 8Diagnosing a stuck transaction
- 9What breaks: the approval nobody received
- 10Lab briefing · Build and break an approval chain