先找出你正在追的那件事
如果申請散落在訊息與試算表，最困難的常是：不知道誰還沒處理、找不到原始資料，或同一筆內容有不同版本。這些問題不一定需要整套企業系統，可以先從一種申請開始整理。
選擇每週真的會發生、規則相對清楚的流程，例如請假或費用申請。先衡量資料量、角色與處理頻率，再決定現成表單、流程平台或客製工具。
把狀態與角色分開寫
狀態可以是草稿、送審、核准、退回及撤回；角色則可能是申請人、主管與管理者。每個角色在每個狀態能看什麼、做什麼，都要確認。
例如申請人能修改草稿，送審後不能自行改內容；退回後可修改並重新送出。這比一句「要有簽核功能」更能作為開發依據。
歷程比漂亮的流程圖更重要
至少要知道誰在什麼時間做了什麼、當時的內容版本與退回理由。修改已核准資料時，應保留合理的更正流程，不要直接覆蓋而失去原始記錄。
若申請涉及個資或薪資，還要進一步確認資料存取範圍、保留期間與匯出權限。實際法規及人事規則應由公司適任窗口確認，系統以雙方確認的規則實作。
第一版建議的交付範圍
- 一種申請表與必要欄位。
- 申請人、審核人兩種主要角色。
- 送出、核准、退回與查詢歷程。
- 必要的搜尋、列表與簡單匯出。
代理人、多關卡條件、任意拖拉流程、組織異動與 ERP 同步，可先列為第二階段。每多一種路徑，都要增加相應的權限與例外驗證。
不要忘記這些驗收案例
自己不能核准自己的申請；其他部門不能透過網址讀取不屬於自己的資料；退回後重送保留舊歷程；主管重複點擊不產生多筆核准。這些規則應由伺服器檢查，而非只把前台按鈕藏起來。
常見問題：展示作品已經包含完整企業流程引擎嗎？
沒有這樣的承諾。TeamPortal是持續開發的技術專案，可參考出勤、工時及請假流程；任意配置的流程引擎與完整薪資 ERP 並非已完成項目。實際商用仍需要依公司規則重新評估與驗收。
