既然是與用戶相關的權限，那么權限的表現則一定與UI緊密相連。工作流管理系統里，用戶與工作流的交互界面有四種：
1、流程設計器
    流程設計器的功能比較單一：定義或更新流程定義。里面涉及到包、模板和版本的概念。資源即流程模板（例如發文模板、收文模板），權限可以細分為：維護、只讀以及不可見。
2、流程管理控制臺
  對流程實例（包括活動實例和工作項實例）進行管理。這里對資源的劃分有兩種方式：操作和數據。從操作來分比較瑣碎，例如：流程實例的掛起、終止、恢復、跳轉，活動實例的掛起、終止、恢復等等，當然可以做一種集合，例如：對流程實例的管理、對活動實例的管理、對工作項實例的管理、時間服務的管理等等。從數據劃分則很好理解，例如：發文的流程實例、收文的活動實例等等。兩種方式的組合構成最終的權限。
3、工作項列表
    這個似乎沒什么好說的，工作項直接分配到用戶、部門和崗位。
4、與流程相關的業務數據
    用戶對業務自身的權限以及不同流程節點對業務的權限。看問題的兩種方式。業務數據處于流程中時由流程決定權限，例如擬稿時可以操作哪些字段，審批時是否可以上傳附件等等。流程結束后，業務數據歸檔，此時的權限由業務權限+流程權限組合。簡單的一個例子：普通用戶A可以在發文模塊里看到自己參與過的所有發文文件，發文管理員B則可以看到發文模塊里所有的發文文件。
    
結合具體的業務需求：
1、主控崗位的提出。例如發文管理，存在主控崗位，可以對所有的發文流程進行管理，催辦、督辦等等。
2、大集中模式下對數據的再劃分。還是以發文管理為例，北京公司的發文管理員對北京的發文數據進行管理，上海公司的發文管理員則只能對上海的發文數據進行管理。

最終的權限分類：
1、流程設計器里流程模板的可見與不可見。可見即可維護。
2、流程管理按操作來分顯得沒有實際的意義，用戶關注的是業務數據即操作的范圍。流程實例（活動實例）的可見與不可見。可見即可操作。更進一步說，用戶甚至根本都不會登錄到流程管理控制臺，他會傾向于在業務菜單里有自己相應的流程管理功能，例如在發文管理里增加發文催辦、督辦等等。
3、不用
4、往業務權限表里增加流程參與者的權限信息。

總結：總是感覺工作流管理部分的權限不是那么的必要，流程定義的復雜度讓最終用戶很難直接使用，流程實例的管理更多的是契合到業務中去，而這種契合表現則是流程數據按業務進行劃分后的管理。

http://www.aygfsteel.com/ronghao 榮浩原創，轉載請注明出處：）