My job? To show you the automation and extension features built into the Spring ‘10 release!

We’ve:

• extended the workflow for new types of recipients in the transaction
• added a way for recipients to collaborate on documents via markup
• added a way for you to build conditional logic for SecureFields™
• created a new way for you to launch a DocuSign envelope
• included many more features

Today I’d like to drill into the new way to launch DocuSign envelopes – the feature we call PowerForms 2.0. PowerForms have existed in DocuSign for a long time and were originally designed to enable sending a PDF form that could be filled in, eSigned, and tracked with DocuSign. With the Spring ’10 release, DocuSign PowerForms 2.0 extends this feature to allow direct launch without the PDF form in the middle of the process and before you know it, we’ve got a whole new protocol!

Previously, if you wanted to create a DocuSign envelope in response to a click on your website you had to write some server side code. While this wasn’t a big issue for a lot of people who already had some back-end systems, those with a Google Site or a pure HTML site had to extend their infrastructure. Now with PowerForms 2.0 to launch a DocuSign transaction all you need to do is create a PowerForm and copy the link to it.

You can send that link via e-mail or add it to your website. In addition to the link, you can add data or recipient information from your site to the URL and that information is inserted into the appropriate fields in the envelope. The data can be passed in the URL or in a form post.

As a proof of concept, we created a small form on a Google site that takes a few form fields and posts the data and the recipient information to a PowerForm. As a result, without any code (JavaScript or back-end code like C#, Java or PHP), a new envelope is created and we have an integrated solution.

Here is the form (you will need to map it to your own PowerForm link of course).

Which looks like:

Google Sites Screenshot

For more on the PowerForm data syntax see the PowerForms User Guide

Want to inject DocuSign’s electronic signature capabilities into your existing technology? Take a look at the DocuSign eSignature Developer Center and register here for a DocuSign Developer account for free access to the leading eSignature API and SDK!

Step 1 – Procure an X509 Certificate

• To get BinarySecurityToken working with Java, procure an X509 Certificate. While getting an X509 certificate is beyond the scope of this blog post – you might want to try searching for “SSL Certificates”. SSL transport protocol uses X.509 certificates for encryption.
• DocuSign supports certificates issued by certificate authorities included in Windows2003 servers. The most widely used certificate authorities are Thawte and VeriSign. Additionally, our Demo server farm support CACert.org certificate authority, which enables you to get a certificate without having to pay for it.
• Keys are generally distributed in PEM, PFX or CRT files. You will need one of these files prior to proceeding with this walkthrough.

Step 2 – Generate a Java KeyStore

• Java has its own keystore format which requires the use of its own tool – keytool. In my experience, I had started with a PFX file. To convert to the Java Keystore format, I had to go through a number of cumbersome steps. Then, one of our customers, Gloria Zhang, pointed me to a blog post about a very nifty tool: http://erlend.oftedal.no/blog/?blogid=68
• Using the steps in that tutorial, I created an esign.jks file.

Step 3 – Configure Axis2 to generate electronic signatures

• We’ve prepackaged samples to generate the right configuration files when you want to use XML signatures. I suggest that you start with working code from the DocuSign SDK and plug in your keystore file. This minimizes the number of things that can go wrong.
• You will need to plug in some important information about your keystore into the build.properties.x509 file. Once you plug in the (1) keystore path, (2) alias of the certificate and (3) password, you will need to issue “ant war-x509” command to build the web archive for deployment.
• If you were to examine the build configuration, you should see the following things in your axis2.xml config file:
• <items>Signature UsernameToken Timestamp</items>
• Elements such as ≤signatureCrypto> in the OutflowSecurity portion of the configuration.
• A cert.properties file that seemingly has a set of information that is already provided in axis2.xml. This may be there for historical reasons.

Step 4 – Testing

• Once you have established that the application is still functioning and making web service calls, the next thing to examine is the SOAP calls. LoanSample comes pre-packaged with log4j integration that dumps out the HTTP wire calls. You can find the SOAP requests and responses there.
• In my experience, opening the SOAP requests and responses in an external editor and cutting and pasting the appropriate sections makes them easier to read. After all the edits, you should see your requests to DocuSign web services. Those requests will have the UserNameToken and also BinarySecurityToken element in the headers. The BinarySecurityToken will have signature information and signature value.
• The final test is contacting your DocuSign representative and asking them to turn on XML signature validation on your account. This request should be accompanied by a public export of your certificate. Make sure you do not include the private key in your request.

While configuring XML signatures in Java is an advanced topic that requires that you master servlets, axis (or a similar framework), and PKI file manipulation, you can also work with DocuSign to ensure the correct configuration.

After all the settings are correctly configured, DocuSign will know that the web service calls were generated only by an application that had access to the X.509 certificate file. Enterprise IT operations put a lot of emphasis on the security of the certificate files, so you can enjoy the benefits from the internal infrastructure.

During design sessions and analysis of the credit union and county government, we realized that many of the forms for county are self-service forms.

License renewals and various applications used to sit in the office. One had to stop by to fill them out. Recently, things have changed a little bit. Many of these paper processes went to “half paper,” meaning that a PDF was available on a publicly facing website. One can print out the necessary form, fill it out and then mail or fax it in.

To be fair, some of these processes went to full web-based applications with web forms. Unfortunately, changing one of these applications or updating the forms requires that the county work with the IT department and change the relevant web pages. After some software development, testing the new process, and deploying the updated web app, the county now has two radically different processes. One is the “half paper” process, or a form with pages. The web-based application usually looks like a web interview.

Fortunately, DocuSign integration gives you the best of both worlds! Here is the self-service pattern when you have DocuSign electronic signature integrated into the forms process:

1. The county stands up a self-service web page with a list of self service forms, and these minimum three elements: name input, e-mail input and “Send me forms” button.
2. Behind the scenes, DocuSign templates have a “Signer” role and a “Processor” role with a defined recipient.
3. The self-service web page has a form post handler that takes the information about which form was selected and the recipient information. The form post handler makes a call to CreateEnvelopesFromTemplates

What does the user experience look like?

1. A user goes to the self-service webpage and selects the appropriate form.
2. After filling out the requested information, the user clicks on “Send me forms”
3. The form handler directs the user to check their e-mail.
4. The e-mail contains a DocuSign envelope activation link.
5. The user clicks the link, taking them to an electronic form that looks just like the familiar paper form.
6. The user e-signs the form to complete the process.

With DocuSign’s carbon copy feature, the processor gets a fully completed form with all the form field validation and a complete electronic signature.

All the automation and filing possibilities can take place from here. For example, if someone gets a large number of forms – you can leverage e-mail rules or web services to file the forms where appropriate.

The DocuSign API allows one to take the data fields and through web services, populate databases or kick off other workflow processes.

One of the common questions I get is: “How do I know that people are not just sending forms and signing using a fake e-mail?”

DocuSign’s integration with RSA ID Verification technology enables you to set up ID Verification. The ID Verification can be set up on a per role basis and it can be dependent on a form.

In short, I’m seeing this very powerful, yet simple pattern starting to emerge. You can implement this solution for any organization with downloadable PDFs or a stack of forms waiting for customers to sign.
–mb

PS: For IT folks – there is just one web service call to learn.

Demonstrate Use Cases
To schedule a Certification, your application needs to be close to complete. We understand that you will keep innovating in your space and continue converting more document execution to DocuSign. For us to get the proper context, we need to see at least a Beta.
Most of the applications we certify have multiple use cases. If only select use cases deal with electronic contract execution or electronic signatures, we recommend isolating your DocuSign use cases and preparing data, if possible, to provide the most benefit.
For example: What if your user needs to establish an account, input 3 screens of data and then sign the appropriate application? You can pre-create a user with all the data entered prior to Certification.
Commonly missed edge use cases:
1.    Users can decline to sign: DocuSign interface supports that.
2.    Users can take several sessions to sign: DocuSign allows someone to review the document, leave the signing experience and come back later to re-start signing.
3.    Network connectivity issues: Network code needs to account for circumstance. You can simulate that by plugging in the wrong web service URL.
4.    Mistyped username or password: While it’s unlikely that your API enabled user account will mistype passwords, you do want to be ready when someone resets the password through DocuSign account management console.

Timing
You might get some actionable feedback during the Certification process. That means your code, your workflow and maybe your configuration may need to change. If your company has actively engaged DocuSign Professional Services, then most likely you will have no surprises waiting for you. However, if you were coding on your own, it’s probably best to structure additional review time in your schedule to ensure sufficient time in your application release cycle.
Keep in mind that DocuSign Professional Services are booked out about 2-3 weeks in advance. The earlier you can let your account manager know that you have a new application getting ready to certify, the better.

Participants
During the Certification, your sustained engineering staff and the implementation team will be introduced to DocuSign developer support, operations and escalations personnel.
One of the goals of certification is to ensure that, in case of an emergency, precious time is not wasted determining who needs to be contacted and who can fix the business critical systems.
Re-certification: “When Do I Need to Re-certify?”
Given the fee associated with the Certification, it’s natural to try to minimize the number of Certifications. That’s a fine strategy as long as the supportability of your application doesn’t suffer.
In a case where you are adding more signatures or documents to the same process, it’s probably not going to change the calls or architecture of the application. You can continue innovation on that scale without looping DocuSign in. However, if you introduce a brand new module, change frameworks, or change programming languages then you might end up in a situation where the DocuSign documentation on your solution is out of date. Contact your Account Manager!

Summary
Please let us know if you need additional clarity into the certification process and our expectations. As mentioned above, the latest checklist can be obtained from your DocuSign Account Manager. While the contents of the Certification Checklist are constantly refined and improved, the spirit of ensuring quality, supportable integrations with DocuSign service remains the same.

General Contract Signing Process
The following stages represent a generalized, high-level cycle for any contract signing process. Without DocuSign, the contract signing process is “print-ship-sign-copy-return-scan”.

Stage 1: Document and Envelope Preparation
During this stage, the sender will provide transaction data and instructions. This information might come in manually or automatically from a variety of the data sources. The sender will add documents, templates, signing locations, initials locations, data fields, recipients, and reminder and expiration information. Without DocuSign, the sender has to print the documents to paper, ensuring sufficient print time and printer ink.
With DocuSign, you can work with the DocuSign team to automate this stage according to your business specifications. The documents and envelope will be ready to be sent at the completion of this stage.

Stage 2: Transaction Execution
Stage 2 begins when the sender sends the envelope of documents. Without DocuSign, this might entail faxing every sheet of paper and confirming receipt. If the documents are overnighted, someone must either drop off the envelope or schedule a pickup. Then the sender must wait for the recipient to receive the documents. If a critical page is missing or illegible, there may be emails, phone calls or other back-and-forth communication. The recipient must also be physically available to wet-sign. Last minute business trips or other delays can add days to this process.

If the sender were to use DocuSign, the DocuSign services execute all of the actions defined in stage 1 once the envelope has been sent. The envelope is routed via email to the proper recipients in the appropriate order. The recipients enter the required data (as applicable) and electronically sign and initial (as applicable) in all the required locations. Senders can control what happens to an envelope after it has been sent. For example, a sender may correct an e-mail address in case it was mistyped, a sender may stop execution and void the entire transaction before completion. However, more major changes are not allowed without first voiding. For example, senders cannot add an addendum after a signer has signed.

Stage 3 – Filing and Storage
After the transaction has been executed, contracts are typically filed and the data is manually entered into business systems. Sometimes other processes are initiated.
With DocuSign implementation, the filing and storage stage can be automated with some amount of investment.
This discussion of a high-level, generalized contract signing cycle provides a process framework for understanding where and how automation using DocuSign electronic signature and online contract execution adds value. The next section describes how to leverage DocuSign technology and service to automate your contract execution process and turn it into electronic contract execution.

Degrees of Automation
DocuSign offers a web interface, desktop software, and an application programming interface (API) called DocuSign Connect. These different options apply to all three stages in the lifecycle of a contract.

Web interface
The DocuSign web interface allows a user to send, sign, add data, initial, download, and get status of documents. The flexible WYSIWYG interface allows users to get started immediately and work from almost anywhere. Anyone who can use e-mail and a web browser should feel comfortable interacting with the system very quickly.

Standard automation solutions
In addition to the web and software solutions, the DocuSign service provides several standard solutions which automate steps in the electronic contract execution process.

These solutions allow you to:
•    Create a DocuSign envelope out of a blank PDF form using DocuSign PowerForms,
•    Automate document and envelope sending with DocuSign desktop software,
•    Automate data entry of status updates and data collected during the electronic contract execution process to SalesForce with DocuSign Connect for SalesForce,
•    Automate document and data retrieval from the DocuSign service to a server behind your firewall with DocuSign Export,
•    Automate the transport of the authoritative copy of documents to another secure location with eOriginal Vaulting.

These solutions require configuration and possibly installation. The target audiences for these solutions are office “power users” and IT administrators.

Application Programming Interface
The DocuSign API, DocuSign Connect, allows other systems to interact with the DocuSign service and automate the processes around sending, correcting, status, and download.

DocuSign Connect is exposed as a standard SOAP XML Web Service, protected by transport level security and message level security based on WS-Security standards.

DocuSign Connect enables greater automation capability. The most common automations are:
•    Automation of sending process: Senders can send documents with one click. This requires additional programming by the DocuSign customers. This programming enables the automatic selection of the document, data collection requirements, and signers. Using this capability, step 1 of the electronic execution process can be almost entirely automated.
•    Store and update documents and data automatically: Using data from DocuSign Connect, update internal systems with documents, data collected, and status information. DocuSign Connect provides all the information about the transaction at any point in its lifecycle. These capabilities can automate most of the processes in step 3 of the electronic contract execution process.
•    Embedded signing experience: You may embed the DocuSign signing and data collection processes in your portal or website using an IFRAME. This capability keeps your brand in front of the signers at all times in the electronic contract execution process.

A shared understanding of the general contract signing process and how DocuSign’s electronic contract execution process differs enables you to think about which steps of the process are repeatable and appropriate for automation. Understanding the various options around creating an automated electronic contract execution process for your organization and how they each fit into the contract lifecycle may help you communicate the value of adopting electronic signature and ECE technologies and processes.

Business Analysis of ECE Implementation, Part 1: Introduction to ECE & DocuSign Terminology

How can you improve many aspects of your business processes and finances? Implementing Electronic Contract Execution (ECE) can help you realize gains in business processes and positively affect your bottom line.
Electronic Signature and Electronic Contract Execution will:

• Save time,
• Reduce costs,
• Improve the quality and accuracy of data collected on contracts,
• Shorten contract signing cycles,
• Improve close rates, and
• Increase revenues.

Signers in the electronic contract execution process report greater satisfaction with the new process, influencing increased customer satisfaction rates.
ECE also is on strategy for environmental or green initiatives by reducing paper consumption and fuel consumption. This ultimately results in a smaller carbon footprint by your company.

Choosing the right tools
The DocuSign service offers flexibility in how you gather data and signatures. Finding the right fit affects the project implementation and cost. We advise you to envision the final solution and map out your desired data flow prior to estimating the project cost.

DocuSign terminology
We use the following terms when speaking specifically to DocuSign’s electronic signature and online contract execution offerings:

Envelope
A collection of documents, signer(s) information, and signing instructions are packaged together in an envelope. This may have any number of signatures placed on any number of documents and may include as many signers as needed. Upon submission to DocuSign, an Envelope ID, displayed in the upper left corner of each page in every document in that envelope, identifies the envelope.

Signer
A full name and e-mail address uniquely identifies a signer. A signer has a user record in DocuSign and can be invited to place signatures on an envelope.

Sender
A sender is a user of the DocuSign service and may sign as well as send documents.  Some sending accounts are created for Web Service access enabling these senders to send documents from other systems via DocuSign.

Account
An account maps to an organization, which can be either a company or a department, depending on company size. Senders belong to an account and are referred to as members of that account. In the DocuSign system, the account gets billed for transactions.

Tab
A tab is a visual indicator on a document for a piece of data: a date, initials or a signature. The most common tab is a signature tab. Other available tabs include: initials tab, full name tab, date tab, text box, checkbox, radio buttons, drop down lists and several others. Generally, tabs as data added to the document by signers as a result of completing the ECE process.
Tabs may be placed manually (ie the sender drags and drops the tabs onto documents) or in an automated fashion via the Web Service interface. Some types of tabs can be used to collect data and/or be configured to restrict data entered to conform to a specific format such as for dates and credit cards.

Certified Delivery
Certified delivery allows you to send a document to a recipient for review purposes only. The DocuSign service records that the certified delivery recipient has read the documents, similar to a “read receipt” in email.

Carbon Copy

Carbon copy allows you to send a document to a recipient for viewing after all parties have signed the document.

A common understanding of the benefits of electronic contract execution (ECE) and terms used to discuss the business implementation and desired solution(s) of the DocuSign service lays the groundwork for further analysis and discussion.

Whether or not your application is installed or delivered as a service, integration with web services such as the ones delivered by DocuSign requires a shift in user interface, support and architecture.

The cost of adopting the new paradigms are often less then the benefits you receive by utilizing the services oriented architecture (SOA). In this post we will examine the benefits, architecture considerations, implementation guidelines and support for an application integrated with DocuSign web services.

The target audience of this post are enterprise software architects and technical project managers that are designing an integration with DocuSign web services.

Benefits
ISO 9126 is an international standard for evaluating software quality.   There are six main characteristics and utilizing DocuSign web services directly contributes to all of them.
1. Functionality
As you are considering executing contracts electronically or just gathering electronic signature you should keep in mind that stated requirements are most of the time are missing the full scope.

In addition to end user stated functionality electronic signatures have a number of applicable laws. Utilizing a commercial web service eases the burden of figuring out the details.  The service providing the full range of options can have immediate return on your investment or most likely will have a return in the near future.

Before you decide to build your own or buy a limited service it’s generally a good exercise to ask your users if any of the additional features could be applicable to their contract execution.  These are the types of questions that can help you figure out the evolution of requirements: “Dear Project Stakeholder, I know you are saying that right now all you need is a signature on the last page, but do you foresee us executing contracts that might require signatures on multiple pages?  Could initials come in handy?  Do we need to collect any data with this contract or just get the signatures?”
2. Reliability
Enterprise ready commercial web service providers such as DocuSign host their solution in a secure and reliable data center.  There are personnel controls, audit logs and secure storage utilized to make sure that the solution and the data are well maintained.  In case of a forensics exercise or data loss by your application the secure audit log at DocuSign will still maintain that your documents were signed.

In addition to the operational reliability the software releases by an enterprise ready web service provider go through test passes and beta testing by other users of the web service.]
3. Usability
Commercial web services can leverage economies of scale and invest more in user interface and application interface.  DocuSign continuously invests into ease of use both by end signers, senders and developers.

