1. 應對業務規則的變化
比如常見的員工請假流程：如果低於3天提交部門經理，如果多於3天以上，提交總經理審批。這就是一種流程。按照常規代碼處理時：
if days < 3
submit to Department Manager
else if days >=3
submit to CEO或許有人會問，既然我代碼可用處理，爲什麼還要用工作流呢？
1). 主要考慮流程的變化因素不可控，比如，公司出來一項新的政策，說是5天以上總經理纔去審批，這個時候，如果通過編碼的方式就要改代碼了，再重新發布，系統的可擴展性太差；
2). 假如有人說我不去把請假天數硬編碼，我放在配置文件裏面不就可以了嗎？
的確是可以的，主要的好處不用重新發布程序。但是這樣做，跟流程相關的規則還是零碎的，分散的，不是完整放在一起的。
3). 我們可以認爲辦法2)就是工作流的萌芽思想，我們將所有跟業務規則有關，任務辦理人員有關，任務數據權限有關的信息全部整合的一個配置文件裏（相當於流程定義或配置信息），然後在程序運行時，讀取這個配置文件，判斷流程的執行流轉走向，最終結束。
在流程定義文件中，分支節點上的連線可以用來定義規則，可以舉例如下：
<Condition type="Expression">
<ConditionText>
<![CDATA[
askDays < 3
]]>
</ConditionText>
</Condition>2. 維護活動節點的資源
繼續看員工請假流程的變化，不僅僅是業務規則發生變化（規定的請假天數），活動節點上的資源也會有變化，假如：公司規定，員工請假時，如果部門主管不在的時候，可以直接發送給HR主管：
if days < 3
submit to (Department Manager || HR Manager)
else if days >=3
submit to CEO從第一點我們總結出，工作流就是把所有跟業務規則有關，任務辦理人員有關，任務數據權限有關的信息整合在一個配置文件裏。此處角色的變化，同樣遵循這個原理，角色作爲活動資源，綁定到節點上，可以增加或減少。角色資源在流程文件中的定義如下：
<Performers>
<Performer id="3c917748-6752-4bc6-aea8-b85d40521888"/>
<Performer id="8e54c07d-d424-4186-b86c-cec43019bed0"/>
</Performers>3. 控制活動節點的數據權限
應用系統中，單據數據讀取或修改權限非常重要，每一個流程步驟的業務數據處理，都會有明確規定，只有具備相應權限的人員纔可以修改數據。其關係可以表示爲：{ Node, Role, Field }的三元表達式。
比如在請假流程中，只有員工自己可以在“請假申請”節點上修改請假天數，而後續節點的部門經理則不能修改請假天數。數據權限始終要根據節點位置和角色共同來定義。
總結：
以上是對工作流的基本功能職責做以說明，鑑於加入Wf5項目的人員可能對工作流剛接觸，特意描述，完整的流程定義文件可以參考項目中的xml文件。此外，後期我們再繼續對工作流模式，引擎原理等再做出解釋和說明。