DocuSign digital signatures in WEBCON BPS

Applies to version: 2020.1.x and above; author: Mateusz Klos



In WEBCON BPS version 2020, the support for digital signatures has been enhanced by preparing plugins (SDK – Software development kit) that enable digital signing of documents.

Four plugins have been prepared that allow for integration with external digital signature providers:

  • AdobeSign
  • Autenti
  • DocuSign
  • Skribble

The following article describes the process of signing documents by using DocuSign software.

The plugin can be installed in any WEBCON BPS installation that uses version 2020 or higher. You must have the DocuSign account (with the ability of using API) and an integration key generated.

Signing a document – an example of use

In the contract approval workflow, a user registers a document to be signed and enters people who can approve the document. To send a document to a given recipient, indicate their name, surname, e-mail and phone number (optional, if you want to use PIN verification via SMS). At the first step a user can generate a contract that will be added to the attachment section, attach a file from disc themselves, or scan a document.

Fig. 1. An example workflow instance


After adding the document, click the “Send to sign ” path – an e-mail will be sent to the previously indicated people with a request for a signature. These people do not have to be WEBCON BPS or DocuSign users – all you need to do is to enter the recipient’s e-mail and phone number (if verification via SMS is required).

By going through the “Send to sign” path, the document is sent to the recipients who receive an e-mail about the document pending approval. The signing of the document is done via DocuSign page.

Fig. 2. Signing the document by DocuSign


After approval, a sender receives an e-mail informing that the document has been signed. The signed attachment is downloaded after going through the “Signed” path.

Fig. 3. The form with a signed document



A simple workflow of signing a document has been created using the SDK actions dedicated to the integration with DocuSign.

Fig. 4. The signing document workflow


The first step is to add the “SendEnvelope” action which allows you to send the document previously added to the attachment. The configuration of this action may look like this:

Fig. 5. The API setting in the action configuration


In the “DocuSign API settings” section, enter the DocuSign account parameters that allow the use of APIs. This data is necessary for all SDK actions so you can enter them as constants in the process.

In the “Attachment section”, define  the method of attachment selection (by Category or SQL query) and technical form fields to which the ID of the signed document and envelope created in DocuSign will be saved.

Fig. 6. The configuration of the action


In the next fields, enter the title and content of the e-mail sent with the attachment, indicate columns of the item list where information about the document recipients is entered on the form. DocuSign allows you to send several documents to sign – they are sent as one envelope so all of them must be approved for the document to be considered signed.

If you want to use an additional PIN verification via SMS select the “Additional SMS verification” field.

Fig. 7. The configuration of the recipients and e-mail content


After sending the attachment to be signed, the instance goes to the “Waiting for signature” system step. The “CheckAllDocumentsStatus” cyclical SDK action checks whether the document has already been signed. You can add this action in the global actions and their configuration looks like this:

Fig. 8. The configuration of the cyclical SDK action


The configuration includes:

  • The DocuSign API key settings
  • The system step ID where the document waits for a signature
  • The paths ID that the process is to follow when the document is signed (Success Path ID) or rejected (Incorrect Path ID) by recipients
  • The technical field that stores the envelope ID in DocuSign
  • The maximum time of action execution (in seconds)

The action checks (in time intervals) whether the documents that are in the “Waiting for a sign” step received the appropriate status (approved or rejected) in DocuSign. If so, they go to the appropriate steps. The last thing is to add an action that will download the attachment when going through the “Signed” path – in their configuration enter the API DocuSign key settings and technical form fields with the envelope ID in DocuSign. You can also enter a suffix to the file name to distinguish them from unsigned (“_signed”).

Fig. 9. The configuration of the DownloadDocument action


There are several SDK actions that also can facilitate the support of digital signature:

Checking the attachment status – it allows a user to check the document status in DocuSign. The action can be added both on the transition path and in the upper menu.

Fig. 10. The configuration of the “CheckDocumentsStatusGlobal” action


In the configuration, indicate the technical form field which will store the identifier of the file sent for a signature, and the form field where the document status is to be saved.

Sending a reminder – this action is used to send an e-mail to all recipients with a reminder about a pending document to be signed. In the configuration indicate the document ID, field with the current document status saved (a reminder will be sent only for documents that have not been signed yet), and the list of signed people.

Fig. 11. The configuration of the “ResendEnvelope” action


Sign canceled – this action is used to cancel the document signing from the workflow level. In the configuration enter the integration key and document ID in DocuSign. Add this action on the “Cancel” path.

Fig. 12. The configuration of the “BlockEnvelope” action


Signing a document (by a current user)

A person who prepares the document then sends it for approval and signature by their supervisor. When the supervisor clicks the “Approve” button, they are redirected to the DocuSign page for an electronic signature. After signing, the document is attached to the workflow.


The workflow will consist of two actions:

  • SendEnveloperToEmbeddedSign – on the “Send for signature” path
  • EmbeddedSigning – added instead of “SendEnvelope” from the previous scenario on entry to the “Waiting for signature” system step. It is used to redirect a signed person back to the instance in the process.

The “EmbeddedSigning” action should be added on entry because it will allow you to automatically move the instance to the “Signed” step when the document is signed.

The configuration of the “SendEnvelopeToEmbeddedSign” action works in the same way as the “SendEnvelope” action. Enter the DocuSign account parameters, attachment and e-mail settings, envelope, and information about recipients.

Fig. 13. The configuration of the “SendEnvelopeToEmbeddedSign” action


Settings of the “EmbeddedSigning” action:

Fig. 14. The configuration of the “EmbeddedSigning” action


In the “URL to the form” field enter a link where the signed person is to be redirected after signing the document. It should contain:

  • The variable referencing the application where the electronic signature is used (here it is: 71)
  • The ID of the current instance
  • The “Signed” path

The above action allows a current user to send the document to be signed and automatically downloads them back into the workflow.

The SDK plugin allowing the digital signatures in DocuSign is available in the GitHub repository:

Note: Using SDK plugins in WEBCON BPS may require a specific license depending on the version being used.

Leave a Reply

Your email address will not be published. Required fields are marked *