Good day to all,
In the context of my project, we integrated Docusign to SAP Ariba CLM (contract Lifecycle management).
We are using the esignature task in our contract workspaces.
Once all parties have signed the contract in Docusign, it takes hours for the esignature task status to move from "signing" to "signed" in Ariba. It also takes hours for the contract signed PDF to be pushed from Docusign to the contract workspace in Ariba.
I have already worked with other esignature providers (for instance AdobeSign) and the update of the signature status took 5 minutes at most.
I think we need to change the esignature status refresh frequency but i'd like to know where this would be done. In Ariba ? or in the DocuSign Account ?
Many thanks for your insights and my apologies for my question phrased with simple words. I'm functional, not technical.
screenshot of the Ariba-Docusign integration configuration
Signature status and document could be transmitted by Docusign to Ariba either through API request or a Connect configuration. You would need to verify what has been implemented.
In the 1st case, it would mean to change the frequency when Ariba makes his API call against Docusign to check the envelope status. If you are in this situation, you should contact SAP support to operate this change.
In the 2nd case, you would need to verify if Connect configuration uses aggregate or SIM (Send Individual Messages) mode. When using aggregate mode, messages are not systematically sent to the 3rd party as soon as a Docusign event occurs, but an algorithm will wait to aggregate several messages together, and could explain the delay you observe
If you are in this situation, you should open a support case to Docusign if you need further help.
The default refresh interval for syncing the task status is 120 minutes. You can create a support request with SAP Ariba to have this updated to be more frequent (the minimum is 30 minutes).
Related
Testing out the platform I was running on both a developer account and a Trial Business Pro account until I purchased a standard plan.
Up until I purchased the standard plan, envelope statuses would update by the second and the functionality built with the Apex Toolkit was working well.
Once changing to the standard paid plan, envelopes statuses take 10-15 minutes to update and some functionality is not working.
My question is:
Do the different plans have different status updating times in Salesforce?
Is functionality of the Apex Toolkit limited between the different plans?
Does the Connect option (which is missing now) have anything to do with the above?
Thanks!
They do not. Writeback to Salesforce takes place via DocuSign Connect. Some plans don't support Connect out of the box but the actual writeback times / delays do not differ between account plan types.
Indirectly, the only way that a plan type can interfere with an API call that worked on another plan type is if it had entitlement to a feature that your new plan does not, IE: The ability to allow Comments, to set recipient signing language, to set envelopeID Stamp Control, etc...
I would highly suspect that it does -- in fact I'm a little surprised that your writebacks are happening at all if you don't have Connect enabled. Salesforce adds an object reference IE: Opportunity / AccountIds to the envelope's custom fields on send. When Connect sees these fields, it knows to write back to that specific object. Without Connect enabled and configured it shouldn't be able to process these writebacks at all.
I think you should have a conversation with your Account Rep first regarding Connect entitlement, then you can reconnect your Salesforce instances to the updated DocuSign account which is something that we can help you with.
Regards,
Matt
Docusign eSignature API has a limit of polling 15 min in 15 minutes for requesting a unique url resources.
However in the documentation it is not explained if normal user behaviour is allowed , which is completely different from polling X in X minutes (e.g. clicking to view an envelope multiple times in a row).
Question 1
Is there a problem in Docusign if the same resource is called multiple times within 15 minutes in normal user actions?
There could be scenarios where the resource needs to be fetched much more frequently within 2 or 3 minutes, but almost 0 the rest of the day for that resource).
Common examples may be: asking for an envelope information, related entities and audit events within a short time span.
Question 2
Do all GET unique resource url have the 15 min rate limiting restrictions in eSignaturesAPI (envelopes, recipients, events, status, templates etc)?
Some documentation indicate only status related endpoints are poll restricted, other docs specify that all GET resources in the eSignaturesAPI are.
Question 3
One alternative for polling is to use Docusign Webhooks (Connect) as suggested in many articles, however to secure it with HMAC, it not possible in combination with oAuth.
The connect keys are associated with the user's account and not the client's app account (each user would have to setup their own keys, which is not feasible). One suggestion seems to be mTLS (which won't be an option).
What other ways exist to secure webhooks when using oAuth?
Wondering how other integrations have done it with the current webhook security limitations.
The reason that DocuSign cares about polling is because developers have built integrations that poll every 1 sec resulting in millions or API calls that clogs the servers.
It sounds like your integration is not doing polling.
Then all you have to do is pass go-live and you should be fine.
The last 20 API calls for your go-live review should adhere to the polling rules, make sure they are so. There's no way for DocuSign to know the intention of API calls, so the polling rule are strict, but they should not be hard for you to figure out.
In my returnUrl handler, I am using list documents.
In the returned array, how can I figure out if the document has been signed or not?
Thanks!
Your return url handler will be called with a query parameter event as discussed in Inbar's answer.
But you should not use the query parameter for making business decisions since a bad guy could easily call your return url and simply tack on an event=signing_complete query parameter--spoofing your application.
Instead, when your application needs to know if the envelope has been signed or not, it has two categories of options:
Ask DocuSign
Your app can call the Envelopes::get method to determine the current status of the envelope. Other API methods can also be used for this functionality.
Design your app such that you do not call DocuSign about a particular envelope more often than once every 15 minutes since such behavior is considered polling and is not allowed.
Webhook: DocuSign will call your app
You can set up a webhook with DocuSign so that the eSignature platform will call your application when the envelope is complete (signed by all the signers, etc).
Use the DocuSign webhook HMAC feature to guarantee that the notification message came from DocuSign (was not spoofed) and that it was not altered in transmission.
By using AWS or equivalent, you can easily receive the notification messages behind the firewall, with no firewall changes. And AWS will not charge you for the first million notification messages per month. See the connect-* repos on github.com/docusign
Dashboards
If your app wants to present a dashboard to a business decision maker about the status of your envelopes, then relying on the event query parameter is fine. But before your app does anything that costs real money, eg initiate goods or services to be provided to a customer, make sure that the envelope has been signed by using one of the two techniques above.
The URL you get back from DocuSign has an event parameter and looks like this:
http://www.acme.com?event=signing_complete
signing_complete means it was signed.
https://developers.docusign.com/esign-rest-api/guides/features/embedding has the full list of other events in the "Determining Recipient Action" section of the article.
We poll for envelopes utilising the listStatusChanges method from the Docusign SDK.
The listStatusChanges call is made with a From date to datetime.now - 10 days with no other parameters.
If we send and complete the envelope within 10 days the completed envelope is picked up.
If we sent an envelope say 10 months ago and it completed 2 days ago liststatuschanges-10 days will not pick up the completed envelope.
What is the determining factor the API uses to decide whether status changes are returned?
I'm sorry that I don't have an answer to your specific question. You may want to consider the alternative of using Connect (webhooks) to receive faster notifications of changes, and more consistent change notifications.
Using AWS, Azure, Google Cloud or other vendors, you can set up your app and receive notifications behind your firewall with no firewall changes or DMZ access needed.
See the code examples for a webhook listener and the behind-the-firewall worker.
I'm using the DocuSign Envelopes: listStatusChanges API to poll DocuSign for updates to envelopes. I'm currently testing this out in the Sandbox environment. The docs say that "you are not allowed to poll DocuSign more than once every 15 minutes" but I've been testing this every 2-3 minutes and not encountering any issues here.
Does anyone know if this 15 minute limit does not apply to the Sandbox environment? I don't have a production version to test against at the moment.
The polling limit does apply to the sandbox accounts but DocuSign is more lenient about the limits in the sandbox platform since it is for development.
Your application will not pass the GoLive testing if it polls more than once per 15 minutes. See Polling Violations on this page.
If your application's polling behavior changes after it is on the production platforms then our automatic monitoring will notify DocuSign staff about your app's violation. The staff will then determine the next step. In the future, actions such as suspending your integration key (client id) may be taken automatically.
Recommended Don't poll. Instead, use the DocuSign Connect webhook feature. If you send your envelopes via the API, then the webhook feature is included with all pricing plans. See the eventNotification attribute of the Envelopes::create call.