往往，对于工作流的强制同步(Forced Synchronous)处理模式，可以仅仅当做一段SQL代码来理解，事实上它也仅在一个SESSION内执行结束。对于某些逻辑处理，工作流图形化的设计方式非常容易理解，并且容易维护和扩展，多数情况下比PL/SQL代码更容易维护——我们的代码质量总是太差，除了程序员没人看得懂。

相对于普通的工作流(同步、异步）来说，它主要的区别就是响应及时。它不会保存任何工作流信息，这也就意味着无法在监控页面查询到工作流状态。工作流会将所有运行状态和变量存在工作流相关的表中，当使用强制同步处理模式时，所有变量仅在内存里保存（实际上是一些RECORD类型的变量），当SESSION结束自动清除。

额外的一些限制有：

  1. 不能使用通知活动。
  2. 仅存在于单个Session中，不能Commit。
  3. 无法使用错误处理流程。
  4. On Revisit仅允许LOOP属性。
  5. 不能使用主从活动。
  6. 不能并行处理。
  7. 不能使用各类延迟处理的活动，比如Defer、Wait。
  8. 不能使用工作流后台处理引擎。
  9. 不能记录到工作流表。
  10. 仅允许少量的API调用。

(更详细的说明，可以参考工作流API文档)

使用强制同步处理模式的方法是设置ITEM_TYPE为#SYNC，或者wf_engine.eng_synch。如果在不启动DEBUG跟踪的前提下试图诊断工作流，则可以通过指定一个唯一的ITEM_TYPE来进行操作，即返回到普通的同步模式。

对于复杂权限的判断、帐户的生成，或其他存在多个逻辑判断的情形，使用工作流比在代码中控制要清晰很多，和设计文档中的流程图几乎一致。