一条流程可能以资料已提供、申请已退回、申请人撤回或转入后续核对等不同方式停止。若所有路径最后都写结束，读者会误以为它们产生了相同结果。本文用虚构的内部资料申请说明多个终点的命名与检查方法，不提供真实审批制度，也不把示意图冒充产品截图。
先定义这张图负责到哪里
明确起点是收到申请，本图只描述受理与初步处理，不覆盖后续使用资料的过程。边界确定后，终点应描述本图结束时已经形成的状态，而不是写整个业务完成。超出范围的工作可以指向另一流程，但要写明交接对象和输入。
用结果句替换笼统结束
例如资料已提供并记录、因信息不足退回补充、申请人确认撤回。每个名称都应让下游知道还能做什么。不要使用处理完毕这种无法区分结果的词，也不要把等待他人确认写成已完成。
待后续处理不一定是真终点
若责任仍在本流程内，只是暂时等待，它更像一个可跟进状态，需要负责人和再次检查条件。只有本图明确把后续工作交给另一流程，才可作为边界终点。箭头离开页面不能自动证明责任已经转移。
核对终点对应的证据
资料已提供需要有交付记录；退回需要记录缺少什么；撤回需要有明确意愿。证据形式依实际规则决定，不能为了画图编造按钮或系统状态。没有证据时降低表述强度，保留待核实，不把操作者的推断写成正式结果。
从下游反向读每个终点
假设接手人只看到终点名称和记录，他能否判断是否继续、向谁询问、依据在哪里。若两个终点带来的动作不同却名称相同，就需要拆开。若名称不同但后续完全一致，检查是否真的有必要分成多个终点。
建议把终点名称写成对象加状态，例如申请已撤回，而不是只写完成。多个终点能真实表达不同结果，不必为了图面整洁强行汇成一个框。关键是每条路径停止时，状态、依据和后续责任都没有被结束两个字掩盖。
最后核对
实际使用时，再请一位没有参与整理的人仅依据成稿完成一次查找或判断，记录他误解、停顿和需要追问的位置。修正时回到原始材料与已确认规则，不用更肯定的措辞掩盖信息缺口。若场景、对象或版本发生变化，应重新确认方法是否仍适用，并保留尚未解决的问题。