Leveraging Intelligent Recommendations for Operational Transformation. AMS Partners click HERE | EMEA/APJ Partners click HERE |
04/02/2024 11:04 PM - edited 04/03/2024 01:26 PM
Hi All,
We have a 2 level appproval workflow configured for an application where in the first level approval is setup for SOD Risk Owners if there are any SOD violations detected and the second level is setup for Ent Owner if the entitlement is soxcritical - Medium, High, Very High otherwise it gets autoapproved.
Issue: A request is submitted for the entitlements that have SOD violations. The request for approval is sent to first level approval to the owners. Once the request is approved at this stage, the if else block to check Entitlement soxcritical condition is failing and the entitlements are getting auto-approved. Below is the workflow configured
Request got completed after Level 1 approval, if else block EntSoxCheck condition is failed. The expected behaviour is that request approval must go to second level EntOwner approval as the entitlements are Soxcritical High
[This message has been edited by moderator to mask sensitive info]
Solved! Go to Solution.
04/03/2024 03:30 AM - edited 04/03/2024 03:30 AM
can you confirm insteadOf entimt.soxcritical>3 , try
1. entitlment.soxcritical==3
2. entitlment.soxcritical=='3'
04/03/2024 08:41 AM
I've tried both the ways, it still doesn't go to second level approval. Also FYI, If the SODCheck & SODRiskOwner Approval blocks are removed in the workflow, entimt.soxcritical>3 condition is working as expected.
04/03/2024 10:50 AM
entimt.soxcritical>3 if else block chaining may be issue , pointing reject and owner block accept scenario both tagging same if block .
what is error in logs?
04/03/2024 11:27 AM - edited 04/03/2024 12:30 PM
@Raghu It's going to EntSoxCritical If-else block but the condition is always failing. If I point both true and false scenarios to EntOwner Approval block, it goes to second level approval.
Note: Updated EntSoxCheck condition to entitlement.soxcritical=='5' for testing purpose
The same condititon (entimt.soxcritical>3) is working fine when SOD blocks are removed.
04/03/2024 08:31 PM
It seems you are using serial workflow where entitlement object is not exposed. please use parallel workflow
04/04/2024 07:27 AM
04/04/2024 10:17 PM
You can use Parallel workflow with custom assignment block
select u.userkey
from request_exceptions RE INNER JOIN riskowners RO ON RO.RISKID=RE.EXCEPTIONKEY
INNER JOIN Users U ON U.userkey=RO.OWNERUSERKEY
where RE.REQUESTKEY=${ARSREQUEST.id}
04/17/2024 01:45 PM
@rushikeshvartak Yes, looks like the custom assignment block with a custom query is working as expected. However, I still don't understand the problem with SOD blocks.