The usability improvements are then vetted and confirmed by thousands of signers that interact with the service every single day.
4. Efficiency
One of the biggest wins when utilizing SOA is that the resource cost of executing the transactions is equal to the cost of making a call to the web service.  That’s a miniscule impact in comparison to what the web service provider needs to invest in to support presentation, conversion, cataloging and archiving of the electronic contracts.
5. Maintainability
Web service provider maintains the solution and fixes any issues.  In addition to your staff not having to fix issues, the issues found by other users by the web service are also fixed and immediately delivered to you.
6. Portability
Utilizing a standards based web service rather then an installed behind the firewall system allows you for maximum portability of your application.

First the application physical location is flexible.  You can access the commercial web service from any location with connectivity to the Internet.

Second the standards based SOAP API allows you to utilize any operating system or technology that supports that interface.  Most of the application stacks in use today support SOAP and XML.

Billing Information
Commercial web services need to support a billing configuration.  When architecting an application you need to consider the following billing relationships:
1)    You are going to purchase a subscription to the web service and deliver the application pre-configured and ready to go.
2)    You are going to ask your clients to purchase a subscription to the commercial web service.

The first configuration is probably easiest for deployment because the billing information is static.  When a new client starts using your application they don’t have to purchase a subscription to DocuSign services.  The burden of billing and possibly pre-paying for the subscription is something your system has to manage.

