流程自动化要先写哪些人工闸门
流程自动化之前，先写明哪些步骤可以自己走完，哪些步骤必须停下来等人，以及停下来之后如何回到人手路径。付款、主数据与对外消息先标成要人完成的步骤。这三类还没有领取人时，自动化先不要开始。
自动化之前先标每一步
从收件到转交，每一步写四项：步骤名称、由服务自己完成还是由人完成、谁可以领取、人做完或拒绝之后流程去哪里。四项缺任何一项，这一步先留在人手路径。
流程怎么接到贵司已经在用的系统，见 流程代理与工作流程自动化。画面机器人与会暂停的代理怎么分开，见 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 月。没有贵司自己的闸门清单之前，用「每一步是否标了服务或人工、付款与主数据与对外消息是否会停给人、拒绝之后是否回到写明的人手路径」来检查自动化有没有在按闸门走。