The problem you're encountering can come from a number of different configuration missteps. The removed flow in the error is on the pxFlow page of your work object. That is essentially the work object's call stack, so the error says the entire flow referenced by the assignment is not in the call stack. In reality this may be because it's been removed (you've finished work in the subflow, hit an end shape and unwound) or because the work object isn't aware of the subflow in the assignment yet. Because there is no common source of the error, it's hard to explain exactly what you need to do to identify/fix the problem. A couple of tips for debugging are to look at the item and the assignment to figure out which is older than expected. The history of the work object can often help with this because you can see has the assignment been processed already or if the pxFlow of the work object reflects an earlier state than the assignment and history. Once you know which is incorrect you should look for things that could cause problems. For instance, if you have a manual commit without proper error trapping and something unexpected occurs in the database, you'll roll back, losing the delete of the assignment being processed, but continue forward in the flow processing, resulting in a pxFlow for a later stage of flow processing. Likewise, if you copy off the work object to another clipboard page and then do a deferred save of that, at commit time, the copy could overwrite the updated version on pyWorkPage, so your pxFlow page in the database will not reflect the latest assignment.