Summarized the conversation with GCS support engineer.

Essence of the issue:

With the stage/step configuration, if there are more than two assignments created at the same time by concurrent steps under the same stage, only the last assignment is considered by the "look for an assignment to perform" feature and if the last assignment is not routed to the current operator, the flow will display the confirm harness instead of opening one of the other assignments which is routed to the current operator.

Attempted work around which has been rejected by the client:

Changing the order of the steps, so the step which needs to be performed by the current operator comes under the other concurrent steps.

This work around does work, however the order of steps has its meaning for business users and developers has no control over changing that order.

Since there isn't any official design documents or prhelp documents which clearly states the limitation of the issues described in this SR, the client insists that "Look for an assignment to perform after add" option should work regard less the order of the step configuration.

The analysis of the current implementation suggests that there should be no technical blockers to make the "Look for an assignment after add" option work properly regardless the order of concurrent step executions. (Current implementation is using newAssignPage, which is definitely pointing to the last assignment, to determine the next assignment to perform.)

Below is the expected behavior:

Upon the entry of a stage,

1. if there is any newly created assignment which is routed to the current operator, then the assignment should be open in the perform harness.

2. if there is more than one assignment being created for the current operator, then the assignment in higher position among the sibling steps should be open.

3. Any existing assignment belongs to the stages other than the current stage should be ignored.