在OpenERP中，工作流是管理一组“所做的事情”（与一些数据模型的记录关联）的人为现象。工作流提供了高级别的方式来组织记录要上做的事情。
具体地说，工作流是一个定向的路径，这里节点称为活动并且弧线称为流程进度。
- 活动定义了OpenERP应该处理的工作，比如改变某些记录的状态，或者发送邮件。
- Transitions 控制了活动之间工作流的处理进度
在一个工作流定义中，一个达到了条件，就会触发进度的推进，这样工作流的行为取决于用户的actions（比如点击一个按钮），变更记录，或者任意的Python代码。
Basic（基本）
使用数据文件定义一个工作流是很直截了当的：针对activities和transitions的记录工作流是与记录一起给出。例如，这里是定义在XML中简单的一系列的两个activities。
<record id="test_workflow" model="workflow"> <field name="name">test.workflow</field> <field name="osv">test.workflow.model</field> <field name="on_create">True</field> </record> <record id="activity_a" model="workflow.activity"> <field name="wkf_id" ref="test_workflow"/> <field name="flow_start">True</field> <field name="name">a</field> <field name="kind">function</field> <field name="action">print_a()</field> </record> <record id="activity_b" model="workflow.activity"> <field name="wkf_id" ref="test_workflow"/> <field name="flow_stop">True</field> <field name="name">b</field> <field name="kind">function</field> <field name="action">print_b()</field> </record> <record id="trans_a_b" model="workflow.transition"> <field name="act_from" ref="activity_a"/> <field name="act_to" ref="activity_b"/> </record>
定义的工作流关联到一个特定的模型（这个模式由模型workflow的osv属性给出）。activities或者transations内指定的方法将在这个模型上调用。
在上路的例子代码中，创建了一个调用test_workflow的工作流。其由两个activities，“a”和“b”，一个transation，从a到b，组成。
第一个activity有属性flow_start，并设置为true，这样OpenERP知道在工作流实例化后从哪里开启工作流便利。因为工作流记录的on_create设置为true，为每个新创建的记录实例化工作流（否则，要通过其他的方式实例化工作流，比如一些模块的Python代码）。
当实例化工作流时，从activity a开始。那个activity是一种函数，意味着模型test.workflow上的方法action pring_a调用（通常传递cr，uid，ids，context参数给它）。
a和b之间的transation不指定任何条件。意味着处理a后工作流实例立即从a走向b，并稍后处理activity b。
Transation(迁移)
Transation提供了一个控制结构安排工作流。当一个activity完成时，工作流引擎就试着从一个完成的activity（活动）流向下一个activity（活动）。在它们最简单的表单中（如同上面的例子），它就继续连接activities（活动）：即之前的activities（活动）处理完成就处理后面的activities（活动）。
作为一下子运行所有的activities（活动）的替换，其也可能在transitions（迁移）上等待，仅当匹配了某些条件才能通过。标准是条件，信号或者触发。它们将在下面详细讨论。
Conditions（条件）
当完成一个activity时，检查它的输出Transation决定工作流实例处理它们并到达下一个activity。当只定义了一个条件时（没有信号，没有触发），OpenERP评估这个条件，如果评估为true，工作流实例处理通过transation。如果条件不匹配，在每次关联的记录修改时都会再评估一次，或者通过一个显示的方法调用做这件事。
默认地，属性condition（即评估表达式） 是true。注意条件可能有几行长，在那种情况下，最后的一个值决定了是否采取通过。
在条件评估环境中，定义了几个方便的符号（除了在OpenERP的safe_eval环境中）
- 所有的模型列名，and
- 所有浏览器记录属性
Singals（信号）
除了条件外，一个transation可以指定一个信号名。当使用一个信号名时，transation不会直接通过，即使condition评估为true。阻塞transation，等待被唤醒。
为了唤醒一个由信号名定义的transation，信号必须发送给工作流实例。发送信号的通用方式是在用户界面使用一个按钮，使用元素<button/>并且信号名作为按钮的属性name。一旦点击了按钮，信号发送给当前记录的工作流实例。
注意
当信号发送给工作流实例时，仍要评估条件。
Triggers（触发）
条件评估为fasle，transation不会通过（并且它引导的activity不立即处理）。工作流实例仍然可以通过提供所谓的触发器处理transation。这是发生在条件不满足，触发器记录在数据库中的情况下。之后，可能唤醒工作流实例，其安装了那些触发器，提供它们重新评估transation条件。这种机制使得唤醒工作流实例很便宜，只是针对几个（安装了触发器的工作流）而不是全部
触发器以记录IDs记录在数据库中（与模型名字一起）并适用于等待那些记录的工作流实例。transation定义提供了一个模型名（属性trigger_model）和一个Python表达式（属性trigger_expression），在给定的模型中评估成一列记录IDs。那些记录的任何一个可以唤醒它们关联的工作流实例。
注意
无论什么时候transation重试，触发器不重装。
Splitting and joining transitions（拆分和联合过渡）
当多个transitions离开同一个activity，或者流向同一个activity，OpenERP提供了获取哪个transition的控制，或者如何处理到达的activity。activity的split_mode和join_mode 属性用于这样的控制。那些属性的可能值解释如下。
Activities
transition可以通过工作流的控制结构看见，activities是事件发生的地方，从改变记录状态到发送邮件。
存在不同的activities：Dummy，Function，Subflow和Stop all，当activity处理时每个做不同的事情。除了这些类型，activity还有其他属性，详情看下面。
Flow start and flow stop（流开始和流结束）
flow_start属性是一个布尔值，指定了当工作流实例化时，activity是否在处理。多个activities能将其属性flow_start设置为true。当为一个记录实例化一个工作流时，OpenERP简单地处理所有，并之后评估输出的transitions。
属性flow_stop是一个布尔值，指定activity是否停止工作流实例。当所有的activity，其flow_stop属性设置为true，都完成时，工作流实例认为是完成了。