前面所使用的活動對象大都是固定的角色或是呈送者的直屬主管，但有些特殊情況下，會用到動態的角色，無法事先知道要送往哪一個對象，我們可以從FLStandard或FLApprove的「SendToKind」屬性中來了解動態的參考角色意義。其中共有RefRole與RefManager兩種參考角色，前者RefRole代表簽核的對象為該單據的某一個指定欄位內容，如上例中的ServiceRole欄位就存放著一個角色的代號，是在簽核過程的「指定服務窗口」時才被決定為R04，如果下一個活動被設定為RefRole者，將會送往該欄位所指定的角色R04的待辦中；後者RefManager則代表會送往該欄位指定角色的直屬主管，如上例中服務窗口為R04，則會送往R04的主管，依組織設定則為R05。

Step1>        沿著Customers.Xoml流程往下做，在FLDesigner打開Customers.Xoml，在「指定服務窗口」下方拖入一個FLStand標準活動，目的用來讓服務窗口確認，因為服務窗口是動態決定的，因此就必須使用到RefRole的型態，如圖。

 

現將這個FLStand的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文服務窗口確認。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，此活動是不允許更改的，所以我們設定為Normal，代表不可以對資料進行任何的動作 (不能新增/更改/刪除/查詢資料等等)。

FLNavigatorMode：在此設定為Continue，代表只顯示「上呈」的按鈕，而不會顯示「審核」與「退回」的按鈕，目的就是讓此活動可以讓該角色得以確認，按下「上呈」的按鈕後即可讓流程往下持續。

SendToKind：活動的對象種類，我們設定為 RefRole，代表此活動指定了一個動態的參考的角色，必須另外定義SendToField來指定哪一個欄位名稱存有該參考角色的內容。

SendToField：當SendToKind為RefRole或RefManager時，即用此屬性來定義一個欄位名稱，用來存放該活動的對應角色，在此可以下拉選擇欄位名稱，我們選 ServiceRole這個欄位。

WebFormName：請選擇一個RWD的表單名稱，同樣選擇RWDClient.rCustomersFL這個表單。

 

最後在FLDesigner中將本Customers.Xoml存檔。

 

Step2>        同樣以 003這個User來登入，點選「客戶申請」這個活動來打開Customers這個表單，接著我們輸入一筆客戶資料，我們將信用額度輸入為5萬，可以免簽總經理與行政經理，以簡化簽核流程。

 

Step3>        使用005登入，再從「待辦事項」中找到0008這個申請單， 當按下「確認」時，系統只會告知送往R05客服經理(指定服務窗口)，因為信用額度不超過10萬，所以不會送往R03行政經理(信用審核)的活動中。

 

 

 

Step4>        接著使用007登入，再從「待辦事項」中找到0008這個申請單，按下打開可以修改「服務窗口」的欄位，此時我們設定為R04，代表指定某一個工程師的角色，因為R04(工程師)有兩個USER(分別為004與011)，因此會有兩個工程師收到待辦，如果你希望「服務窗口」必須為一個工程師負責，你就必須將004與011兩個User設定成不同的角色(Groups)，如設定成R04A代表004，R04B代表011就可以做到。

更改後按下「審核」，最後按下「確定」，因為後面活動是根據ServiceRole來決定的，因此系統會告知已經送往 R04 (工程師)，對象有004與011等。

 

 

 

Step5>        我們使用004登入 (使用011登入也可以)，再從「待辦事項」中找到0008這個申請單，打開此單據，如圖，因為此FLNavigator為Continue ，無法修改內容只能往下呈送，呈送後往下為『通過通知』活動，所以不會停在申請者的待辦上，會自動將流程結案。