Implementing Workflows, Approvals, and Notifications

Key points the exam tests

• Escalate routes the task up the management chain when the current approver cannot act (e.g., overdue tasks). Not the same as Reassign.
• Bypass Approvals skips all routing and immediately commits the transaction. Useful for testing but should be disabled in production.
• Vacation Period in BPM Worklist Preferences allows setting date range + delegate. All tasks are automatically rerouted during that period.
• Approval Rules are IF-THEN statements: IF conditions check transaction attributes; THEN statements define routing (manager levels, groups, auto-approve).
• Alerts Composer Resource Alerts query REST API resources on a schedule with filter conditions — perfect for expiry-based notifications like passports.
• Vacation Period (BPM Worklist Preferences) lets a user set a date range and a delegate; all tasks arriving in that window are automatically redirected to the delegate.
• Delegation lets someone act on your behalf without giving up ownership of the task (useful for short absences); Reassignment permanently hands off the task to someone else.
• Approval Rules use IF-THEN logic: conditions evaluate transaction attributes (like salary increase %), and THEN statements define the routing outcome.
• Bypass Approvals skips all routing and commits immediately. Useful to speed up testing, but in production it removes the governance/approval control that compliance typically requires.
• An Approval Group is a named collection of users who can act interchangeably on tasks routed to the group — any single member's action satisfies the approval.
• Resource Alerts run on a schedule, query a REST resource, apply filter conditions, and notify recipients automatically — commonly used for expiry-based reminders.
• Report-Based Notifications use a BI Publisher template to format the notification body with report data — useful for polished, structured communications beyond plain-text alerts.
• Approval Rules define routing logic that can chain multiple approval stages — manager levels, then specific roles or groups — in a defined sequence.
• Request Information sends the task back to the requester (or another party) for clarification without approving or rejecting it outright.
• Without an escalation or expiration rule, a task simply stays outstanding in the assigned approver's worklist — this is why escalation policies are important for time-sensitive transactions.
• Approval Rule conditions can evaluate transaction attributes such as Legal Employer or country, allowing different routing logic per region within the same ruleset.
• Reassign transfers the task (and accountability for the decision) to a different user entirely, unlike Delegate which retains the original owner.
• Approval Rule misconfiguration can send real transactions to the wrong approvers or skip governance entirely, so testing routing logic before production changes is a best practice.
• Resource Alerts can be scheduled at defined frequencies (e.g., weekly) to query and summarize matching records, rather than firing on every individual event.
• 'Publish to Production' is a Sandbox/Extensibility concept, not a BPM Worklist task action. Standard worklist actions include Approve, Reject, Request Info, Reassign, Escalate, and Delegate.
• Approval Rules can route to auto-approval as a valid THEN outcome when conditions are met — commonly used for low-risk, low-value transactions to reduce approver workload.
• BPM Worklist is the unified interface where all pending approval tasks — regardless of transaction type — appear for the approver to action.
• Not every HR transaction needs governance-level approval — low-risk self-service changes are often configured to commit directly, reserving approval routing for higher-impact transactions.
• Activities are the individual building blocks of a workflow — each one represents a distinct step, such as routing an approval task or sending a notification.
• Human Task Activities represent steps requiring a person to act (approve/reject/review) — one of the most common activity types alongside notification and system activities.
• Transitions define the paths connecting activities — determining which activity executes next based on the outcome of the current one.
• Conditions attached to Transitions let the workflow branch dynamically — for example, routing differently based on salary amount, department, or country.
• Transaction Console is purpose-built for monitoring in-flight workflow/approval instances — showing status, current step, and time-in-stage for troubleshooting.
• A stalled step often indicates an unavailable or misconfigured approver with no escalation rule — Transaction Console surfaces exactly where in the chain the transaction is stuck.
• Transaction Console includes simulation/validation capability, letting implementers verify how a transaction would route under current rules before changes go live.
• Oracle BPM is the engine underneath HCM's workflow/approval processing — Approval Rules and Activities are ultimately executed as BPM process instances.
• Escalate and Delegate (along with Approve, Reject, Reassign, Request Info) are standard BPM Worklist task actions. 'Publish to Production' and 'Compress Sandbox' are not real Worklist actions.