流程自動化要先寫哪些人工閘門
流程自動化之前，先寫明哪些步驟可以自己走完，哪些步驟必須停下來等人，以及停下來之後如何回到人手路徑。付款、主資料與對外訊息先標成要人完成的步驟。這三類還沒有領取人時，自動化先不要開始。
自動化之前先標每一步
從收件到轉交，每一步寫四項：步驟名稱、由服務自己完成還是由人完成、誰可以領取、人做完或拒絕之後流程去哪裡。四項缺任何一項，這一步先留在人手路徑。
流程怎麼接到貴司已經在用的系統，見 流程代理與工作流程自動化。畫面機器人與會暫停的代理怎麼分開，見 RPA 和流程代理有什麼分別。具體產品怎麼把步驟接起來，見 n8n 和 Make 怎麼選。本文先寫閘門，不選產品。
標準裡的三種任務
BPMN 2.0.2 由 Object Management Group 於 2014 年 1 月出版，狀態為 formal。該頁寫明，這套記法給設計、管理與實現業務流程的利害關係人直接使用，同時要精確到可以把圖轉成軟體流程元件，記法本身不綁某一種實作環境。規範正文在該頁的 Normative Documents，檔案編號 formal/13-12-09。
規範把 Service Task 寫成使用某種服務的任務，服務可以是 Web service，也可以是自動化應用。第 10.3.4 節寫明，有些任務要人完成，並規定兩種有人參與的任務：User Task 與 Manual Task。User Task 由業務流程運行環境執行並管理，人在軟體應用的協助下完成，任務生命週期由稱為 task manager 的軟體元件管理。Manual Task 不由任何業務流程引擎管理，引擎不追蹤這類任務的開始與完成；規範舉的例子是給電話技師的紙本安裝指示。User Task 的潛在負責人可以領取任務，領取之後成為實際負責人；實例屬性 actualOwner 回傳領取該任務的使用者。本文不引用實作產品的方案或價格。
可以自己走完的步驟
規則已寫成文字、這一步不付款、不改主資料、不向客戶或供應商發送訊息，而且已經有一個服務或自動化應用可呼叫：這一小步可以標成 Service Task。呼叫的服務名稱、讀哪一筆、寫回哪一個欄位，寫在同一行。
規則還沒寫成文字，或呼叫會改到付款、主資料、對外訊息其中任何一類：這一小步保持為要人完成。規範裡的 Service Task 描述的是呼叫服務，本文不把「有介面」寫成可以無人看過就付款或發信。
付款、主資料與對外訊息先停
付款、主資料的新增或修改、以及對客戶或供應商發出的訊息，在自動化開始前就標成要人完成。主資料包括客戶、供應商、資產與料號這一類會被後續步驟沿用的紀錄。對外訊息包括電子郵件、短訊，以及會出現在對方系統裡的通知。
這三類標成 User Task 時，運行環境要能管理領取與完成。標成 Manual Task 時，沿後面一節另寫完成紀錄。兩種都要有潛在負責人的名字。名字還沒有，這一步先不要放進自動路徑。
人領取之後流程如何繼續
User Task 的潛在負責人領取之後，規範寫明此人成為實際負責人，actualOwner 回傳這位使用者。完成之後，任務生命週期由運行環境管理，流程從這一步的下一站繼續。下一站的名稱寫在閘門清單上。
領取之後若要拒絕，拒絕的結果同樣寫回原系統的具名欄位，例如申請狀態或工單結論。只有對話裡一句「已完成」，下一站看不到。寫回欄位的要求與 RPA 和流程代理有什麼分別 相同，本文不重寫工具選擇。
引擎不追蹤時另寫完成
Manual Task 按規範不由引擎追蹤開始與完成。紙本或系統外的工作做完之後，要由人另寫一筆：誰做完、何時、哪一筆案件、結果是通過還是退回。沒有這筆，自動路徑沒有繼續的依據。
這筆完成紀錄寫進閘門清單指定的系統與欄位。欄位在該系統裡不存在時，這一筆停住，沿 設備怎麼接到既有業務系統 的寫法，先補欄位再恢復。本文不假設引擎會替你補上它不追蹤的完成時間。
拒絕之後回到人手路徑
人拒絕、逾時未領取，或這一步無法在運行環境裡表示成 User Task 時，案件回到開工前已經在用的人手路徑。人手路徑寫明打開哪一筆紀錄、交給誰、做完之後要不要再回到自動路徑。
逾時的時限來自貴司自己的審批規則，並註明日期。本文不代填時數。沒有寫明人手路徑時，拒絕會停在運行環境裡，沒有人沿原來的辦法把案件做完。
什麼時候先不要自動化
付款、主資料或對外訊息還沒有領取人，或拒絕之後的人手路徑還沒寫明時，先不要把收件到轉交整段交給自動化。先補閘門清單。
本文不給出節省時數，也不指定某一套流程產品。規範頁的出版日期是 2014 年 1 月。沒有貴司自己的閘門清單之前，用「每一步是否標了服務或人工、付款與主資料與對外訊息是否會停給人、拒絕之後是否回到寫明的人手路徑」來檢查自動化有沒有在按閘門走。