The second configuration will leverage DocuSign billing infrastructure but will have an up front cost of setting up a DocuSign corporate account and plugging that information in.

From a software architecture perspective the credentials that identify an account on DocuSign system are going to be global or stored in a customer record.

Application Configuration
Most user friendly applications have a configuration page that allow the administrators to make changes without having to recompile or re-deploy the application.

Depending on the choices you made for the billing configuration between your application and your clients the configuration page is going to be global or on a per user basis.

It’s important to make sure that the configuration is limited and secured to the users that know how to properly configure connection to DocuSign web services.

There are also web service methods that can be used to make configuration easier.  Login method allows your application to get the web service credentials by supplying an e-mail and a password in a human readable form.  DocuSign also supports a Ping method which doesn’t validate credentials but returns True if you are successfully connecting to the web service end point.

DocuSign has several server farms:
a.    Production (www.docusign.net) – this is where legally binding contracts are processed.
b.    Demo (demo.docusign.net) – used for development and is free for customers to test against.  The code mirrors production exactly, the data is separate.
c.    Preview (preview.docusign.net) – used to give customers early access to the upcoming versions of the web service.

A full DocuSign configuration screen should contain the following elements:
1)    E-mail
2)    Password
3)    Billing Account selection (one e-mail and password could belong to several accounts)
4)    Web Service URL selection (demo/production/preview)

