We recently updated our approval workflow using a custom Groovy script in Application Composer for our procure-to-pay process. The workflow was functioning perfectly until last week when we deployed changes to handle multi-level approvals based on PO amounts.
Now purchase orders are getting stuck at the manager approval level and not routing to directors for amounts over $50K. The Groovy script should evaluate the PO amount and route accordingly, but it seems to stop after the first approval.
The workflow shows as “Pending” in the system but no notifications are being sent to directors. We’ve checked the Application Composer configuration and the approval groups are correctly defined. Has anyone encountered similar issues with conditional routing logic in Groovy workflows?
This sounds like you’re missing the approval completion callback. In OFC 23c, when using Groovy for conditional routing, you need to ensure the current approval is marked complete before routing to the next approver. Try adding context.completeApproval() before your conditional logic. Also, verify that your script has proper error handling - silent failures in Groovy scripts are common and won’t show up in the standard workflow logs.
Check your Application Composer workflow definition. When you’re using conditional routing with Groovy, you need to ensure the approval chain is properly configured in the workflow canvas itself, not just in the script. The script logic looks correct but the workflow definition might not have the director level properly connected as a subsequent approval node. Navigate to Setup and Maintenance > Application Composer > your workflow and verify the approval hierarchy visually.
I’d recommend adding logging statements to your Groovy script to debug the execution flow. Use context.logInfo() to track when the script enters each conditional block. Also check if the POAmount attribute is being retrieved correctly - sometimes attribute names are case-sensitive or the context might not have the value populated at the time your script executes.
I’ve seen this exact behavior before. The issue is likely that your Groovy script isn’t properly completing the approval action before trying to route to the next level. You need to explicitly call the approval completion method. Also check if your DIRECTOR_ROLE has the proper assignment in the approval group hierarchy.
Thanks for the suggestions. I checked the workflow canvas and the director approval node is connected. However, I’m noticing in the audit logs that the script execution completes but doesn’t trigger the next step. Could this be a timing issue where the script finishes before the approval state is properly committed?
I’ve debugged similar workflow issues in OFC 23c and the problem is typically in how you’re handling the approval routing logic. Let me address all three aspects systematically:
Groovy Script Debugging:
Your script has a critical issue - it’s setting the approver but not properly handling the approval completion and transition. You need to restructure it like this:
Application Composer Configuration:
In Application Composer, verify your approval group hierarchy includes DIRECTOR_ROLE as a valid subsequent approver. Go to Setup and Maintenance > Application Composer > Procurement > Purchase Orders > Approval Groups. Ensure the director approval group is configured with proper member assignment and that it’s enabled for the specific business unit you’re testing with. The workflow canvas should show a clear path from manager approval to director approval with your Groovy script as the routing condition.
Workflow Approval Logic:
The workflow engine in OFC 23c requires explicit state transitions. Your original script was attempting to set the next approver while the current approval was still in pending state, causing the routing to fail silently. The correct pattern is: complete current approval → evaluate conditions → route to next approver. Additionally, make sure your workflow has proper exception handling configured - if the director role is not found or has no members, the workflow should have a fallback path defined.
Test this by creating a test PO with an amount just over $50K and monitor the workflow using the BPM Worklist application. You should see clear transitions in the audit trail. If issues persist, check the diagnostic logs in Enterprise Manager for any Java exceptions that might not be surfacing in the Application Composer interface.