Tips and Tricks for Configuring Oracle Cloud HCM Approvals

How do Oracle Cloud HCM workflow and approvals work? How do I configure that? How do I smoke test and then how the heck do I migrate these so that I don’t have to build them manually again? If you’ve ever asked yourself one of these questions, then hopefully this blog on Tips and Tricks for HCM workflow will help you on your journey.

Best Practices when gathering Requirements

• Keep it simple
• Don’t use users! Route to a role, AOR, approval group, or management hierarchy
• If it can’t be configured via BPM, then the rule is too complex

GETTING STARTED

There are two main configuration areas

1. Transaction console

1. • Quick and excellent for very basic workflow configuration
   • One-stop-shop for configuring, testing, and monitoring workflow
   • Very user-friendly, functional area. Best place to configure workflow nodes after the condition
2. BPM
   • A more robust and less functional configuration area with much more power, options, and reliability
   • It’s required to use to configure complex conditional statements such as role-based clauses

The steps I would take to configure a new, complex workflow are:

1. Prepare test data so that you can login as various initiators (admin, manager, manager+1)
2. Start in the BPM area to configure
   1. Setup and Maintenance > Manage Approval Groups > Task Configuration > Search
3. Enter the BPM approval configuration area
4. Start a new condition and toggle advanced mode on
   1. Rule > Properties > Advanced Mode
5. Input one of your conditional statements after the List is a List and Task is a Task objects
6. Go back into the transaction console and add distinct approval paths for the two different conditions
7. Submit a test transaction using your test data logins to verify that this condition is successfully met
8. Go back into BPM and build out more conditions, one at a time (role based, country, worker type, etc.)
9. Retest the complex conditions with test data
10. Build out the workflow node paths in the Transaction Console and test all of them

There you have it.  That’s how you can configure complex conditions in your approval rules.  In my experience, it can be a large headache to try to configure conditions only via transaction console, with many rules failing or not routing with logic and reason.  It’s worth the pain of learning how to use BPM to make the approval configuration process to be more seamless.

MISCELLANEOUS TIPS

• If the only result of a workflow is to send one or more FYI notifications, make sure to include an auto-approval node first after the condition block. Without this auto-approval node, the FYIs will fail.
• Approvals can be easily scoped and migrated using the SOA composer tool (Whitepaper)
• Workflow can be copied within the BPM area and pasted into another action type—this is very useful if the configuration between transactions is similar.
• Job-level based management hierarchy can only utilize minimum job level, so when designing the jobs make sure that the CEO is the highest job level.