SigningGroup事件的DocuSign Webhook / Connect行为

如何解决SigningGroup事件的DocuSign Webhook / Connect行为

我们正在使用DocuSign REST API，并利用Webhooks来接收在信封的整个使用期内发生的各种信封和收件人事件。

我们还在实现中使用了SigningGroups，并且我注意到在某些情况下Webhook事件并没有发送给我们，而感觉上确实如此。

场景：

1-将信封发送到包含两个不同用户的签名组。用户A和用户B。

发送了一个Webhook事件，收件人用户名为“ Signing Group 1”，电子邮件地址为空，状态为“已发送”。

2-用户A在收到来自DocuSign的通知电子邮件后参加了签字仪式，但是在此阶段，什么都没有签字。

发送了一个Webhook事件，收件人用户名现在更改为“ UserA”，电子邮件地址现在设置为UserA的电子邮件地址。收件人状态现在为“已发送”。

3-用户A决定不立即签名，而是“稍后完成”，这样做可以解除对该签名者的锁定，以便用户B现在愿意的话可以访问签名仪式。 / strong>

尽管DocuSign知道UserA不再专门分配为签名组收件人，但没有发送Webhook事件。如果在此阶段执行API调用以获取信封的收件人，我们可以看到收件人用户名已返回到“签名组名称”“ Signing Group 1”，并且电子邮件地址现在又为空，因为不再在签名组中有一个特定的人。

这感觉错了-我们的系统尚未收到关于不再向UserA分配（并锁定）签名组中任何其他用户的签名过程的通知。

4-用户B现在正在访问签名仪式（因为用户A不再锁定它），但是在此阶段尚未签名。

尽管签名组中的用户现在完全不同，但查看并锁定签名过程的签名用户与签名组中的任何其他用户都不一样，但没有发送Webhook事件。我们的系统仍然认为已分配UserA并查看/锁定了签名过程。

5-用户B现在对文档签名并完成。这样就完成了信封。

现在已发送一个Webhook，通知我们UserB已“签名”，因此信封已完成。我们甚至都不知道UserA离开了签字仪式，而UserB从那以后一直查看信封。

再次，这感觉很不对劲，尤其是如果我们要手动轮询信封及其中的收件人的状态，DocuSign将所有这些信息都包含在信封中，那么使用Webhooks的目的就是摆脱不必要的负担轮询DocuSign API。

无论我们使用DocuSign'Connect'还是在信封级别配置webhook事件，此行为都是相同的。在配置“连接”或我们的信封级别事件时，我们确保已启用所有个可用信封和收件人事件。

有人知道为什么这是一种更好的方法，还是有一种更好的方法来接收这些丢失的事件，因为它不能使我们的系统保持最新，就像我们手动轮询API一样？

作为上述的补充说明，我今天上午所做的另一项观察是，无论签字人是否使用“稍后完成”选项，无论签字人是否在签字组中，它都将出现。似乎会触发任何形式的webhook事件！

同样，我觉得这很奇怪，因为webhook响应数据包含每个文档中每个签名者的每个签名选项卡的状态，但是如果我在签名仪式中在文档的4个选项卡中签名了3个，则单击“稍后完成”，则不会生成webhook事件。因此，尽管DocuSign知道该用户已签名了哪些标签，但他们并未通过网络钩子通知我们4个标签中的3个已签名，因此我们的系统仍然认为，尽管用户可能已“查看”信封-实际上还没有签署任何东西。为什么如果每个文档和每个收件人都无法反映当前状态（尽管DocuSign知道此数据），为什么还要在每个Webhook响应数据中包括每个文档的不同选项卡状态？

解决方法

不幸的是，Connect（和每个信封Connect）尚不支持Finish Later事件。

这是一个已知的功能请求，编号为CONNECT-971。不幸的是，由于更高的Connect优先级和资源限制，未安排此功能。

您可以要求DocuSign业务或支持联系人将您的姓名和公司信息添加到功能请求中。

同时，我建议：

1. 由于您正在密切跟踪信封状态，因此请使用SIM Connect排队算法。通过eSignature管理工具中的Updates屏幕切换到它。这样，您的应用将收到所有可能会被跳过的中间状态消息。

2. 使用算法询问DocuSign平台，以确定在将信封交付给签名组中的特定人员后发生了什么。您可以绘制出不同的潜在结果（就像您在问题中所做的那样），并根据需要询问DocuSign平台。