需求文档定稿之后，如果只靠邮件去提醒负责人，漏掉的环节还是会很多，真要管住审批过程，就得在Polarion里面把一套稳当的审批流程搭起来。这里主要涉及两件事：一是文档审批怎么配置才比较合理，二是审批流该发的通知一直没有触发时，该怎么顺着链路往下查。把这两件事处理好，关键就是把文档状态、审批评审人员、签名要求还有各个节点的通知事件，都放进同一条流程里面去，让它们互相咬合。Polarion本身就可以通过LiveDocs来管理需求文档，也提供电子签名、审批记录和变更追踪这些能力，只不过不同版本的通知功能会有些差异，动手配置之前最好先摸清当前部署的到底是哪一个版本。

　　一、Polarion怎么配置文档审批

　　给文档配审批的时候，不能只扔一个“已批准”的状态就算完，实际项目里面，至少得把“编写中”“待评审”“待批准”“已发布”这几个阶段拆开，而且每一次状态发生改变，都要落到具体的责任人头上，判断条件也要写明白，不能模模糊糊就走了。

　　1、先定好审批的关键节点

　　进到项目管理页面的工作流设置里，给文档或者文档里面的Work Item规划状态流转路径，最常见的顺序就是从Draft先进到Review，再从Review进到Approved或者Released，状态名字可以按公司的流程习惯来调，但每个节点都要写清楚由谁来提交、谁来评审、谁来批准。

　　2、把审批人员配置到位

　　审批人员可以按单个用户、按用户组或者按项目角色来指派，项目里通常会用一个类似project_approver的角色，把有批准权限的人集中管起来，流程一到审批阶段，系统就会自动把相关人员拉进Approvers列表里，并且在批准还没有完成之前挡住流程，不让它提早滑到下一个状态，Polarion早期版本就已经支持这种自动添加审批人的做法。

　　3、把签名要求加上去

　　如果项目需要正式留痕，就可以在需要审批的节点上启用电子签名，审批人可以在Work Item表单、侧边栏工具或者直接在LiveDoc里提交Approved或Disapproved的处理结果，保存后就等于完成了签名确认，相关的签名记录会保留姓名、日期和签名的用途。

　　4、用一份测试文档把流程完整跑一圈

　　正式推广之前，先新建一份测试文档，分别用编写人、评审人和批准人三种不同账号去操作一遍，重点看状态能不能按预想的次序顺畅切换，审批还没完成的时候会不会被系统拦截，驳回之后能不能退回到修改阶段，这些提前在测试文档上暴露出来，要比在正式文档上出了故障再回头修容易得多。

　　二、Polarion审批流通知不触发怎么办

　　审批流本身能够正常流转，但负责人却怎么都收不到邮件通知，通常不是单一原因造成的，与其反复点提交审批，不如按照一条线追下去查清楚。

　　1、先确认一下自己用的版本

　　到了Polarion ALM 2512这个版本，新增加了文档签名通知的能力，当系统需要某人签名时，可以自动发一封带直达链接的邮件，其他人完成签名或者拒绝时也能发出实时更新，管理员还可以在通知管理的设置里去专门配置这些文档签名事件，如果用的是更早的版本，就没有这套现成的新事件，只能靠项目原有的通知方式或定制流程去补上这块。

　　2、检查通知事件到底开了没有

　　如果当前已经用上2512或之后的版本，就要进管理区，去查看Notifications设置里，“文档签名邀请”“签名完成”和“拒绝”这一类的事件是不是都处于启用状态，有时候审批流程本身配得挺完整，却忘了打开对应的通知事件，结果流程静悄悄走完了，邮件一点动静都没有。

　　3、再查一下审批人的邮箱和访问权限

　　打开审批人的用户资料，仔细核对邮箱地址是不是空的或者拼写有误，接着还要确认审批人这个账号能不能正常打开目标项目、对应的Space和那份LiveDoc文档，因为如果连文档访问权限都没有拿到，即使收到了邮件里的链接，点进去也会被拦在外面，根本进不去审批界面，Polarion是按项目和Space来控制访问权限的，这一点经常被漏掉。

　　4、最后检查邮件发送的整条链路

　　假如所有审批邮件都收不到，那就让管理员去排查邮件服务器的配置，看发件地址、端口、认证信息和系统日志有没有问题；如果只是个别的人收不到，就重点去看垃圾邮件箱、企业邮箱的拦截规则，以及用户资料是否填写准确。

　　三、Polarion文档审批怎样避免后期反复排查

　　审批流上线并且稳定之后，还要把配置和验证的记录保存下来，否则等项目模板被复制到新项目里时，很容易漏掉原来设定好的角色和通知事件，后面再反复排查就很耗时间了。

　　1、保留一份清晰的流程说明

　　把状态名称、审批角色、签名要求、退回条件和通知事件都写进项目说明文件里，以后如果碰上人员调整，只需要去改动对应角色下面的具体成员，不要因为着急就临时去改整个流程，那样容易把已经稳定的设置搅乱套。

　　2、常备着几套测试账号

　　最好把编写人、评审人和批准人这三类测试账号长期保留下来，以后不管升级Polarion、修改项目模板还是调整邮件服务器，都先用这些测试账号把整套审批路径完完整整再跑一遍，新环境里有没有暗藏问题就能早一点发现。

　　3、定期扫一眼那些还没被处理的审批

　　邮件通知终究只是个提醒，不能代替看板的作用，可以建一份待审批文档的查询或报表，定期查看有哪些文档长时间停在Review状态，有哪些评审已经通过却迟迟没有人去点批准，这样一来，卡在流程中间的待办项就更容易被及时揪出来。

　　总结

　　在Polarion里面给文档配置审批，核心步骤就是先把状态流转搭起来，再配上审批角色和签名要求，接着用测试文档完整验证一遍。遇到通知不触发的情况，就从版本开始，顺着通知事件、用户邮箱、访问权限和邮件链路的顺序往下排查，特别是升级到2512以后，可以多利用新增的文档签名通知事件，让系统自动发信来代替人工催办，审批过程也就更容易保证透明和不遗漏。