Refer a Sample Approval workflow. Approval Rejection is an Alternate Stage here. Both Confirm and Approval Rejection are stages marked to resolve upon completion.
A case is created and rejected during approval, so the control goes to alternate stage. The case is resolved as expected. However, the case life-cycle displayed in the Case Header hints of a pending action. Look closely, where Approval Rejection stage resembles the chevron with automatic transition to the next step - which quite isn't the case.
Anyone with the same dilemma ?
I think: Ideally the Confirm stage should have been grayed out (or even hidden) to suggest that Approval Rejection is (indeed) the final stage in case life cycle.
I have recreated the same scenario in PRPC v7.2.2. In this version, the next step 'Confirm' is grayed out in case of Rejection as mentioned by you. But in PRPC v7.2.1, it seems to be enabled. I think its an issue in 7.2.1. Attached screenshots for reference.
Hi PranathiC, the information you've shared is helpful. Thank you.
My query had two folds. The first one has been resolved as PRPC 722 seems to have introduced an enhancement to gray-out stage(s) that are not part of the case life cycle anymore.
The second one is more around the alternate-stage formatting because, it's current representation (also in v722) doesn't seem to be fit or inline with the underlying principle understanding. A Blue-colored, open-ended-chevron shape (in my opinion) indicates an in-flight case. By looking at the information in question (pyDisplayStages), end-users are confused whether the case has actually completed its life-cycle or not - despite of the fact that case is already resolved.
Having received a confirmation that the problem statement is inherent to the latest PRPC version (722), a feedback item (FDBK-19867) has been requested. Meanwhile, a local fix has been identified for folks who are interested in enhancing the way PRPC depicts the current stage of a case in it's Life Cycle.
The issue with color coding for an Alternate Stage (marked to resolve) can be fixed: Override D_CaseStages which is available rule and in the post load processing set additional property to reflect the completed status of the Alternate stage based on pyStageStatus and pyStageName.
Also, to prevent from displaying the final stage in happy path once the case is resolved at an alternate stage: Modify the available section pyStageName and tweak the visibility condition of Dynamic layout -3.