Special Considerations For Envelope Submissions

Last updated 2016-08-11 14:10:51 UTC

AssureSign supports the concept of grouping documents into a single envelope. This allows for scenarios where it is desirable to provide a single signing session that can be used for managing the signing of multiple related documents.

In its most basic form, the envelope setup process consists of several calls made to various DocumentNOW operations:

  1. A call to the CreateEnvelope operation will create a new document envelope entity and return an EnvelopeId.
  2. One or more calls to one of the Submit operations can be made with the EnvelopeId obtained from the CreateEnvelope call used to ensure that the new document(s) are added to the new envelope.
  3. After all documents have been added to the envelope, a call to the CloseEnvelope operation will finalize the envelope so no more documents can be created and will initiate workflow for the document(s) in the envelope.

Once a new envelope has been created, it can be managed using the other envelope operations which function similarly to their document operation counterparts (ex. CancelEnvelope vs. Cancel, CheckEnvelopeStatus vs. CheckStatus, etc.).

Consistency of Signatory Information in Envelope Documents

When adding a document to an envelope, signatory email addresses are used to link signatories across documents. Consequently, signatory email addresses must be unique within an individual document. In addition, signatory attributes such as first name, last name, and password must be specified consistently across documents for any given signatory.

For Example:

Assume that a first name of “John” and a last name of “Doe” are specified for signatory 1 ( in the first document added to an envelope. If that same signatory is going to be signing document 2 in the envelope, his email address, first name, and last name will need to match what was specified for that signatory in document 1.

Special Considerations for using Knowledge Based Authentication(KBA) on Envelope Documents

The presence of KBA is defined on a signatory basis within document templates. In order for a signer of an envelope document to be presented with KBA questions, then the first instance of a signatory within the envelope must define that KBA should occur, and if required, must specify the KBA related parameters. And subsequent documents must provide a consistent set of KBA parameters.

So, if signatory A should sign document 1, 2 and 3 within an envelope, and KBA should be used for authenticating signatory A, then:

  • the template for document 1 (the first document added to the envelope) must have KBA present for signatory A
  • subsequent documents 2 and 3 must have consistent KBA parameters present for signatory A

If signatory B should sign document 2 and 3 within an envelope (and is not a signer on document 1) and KBA should be used for authenticating signatory B, then:

  • the template for document 2 must have KBA present for signatory B
  • subsequent document 3 must have KBA present for signatory B

The important thing to remember is that Knowledge Based Authentication must wrap the access to signing of all documents a signer must sign, and the document which defines the first instance of a signatory must define the KBA related parameters. And while the following templates for a signatory might not have KBA defined on them in the workflow design, the KBA parameters should still be submitted for them in cases of envelope inclusion.