If you opt out of using the Login method and would like to obtain web service credentials directly your screen should at least contain these elements:
1)    Web Service User ID
2)    Account ID
3)    Password
4)    Web Service URL selection (demo/production/preview)

We also suggest that you add a “Test” button that uses Ping and Login method for basic checking.  It will save you time on generating a real transaction in order to just test whether the configuration is correct.
Support Considerations
Your application is likely to have it’s own screens, processes and data flow.  When an administrator or an end user is looking for help you need to provide functionality that will enable them to get help from DocuSign.

DocuSign deals with millions of different contracts and hundreds of integrated applications.  In order to help DocuSign developer support troubleshoot the errors we suggest you build in logging that shows what the requests and responses were at the web service level.

Different technology stacks support various methods for enabling tracing of web service calls.  When you escalate a support request to DocuSign you should have these key pieces of information – XML output of the web service call that is failing, XML response from DocuSign web service, Envelope IDs that are exhibiting problems, web service URL that you are interfacing with.

We suggest devising a configuration screen or a report that will allow an IT Operation person to generate the above-mentioned output.  Having that information handy is going to enable us to service you a lot quicker.

Meta Data Linking
Most integrating applications extend their workflow and replace what used to be a faxing or printing functionality with DocuSign electronic contract execution.  From a system level you will be using an external data source for some of your data.  The data needs to be correlated between the two data sources to provide a coherent view to the end user.

