這一篇就用第一篇留下來的例子來說明 AME 中，核決群組 (Approver Groups) 的使用。
第一篇所留下的例子：
當員工要請購任何跟電腦相關的東西時，希望可以讓簽核流程先流到資訊部門；同意後再按照請購人的組織架購一路往上簽核到有足夠核決權限的人為止；之後再發給財務部門做預算檢查；最後再發信給採購人員進行採購程序。
配合在第二篇所提到的需求分析我們可以知道
- 任何跟電腦相關的東西：條件
- 資訊部門：第一部份的簽核
- 組織架購一路往上簽核到有足夠核決權限的人為止：第二部份的簽核
- 財務部門：第三部份的簽核
- 發信給採購人員：第四部份的
簽核通知
設定的最後一個部份是核決群組 (Approver Groups)。雖然它的名字是群組 (Group)，但是不表示它只能用在定義一群人的情況下。
這個功能的重點在於，如果你的需求是要指定一個或一群 "特定" 的人員，你就必須使用這個功能來定義 (至少到目前為止，我還沒有發現其他方式來指定特定人或人群)。
它一樣可以用 Function 去回傳邏輯複雜的結果，唯一可以被稱得上是缺點的地方，就是如果表單有提供核決流程預覽時，使用者"第一眼"只能看到這個群組的名稱，看不到誰才是真正的核決人 (Approver)，使用者要點擊進去才能夠再下一個畫面看到是誰在這個群組裡面。
設定畫面基本上也跟屬性差不多，因為邏輯都在 Function 裡面～
有一個特殊的設定參數需要解釋一下：Voting Method
這個參數是讓你決定這個群組中，如果有多人的情況下，要如何才會視為它完成 (只有一個人的話，同意就是同意，用那一個值的結果都是一樣的)。
Serial / Consensus / Order Number：這三個都是要求全部成員同意才算同意。差別就在於送信的方式略有不同。
- Serial：依照順序，一個人一個人依序同意 (當然，順序是可以動態決定的)。
- Consensus：系統會同時送出每個人的信。
- Order Number：可以想成是 Serial + Consensus，系統會依照編號依序送出，如果有多人的編號相同時系統會同時送出信。
First-Responder-Wins：系統會同時送出每個人的信，第一個人的回應就是回應了。其他人之後的回應系統 "好像" 還是會紀錄，但，為時已晚了。
新增完後，如果你在前一個 "動作" 裡，有新增是跟核決群組運作的類別，那此時你回到 "動作" 的頁面，並選擇該類別時，你就會發現下面的 Actions 就會自動出現你剛剛新增的核決群組，這樣就表示設定是正確的：
沒有留言:
張貼留言