The CA Process Automation (PAM) Reset Operator can be an extremely useful tool for handling a number of Process design cases. As noted in the Content Designer Reference, the Reset Operator can be used to reset selected Operators (typically an operator that caused an exception) to their initial states. These reset operators act as if they had not been executed and the process continues.
However, because of the way that PAM evaluates execution paths a Reset can cause some very unintuitive behavior. Specifically when the Reset Operator is executed, all exit paths for previously executed Operators that have not been reset are reevaluated.
Normally this goes unnoticed because when the path is reevaluated, it typically calculates the same exit port as before, and if the Operator on that path has already been executed, and not reset, then that next Operator is not executed, and that is the end of it. However, in the case where an executed Operator has a custom exit port, and the condition being tested involves a variable that has changed between when the Operator was first executed, and the reset, a different path may be taken and previously unexecuted Operators may start running leading to what the user may see as unexpected behavior.
For many reasons, not the least of which is backwards compatibility this behavior can't be changed.
Best practice to assure that the same path is taken when the exit ports are re-evaluated after a reset is to have the exit port test a variable from the Operator dataset. While any Dataset can be referenced and modified by other Operators in a Process, unless the content developer goes out of their way to do so, Operator Datasets are typically not modified after the Operator has been executed.