企業的業務處理過程如果簡單，不繁瑣，幾步就處理完成了的，不會考慮上工作流系統。如果處理過程繁雜，處理步驟很多，涉及到很多工序，而且處理時間很長，就必須用工作流系統了。統一管理，統一運行，無論處理的過程以及路由如何繁雜，這都是工作流系統最擅長的了。並且后續的維護、修改、變更也能快速的相應。這些是用硬編碼的方式來實現無法比擬的。
企業選用工作流系統，還有一種情況，當企業的業務處理種類很多，雖然每種業務的處理過程不復雜，但是種類太多，用硬編碼的方式來控制流轉工作量太大，多一種業務處理過程就需要做技術人員撲上去，開發，測試，發布，部署，試運行一次，而且后續的維護和修改更加無法控制，這樣企業也是無法忍受的。
用工作流系統統一建模，將業務處理過程圖形化的方式展現出來，一個業務辦理的過程用流程中的一個節點表示，有多少個業務辦理過程，就有多少個流程節點。
工作流引擎是業務流程的抽象，將業務數據和流程處理過程剝離，流程引擎只負責業務流程的流轉，包含節點與節點之間的各種路由方式，條件路由，循環路由，分支，合並，子流程等等。
在工作流軟件產品中就表現為，業務流程的流轉用流程設計器來建模，將業務的流轉辦理過程用流程的節點來表示。業務辦理過程，在節點上掛接的業務表中處理，包含讀寫展現業務數據，工作流引擎是不關心業務數據的，就是說節點上辦理的是何種業務，工作流引擎是不必要知道的，這樣來達到業務數據和流程的流轉剝離。但是，工作流引擎在處理業務流程的流轉時，有時候需要一些業務數據的參與（如條件路由，就需要取業務數據，如報銷金額>10000這樣的條件，這個報銷金額就是業務數據），這就需要將業務數據做為實時的變量，傳遞到流程引擎的上下文中，使得流程引擎能讀取到。所以我們經常說 業務數據和流程數據是交互的，既要分開又要有關聯。
當一個業務流程建模好了，並且業務表單也掛接上了，就可以運行了，運行的順序按流程建模的節點順序向前流轉。
運行的結果可以在流程的運行軌跡圖上面直接查看，當前運行到那里了，走過的軌跡也有圖形的方式查看。每個節點上辦理的業務，通過雙擊節點，打開表單，還原當時的業務數據。雙擊當前正在辦理的節點，打開表單，辦理這個節點上的業務。提交后，這個節點任務就辦理完成，從軌跡圖上面又可查詢到，當前運行和流轉到那里了。
這種的流程運行方式，在常見的生產制作等等行業都是很實用的。通常在審批流中，不是很有用，審批流的流轉通常是給下一步的辦理人發送一條需要審批的待辦事項（待辦任務），具有審批權限的人登錄到系統后，在我的待辦任務中，查看到待辦事項，點擊進去執行審批。
當一個業務流程的辦理節點數很多，或者說一個業務流程實例一啟動，辦理的過程就是幾個月。那么這種類型的流程節點數量一定會很多。用流程建模的工具來查看或者編輯，會顯得有些笨拙，節點數量大多，一個界面都放不下，這種情況，我們通常可以有選擇性的用子流程的方式來分解，這樣使得界面更簡潔。
