It has been more than six years since I started at DocuSign and what a difference six years can make! In 2006 the standard for the home office was to have a desktop computer and a printer in home and for businesses to print/scan/fax/overnight documents for signature. Those on the ‘leading edge’ would email PDFs for signature – all the while worrying about OCR (optical character recognition). Today people and businesses expect all transactions to be done electronically and within seconds. They’re disappointed if they are asked to do it the old fashion way of printing and signing in “wet ink”; and downright irritated when asked to find a fax machine.  

Over the years it has been exciting to help implement hundreds of systems that ditch the old clunky print buttons and replace those processes with DocuSign’s eSignature workflow. So here are some tips I’ve learned over the years and hundreds/thousands of API integrations later on how to help make integrations smooth and seamless:

5. Signers Can Decline to Sign Your Contract

Just because you present an intuitive interface for people to sign a document, it doesn’t mean that they’ll automatically sign it. DocuSign’s system natively supports the signer’s right to decline to sign and your software needs to be able to handle that situation. 

4. You Might Need to Resend a Contract

DocuSign can send out invitations to sign your contract, but the information coming to the API might not be 100% correct.  It could be an outdated e-mail address or people just mistyping information.  DocuSign will let you know that the e-mail has bounced, but your systems should give your users the ability to correct and resend.  This is a common design bug. Fixing it requires extending your user interface.

3. Supporting Datacenters Across the Globe

In the past several years DocuSign has expanded to serve users worldwide.  There are several server farms in North America, the EU and Asia Pacific. A lot of software vendors allow users to use their own DocuSign accounts without realizing that those users can have an account on different DocuSign servers (eg. NA1 or EU1 or somewhere else).  It’s always a good idea to use the login information method and make good use of the baseUrl parameter that shows you where the account resides.

2. Limited Permissions

All the enterprise systems now support custom permissions.  If you are a sales rep you can access a set of objects and if you are an Administrator you can access a lot more.  I see developers run in Admin mode most of their time and then wonder why things like DocuSign Connect events are denied write capabilities.  Don’t be caught unprepared – analyze all your CRUD (Create/Read/Update/Delete) touch points and make sure you don’t assume anything.

1. Accumulation of Data

As your eSignature solution gets real usage, thousands of documents will be sent through the interface. Trust me, with 50,000 new users joining the DocuSign Global Network every day, it goes viral quickly.  The table with DocuSign envelope IDs is going to grow and sooner or later you will need to devise a strategy to deal with a large data set.  It’s best not to wait until your system starts crawling or when you start exceeding the API invocation limit.  The smart thing is to realize that you and your users only care about a subset of stuff.  For example there is a web service call to get a list of things that have changed in the last several hours without having to poll every envelope status.  It’s also smart to figure out that envelopes in final states – completed, declined and voided are never going to change their state.  Get in front of the Big Data problems before they get you.

To learn more about DocuSign API and integration visit www.docusign.com/devcenter.  You can get a free development account, samples, interactive tools and share your tips on the DocuSign Developer forums.

(Visited 82 times, 1 visits today)