在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，都完成時，工作流實例認為是完成了。