DocuSign transaction containers are called Envelopes and every single envelope has an envelope ID.  An appliction that creates or references those envelopes should at the very minimum store the envelope ID in one of its tables.

Envelopes also have Custom Fields.  Those are places where arbitrary data can be placed.  If you are looking for a bi-directional data linking you can use these fields.  Commonly applications store things like account ID or transaction ID in the envelope custom fields.

Given the envelope ID you can control the envelope and maybe most importantly gather the data from a completed envelope to update your application state.

For example when envelope completes you might want to change the customer record in your application and move forward in the business process.
Multi Tenant Support
Often applications will support having several companies in one data store.  For example SalesForce.com supports thousands of tenants that all have their own configuration and are expecting SalesForce.com to keep their records private and secured from each other.

When integrating with DocuSign web services you need to keep in mind that every tenant in your application might want to plug in their own web service credentials in case they have a DocuSign subscription already.

The configuration screens, data tables and onboarding procedures need to take this into account.  Consequently any support escalating from one of the tenants of the application might be due to the fact that the settings in that tenant’s DocuSign account are incorrect.

A common scenario is a changed password.  A new password would invalidate existing web service credentials for one of the tenants and the web service calls are going to generate “Invalid User Name or Password” credentials.

X509 Certificates
A few of DocuSign’s web service calls are secured with an additional level of security.  The security based on WS-Security standard is utilizing a binary security token generated with an X509 Certificate.

These certificates need to be issues by a well known certificate authority such as Thawte or VeriSign.  The certificates also tend to have an expiration date.

If your application is using the methods that require a functioning certificate you need to make sure that the certificate doesn’t expire.  If you are not careful then one day with no code changes and no data changes the web service calls might start failing.
Other Considerations
Some businesses have additional requirements:
1)    What kind of identity verification is necessary for the signers?  DocuSign supports scalable security around signing from a unique activation link sent to the e-mail to RSA integrated ID Check system.  Increased levels of security generally make getting to signing harder and have different costs associated with them.
2)    Has your development team implemented Web Service connectivity before?  If not we strongly advise you to get help from a knowledgeable integrator or from DocuSign Professional Services.
References:
http://en.wikipedia.org/wiki/ISO_9126