回退（Rollback WorkItem）
回退是工作流参与者对自己“待办任务”（实际是对工作项）的一种操作，即参与者主动回退待办任务列表中的任务到已经执行过的人工节点。
为什么要回退？
参与者接受任务后，发现不应由自己办理此任务或以前的执行者办理有错误等情况后，需要将此接受的任务回退给以前某个节点的执行者重新办理。
回退模式
回退的情况实际上是非常复杂的，其中包括了参与者的重新选择以及回退的条件判断等等。这里先列出常见的回退模式（其实也是我们支持的模式）。
串行
这种情况最为简单，后续节点可以回退到前续任意人工节点。回退后，节点重走。
分支
这种情况也相对简单，实际执行的分支上的节点可以回退到前续任意人工节点（不区分主支和分支）。同样，主支上的节点也可以回退到任意实际执行的分支上的节点。
可能的问题：多次回退后的回退节点选择。例如：第一次流程经过节点2、节点3到达节点5，节点5可以回退到节点1、节点2和节点3的任意一个，此时节点5回退到节点1，节点1重走，这一次流程改为经过节点4到达节点5，节点5回退时如何选择回退节点？此时的策略是以最近实际执行的分支为准，即节点5只允许回退到节点4和节点1，不允许回退到节点2和节点3。（抹去记忆）
并发
对于并发的情况，分支节点只允许在分支的节点间回退。
同理，主支节点也只允许在主支的节点间回退。
多实例汇聚
在这种情况下，节点5会产生2个实例，实际相当于继续并发。节点5根据具体哪个节点触发的它而产生回退节点。同时不允许回退到节点1以及前续的节点去。
子流程
支持子流程到父流程的回退，也支持父流程到子流程节点的回退。需要注意的是子流程节点有可能产生多个子流程实例，在这种情况下不支持父子流程之间的相互回退。
回退节点的参与者选择
默认策略是由原先节点的实际参与者重新处理，比如节点2回退到节点1，则节点1的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。
在节点任务竞争参与的情况下，提供另一种策略，即让人员重新竞争。
回退的条件判断
对于多人（或者多部门，用户）参与的工作项，提供不同的回退策略
任意人回退即回退，剩余工作项手工终止
最后提交人回退才回退
流程定义期定义该策略。
另外流程定义时提供节点可回退列表，由用户在定义期对可回退的节点进行限制。
关于业务补偿
业务补偿是一个很重要的概念，在回退的情况下需要相应的回退部分业务操作。这里由引擎提供统一的接口，返回回退路径，由客户自定义代码进行匹配处理。
关于实现
很多工作流引擎通过流程定义时绘出回退线来显式的支持回退，这种实现在业务复杂的情况下会造成流程图的异常烦琐，但是比较清晰，实现比较容易。隐式实现相比而言优点更多。