Start Upon stage entry priority in a Case Type
Hello dear community,
I am working on Pega 7.31 and I have some troubles to configure steps order execution in a stage.
The scenario is : When I complete my stage 1, I go to stage 2.
In stage 2, there are 4 steps : A - B - C -D
In my application, when the user arrives to Stage 2, he should directly arrive on step A. However, he has the possibility to skip temporaly this part by going back on the review of the Case to go to Step B and complete the rest of the Stage (with Step A still opened = not completed).
To do that, I put steps A & B to "Start Upon stage entry" in my case type, otherwise I could not go out of Step A (without completing it) and go on Step B.
But the issue I meet is when I complete Stage 1,and I automatically move to stage 2, it's the Step B that's automatically open first and not Step A. For my customer needs, I have to let the order A - B - C - D displayed.
So do you have any idea why it's the Step B that's opening directly and not A ?
Thank you.
Best regards, Kévin.
Pegasystems Inc.
AU
I am going off memory a bit here. I think this is because Pega does the work to create the assignment for A (because it is the first configured in the stage), and then subsequently does the work to create the assignment for B.
Once Pega realizes there is no more steps to start on stage entry, the case has reached an idle point. Once idle, if the most recently created assignment (B) is performable by the current user, it makes sense that B is the one shown given the clipboard already has B's assignment state in place.
Is it appropriate to swap A and B around? That is, have Stage 2 configured as B - A - C - D? This would have A in place at the idle point and be shown to the user.
Depending on what you need to happen once either A or B are performed (for example, in both cases they should go to C), you may want to investigate a Split Join subflow in the Flow rule, for which you may need to use Dev Studio. This is another technique for starting multiple flows at the same time, and having some rules around how to proceed once either (or both) are completed.
There is also the option to add A and B as Parallel Processes to your stage, but that's not much different to what you already have.
In all of the above though, I think the principle of "the last performable assignment created is the one shown" still likely takes effect.
I am going off memory a bit here. I think this is because Pega does the work to create the assignment for A (because it is the first configured in the stage), and then subsequently does the work to create the assignment for B.
Once Pega realizes there is no more steps to start on stage entry, the case has reached an idle point. Once idle, if the most recently created assignment (B) is performable by the current user, it makes sense that B is the one shown given the clipboard already has B's assignment state in place.
Is it appropriate to swap A and B around? That is, have Stage 2 configured as B - A - C - D? This would have A in place at the idle point and be shown to the user.
Depending on what you need to happen once either A or B are performed (for example, in both cases they should go to C), you may want to investigate a Split Join subflow in the Flow rule, for which you may need to use Dev Studio. This is another technique for starting multiple flows at the same time, and having some rules around how to proceed once either (or both) are completed.
There is also the option to add A and B as Parallel Processes to your stage, but that's not much different to what you already have.
In all of the above though, I think the principle of "the last performable assignment created is the one shown" still likely takes effect.
Post back your findings - I have one other idea in mind too if none of the above work for you.
Sopra Steria Group
FR
Thank you for your response, I understand a bit much more how does the process of creation & display works, the way you explained seems logical.
Actually I can't really swap both A and B.
It's like, in my stage A - B - C - D, A should not prevent the completions of B-C-D (C - D must use the status "Starts after previous step" since they can be opened only if B is done).
So if I swap to B - A - C - D, indeed A will appear first, but if my user wants to complete it later, then C & D will be blocked because of the status, and much more than that : it's more on a logical point of view for my life-cycle, that B must be completed before C-D (that's why they must unaccessible until B is completed) I think when you explained the Split Join subflow, you thought that both A and B could lead to C right ? Actually, It is more like only B is leading to C. So I'm not sure Split Join could be a solution.
I think one solution should be to change the principle of "the last performable assignment created is the one shown" to "the first performable assignment created is the one shown", but I'm afraid this is a complex and asks a lot of effort to just find how it works. Anyway, I still thank you for your implication. So if anyone else reading this message has an idea, feel free to leave a comment. Best regards, Kévin.
Pegasystems Inc.
AU
If I understand it correctly, B-C-D must be completed in sequence, whilst A should be created at the same time as B.
Would the below work?
- Implement a distinct Flow rule which includes the B-C-D sequence, let's call it X.
- Configure your Stage to consist of just X then A, both of which start on stage entry.
- When the Stage starts, this will start X, which in turn starts B and pauses at the assignment in B.
- Then A will start, pausing at A.
- Since A is the last assignment created, A will be the assignment presented to the user.
If the user elects to complete A, nothing in the configuration directs the user to C; B must still be performed to get to C.
If the user elects to complete B, they transition onto C, and then D, independent of what is (or is not) done with A.
Sopra Steria Group
FR
Technically you are right, this would be a great workaround for that ! The blocking point is more from our customer's needs. He wants a case life cycle to be like
| Stage 1 | Stage 2 | Stage 3 | Other stages |
| 1.1 | 2.1 | A | . |
| 1.2 | 2.2 | B | . |
| 1.3 | 2.3 | C | . |
| 1.4 | 2.4 | D | . |
To have a clear view of the progression of the stage when he is on the review of the case. But I think with your solution, it would look like that no ?
| Stage 1 | Stage 2 | Stage 3 | Other stages |
| 1.1 | 2.1 | X | . |
| 1.2 | 2.2 | A | . |
| 1.3 | 2.3 | . | |
| 1.4 | 2.4 | . |
This is the main difficulty for our team, keeping the case life cycle as it is ...
Technically you are right, this would be a great workaround for that ! The blocking point is more from our customer's needs. He wants a case life cycle to be like
| Stage 1 | Stage 2 | Stage 3 | Other stages |
| 1.1 | 2.1 | A | . |
| 1.2 | 2.2 | B | . |
| 1.3 | 2.3 | C | . |
| 1.4 | 2.4 | D | . |
To have a clear view of the progression of the stage when he is on the review of the case. But I think with your solution, it would look like that no ?
| Stage 1 | Stage 2 | Stage 3 | Other stages |
| 1.1 | 2.1 | X | . |
| 1.2 | 2.2 | A | . |
| 1.3 | 2.3 | . | |
| 1.4 | 2.4 | . |
This is the main difficulty for our team, keeping the case life cycle as it is ...
Still, thank you for your suggestions !
Best regards, Kévin.
Pegasystems Inc.
AU
So I think the below (from the Case Type ruleform) would get you at least the B-C-D-A outcome?
You may be able to achieve A-B-C-D by having the first assignment in B be a time-based Wait shape, which when the timer lapses then moves onto the original assignment in B. Then set the timer to be short (e.g. 5 seconds). This way once the case has finished starting the processes for Stage 2, the only assignment created during that interaction that is performable by the user is A, so hopefully it is the one shown. Without having tried it, there is a chance that if the last assignment created (B) is not performable, then the case goes into the Review harness even if A is performable by the current user. You'd have to try that out.
Within 30 seconds of the Wait shape lapsing (the frequency of the SLA agent which actions the Wait shapes) and the case not being locked (which it will be whilst A is being performed), B will have been moved onto its intended assignment. However there is a 30 second window between when the case gets unlocked from performing A and the creation of the intended assignment in B.
So I think the below (from the Case Type ruleform) would get you at least the B-C-D-A outcome?
You may be able to achieve A-B-C-D by having the first assignment in B be a time-based Wait shape, which when the timer lapses then moves onto the original assignment in B. Then set the timer to be short (e.g. 5 seconds). This way once the case has finished starting the processes for Stage 2, the only assignment created during that interaction that is performable by the user is A, so hopefully it is the one shown. Without having tried it, there is a chance that if the last assignment created (B) is not performable, then the case goes into the Review harness even if A is performable by the current user. You'd have to try that out.
Within 30 seconds of the Wait shape lapsing (the frequency of the SLA agent which actions the Wait shapes) and the case not being locked (which it will be whilst A is being performed), B will have been moved onto its intended assignment. However there is a 30 second window between when the case gets unlocked from performing A and the creation of the intended assignment in B.
This is likely to cause confusion. The additional engineering and complexity introduced won't meet the business need.
I think you're better to go with X-A or B-C-D-A from above (both of which yield the right Case Management outcome) and challenge the customer on the value that is genuinely added by visualizing the steps as A-B-C-D. The delivery team can likely add more business value by not dwelling further on this.