I am not receiving events for Delete of signers.
Is this an expected behaviour of DocuSign Connect?
These are my steps:
Log in as sender and created the envelope with 4 signers
Click on the email link as the signer and opened the envelope
Signed the envelope as the signer
Log in as sender and deleted one of the remaining 3 signers (This is missing from my Connect event)
I received XML messages for steps 1-3.
However, there was no event trigger for step 4.
I am monitoring this under both Connect Logs and Failures.
I have every event enabled under my Connect Configuration.
Is it expected to not receive an event in this case?
If not, any suggestions on how I can debug why I am not receiving messages?
Just another finding:
An event is triggered for the New Experience.
This behavior is only observed for the Classic Experience.
I believe the behavior you're seeing is by design. i.e., the "Recipient Deleted" action does not correlate to any of the events that can trigger a DocuSign Connect notification. The events that can trigger a DocuSign Connect notification are shown in the Connect configuration UI:
As this screenshot shows, there is no event that correlates to the "Recipient Deleted" action.
If your application needs to know if/when a recipient is removed from an Envelope, you could implement a process that periodically polls in-progress envelopes (List Envelope Recipients) with the goal of detecting if/when a recipient has been deleted. This obviously isn't ideal, as it wouldn't be a real-time notification, but it's likely your only option, given that DocuSign Connect does not currently support notifications for "Recipient Deleted".
UPDATE #1
Interestingly, I've verified the behavior that you've described in your Comment below. I tested the following scenario in both the "New" UI and the "Classic" UI:
Created/sent an Envelope with 2 recipients (sequential routing order: 1, 2)
Immediately thereafter (i.e., while still pending response from the first signer), I corrected the Envelope to delete the second recipient (routing order=2).
Conducting the steps above using the "New" Smartsheet UI triggers a Connect Notification ("Envelope Sent"), while conducting the exact same stepsusing the "Classic" Smartsheet UI does not trigger any notification. This behavior inconsistency seems like a bug to me -- perhaps someone with DocuSign can chime in to confirm/explain.
Related
Our application is able to use DocuSign REST API to create an envelope for users to sign, and return the signed document to our application once the signing is done.
Recently, the issue is when the document signing has been completed, it is always missing the last signature. For example, we have indicated 3 signers to sign, but in the completed document it only shows 2 signatures.
The missing signature problem only happens to the completed document that is pushed back to our application. When the signers receive the signed document via DocuSign's email, all 3 signature are in the attached signed document.
Please let us know if there is any change to any API recently that cause us to face this issue, or what configuration do we need to fix. Thanks!
You say that your DocuSign "return[s] the signed document to our application"
If you're using Connect or the eventNotifications attribute for this, then you're using the DocuSign webhook system. Check that the webhook events you're interested in only list Envelope Complete. Not Recipient Complete.
Also check if the status of the envelope itself is complete. You've not indicated whether the problem is that the last signer is not asked to sign or if you're receiving a notification before the last signer signs.
If you're using a template, check that the template has not been changed and works as expected when it is sent from the DocuSign web app (vs the API).
Added
In the comments, the OP notes that they:
are using Connect webhooks
are requesting notifications for both Recipient Complete and Envelope Complete
In addition, from the question, I believe that the developer is using the default Aggregate queuing method.
What's happening
When aggregate queuing is used, notifications are initiated when a requested event occurs. But if a second requested event occurs before the notification from the first event is sent, only one notification will be sent for both events, and the notification content will reflect the later (the second) event.
So what is usually happening:
The last recipient signs (completes)
The recipient complete event triggers a notification. It is not yet sent.
The envelope as a whole becomes complete milliseconds after item 1.
The envelope complete event is triggered. The recipient complete notification has not yet been sent.
The notification is actually sent. The notification includes the envelope complete information.
What will sometimes happen:
The last recipient signs (completes)
The recipient complete event triggers a notification.
The DocuSign system sends off the notification. It shows that the recipient is complete but not the envelope.
The envelope as a whole becomes complete.
The envelope complete event is triggered.
The notification is sent. The notification includes the envelope complete information.
Conclusions
If you are only interested in the envelope complete status (everyone signed) then do not request the recipient complete events!
If you want recipient complete and also want envelope complete events, then your application needs to inspect the incoming notification to determine the envelope's status.
Added re why not recipient_complete?
recipient_complete events should only be requested if your application will take action as each recipient in the envelope completes. (A signer is complete when they sign, a cc recipient is complete when the email has been sent to them, etc.)
If your app will only take action when the envelope as a whole is complete, then asking for recipient_complete events too will only cause additional notifications that can be confusing to your app's logic.
In my DocuSign application, I have two recipients that sign documents. When both recipients finish signing the envelope, DocuSign Connect dispatches two identical XML payloads, at what appears to be exactly the same time. This causes issues with my application because I don't want my logic to be duplicated. Is this is a bug in the DocuSign Connect, or is it intentional? I don't think DocuSign duplicated calls when I set up my application two years ago.
Here's an example envelope that appears in the Connect logs in my account:
First webhook call
<TimeGenerated>2020-04-13T10:34:19.1110424</TimeGenerated>
Second webhook call
<TimeGenerated>2020-04-13T10:34:19.1110424</TimeGenerated>
If you're requesting recipient completion events then you shouldn't be surprised to get two notifications, one for each of the two recipients.
They can be the exact same since the default queuing strategy for Connect is for the notification message to reflect the envelope's status at the time the notification is sent, not the status at the time the event triggered.
Suggestions:
Switch to the new queuing strategy, SIM (Send Intermediate Messages). Do this from the Admin tool, in the Updates section.
Only request the envelope completion event, not the recipient completion event.
Update your app to more flexibly handle the notifications. Note that with the default queuing strategy, a recipient completed event will often be skipped in favor of an envelope completion event (if you're asking for both envelope and recipient completion event notification).
The status for the voided envelope is "sent" in the XML POST response for the webhook listener. The document pdf bytes are also in the "sent" status . But the envelope is showing as "void" in the docusign account and the documents are voided too .# Inbar Gazit
You may need to open a case with DocuSign Support and provide specifics such as your account ID and the envelope ID in question.
Are you using an account-level Connect configuration, or are you using an envelope-level EventNotifications definition? Either way, you'll want to confirm what events are set to fire. If you haven't enabled the 'Voided' event, it won't fire.
Are Logging and Require Acknowledgement enabled? If so, you can check the Failure queue to see if the event fired, but was rejected by your listener. Logging will show which events have fired, as well.
Finally, you can use a free service like https://webhookapp.com/ or http://webhook.site to confirm that the data coming from DocuSign matches what you're expecting.
I've already been successfully using the envelope eventNotification webhooks to receive status updates for various envelope and signer events (Sent, Delivered, Completed, etc.), but I'm trying to solve one last event case: adding and removing signers from the envelope.
Suppose in a situation where envelopes are shared among multiple people in a company:
1. Someone creates an envelope through the API, and adds 3 signers.
2. Someone else makes corrections to the envelope using DocuSign's web site, and removes a signer...
Is there any way for my app to know that action #2 took place? Or do I have to wait for one of the regular signer events to take place before I will know that the signers on the envelope have changed?
Connect event triggers for the start and finish of Envelope Correct are a good idea. You'd use the finish trigger to figure out what has happened.
This enhancement request is internally logged at DocuSign as CONNECT-510.
Ask your DocuSign Account Executive or Account Manager to add your organization's interest in the enhancement. It is not yet scheduled to be released, other Connect architectural work is needed first.
The history of the envelope, including correct operations is available from Envelopes: listAuditEvents. You could use that today to see if someone is correcting the envelopes you're interested in.
In our DocuSign Demo environment, we noticed that when several envelopes were voided, we did not receive the corresponding connect events. We checked the connect logs and the envelope ID's are not listed. We checked the envelopes in DocuSign and verified that the envelopes were properly voided. We sent a couple more through and recieved the events successfully.
Has anyone else experienced this issue and if so, were you able to correct it?
I'd suggest you verify the following Connect settings via the DocuSign UI (Preferences >> Connect >> [Connect_Configuration_Name]).
Ensure that Allow Envelope Publish is selected:
Ensure that Envelope Voided is selected, and also that All Users Integrated is selected (assuming you want Connect to send notifications for all envelope void events, i.e., for all Envelope Senders)
Provided that the Connect configuration settings are specified as described above (and logs are enabled via the Enable Log checkbox), you should at least see the Envelope Id in the Connect Log file anytime an envelope is Voided (even if some connectivity issue prevented the message from actually reaching your listener). Also, keep in mind that the Log file only preserves the 100 most recent log file entries -- so if there have been more than 100 messages sent since the Envelope Void that you're looking for in the Connect log, it's expected that you wouldn't see that Envelope Id in the log file.
Working with enterprise support, we determined that our missing connect event problem was caused by using the 'Send on Behalf Of' feature. We were listing the authenticating user in the 'Select Users to Integrate', and needed to list the send on behalf of user.
Also, Require Acknowledgement is NOT mentioned here and can and generally does play into debugging connect issues.
Related article:
Docusign Connect retry frequency when require acknowledgement enabled