AdobeSign digital signatures in WEBCON BPS
Applies to version 2020.1.x, author: Anna Puka
Introduction
Digitally signing attachments ensures the integrity and authenticity of approved documents and improves the entire approval process. This is especially important now when more and more businesses are choosing to allow remote work and have little time to implement a paperless office model. The standard WEBCON BPS functionalities allow both digital and electronic signing of documents using:
- certificate applied to a document via appropriate action
- personal signature applied by the user directly on the form
From version 2020, the ability to make the electronic signatures in WEBCON BPS has been enhanced with SDK – dedicated plugins enabling integration with the electronic signature providers:
Thanks to the integration with these solutions, not only can WEBCON BPS users sign/approve the workflow attachments, but also any person to whom the document will be sent can do so as well. For each of these providers, a dedicated action allows you to: send documents for signing, verify their status, and download the signed attachments. These actions are an addition to the platform, not part of the standard software. Thus, they are not delivered with WEBCON BPS version, but at the client’s request.
This article describes how to configure the AdobeSign integration plugin based on two business scenarios.
Basic requirements
Implementation of the electronic signatures by using AdobeSign requires:
- WEBCON BPS 2020 or higher
- Uploading the plugin
- Integration key to the AdobeSign account along with the ability to use API interfaces
First scenario
A user prepares the document to be signed and then adds a list of people who should approve it.
Fig. 1. Preparing the document form
When a user clicks the “Send to signature” button, each of the indicated people receives a link to the document to sign. People signing the document do not have to be WEBCON BPS users or have an AdobeSign account. The only required element is an e-mail address and phone number (if you want to also use the PIN code sent via SMS).
Until all the indicated people sign the document, the workflow waits in the “Waiting for signature” system step.
Fig. 2. The “Waiting for signature” system step
After approval, the document is automatically sent to the next step (the “Signed” step) and the attachment is downloaded.
Configuration
The following diagram presents the simple workflow which can be added to any existing process.
Fig. 3. The workflow diagram
First, add an action which allows you to send a document (PDF attachment) for signing. This action should be added on the path from the step in which the document was prepared or attached to the “Waiting for signature” system step.
Fig. 4. The configuration of the “SendEnvelope” action
- AdobeSign API Settings – enter the integration key assigned to a given AdobeSign account. This key is required in the configuration of all actions in this plugin, so it is a good idea to define it as a constant in the process.
- Attachment selection – indicate:
- The method of attachment selection -> based on the attachment’s category or SQL query
- The technical form fields to which the attachments’ identifiers will be saved
- Message content – enter the title and content of the message sent with the attachment
- Recipients selection – in this section indicate the item list from which the list of people that need to sign the document will be downloaded, and fill out the fields about SMS verification (it is required)
Fig. 5. The “SendEnvelope” action configuration
In the “Waiting for signature” system step, the instance waits for the document to be signed . The “CheckAllDocumentStatus” cyclical action was created to automate attachment status verification and move the instance to the appropriate step.
Fig. 6. The cyclical action configuration
In addition to the AdobeSign key, there are more parameters that you should configure:
- Step ID – the ID system step in which the documents are waiting to be signed
- Success Path ID – the path leading out from the “Waiting for signature” step which the documents are to take after the document is signed
- Incorrect Path ID – the path leading out from the “Waiting for signature” which documents are to take if the document will be rejected
- Document ID field name – the technical field containing an external document ID
- Execution time – the maximum time of the action execution
In this example, the cycle is executed once every 4 hours. In each cycle the action checks the status of all documents included in the “Waiting for signature” step and, if their status has changed – moves them using one of the indicated paths.
For the above action to work correctly, you have to add the action that downloads the signed attachment (“DownloadDocument”) when going through the “Signed” path. In this action configuration, re-enter the AdobeSign key and indicate the technical fields with information about the uploaded file. Also you can indicate the suffix and category to which the downloaded attachment should be added.
Fig. 7. The action configuration
After creating the action of downloading the attachment, you can test the first scenario.
In addition to the scenario above, you can add three actions for supporting and improving the electronic signatures workflow.
- Checking the attachment status – the action allows you to check the current document status in AdobeSign. They can be added both on the transition path or as a menu button on the form ribbon.
Fig. 8. The action configuration
In the configuration, indicate the technical form field in which the file identifier is stored, and the target field on the form where the document status should be saved.
Sending a notification – this action allows you to send an e-mail to all signers of the document with the notification. In the configuration, indicate the document identifier, field in which the current document status is saved (the notification is sent only for documents which have not been signed yet), and the list of signers.
Fig. 9. The action configuration
Canceling the document signature – this action allows a user to cancel the document signing from the workflow level. To configure such an action, you must enter the integration key and document identifier in AdobeSign. This action should be added on some sort of “Cancel” path, so that you can add verification on that path and force the user to provide some reasoning for the cancelation.
Fig. 10. The action configuration
Second scenario
A person who prepares the document sends them for approval and signing by their supervisor (also a WEBCON BPS user). The supervisor in the “Approval” step verifies the document and sends them for signing. At the moment of clicking, they are moved to the AdobeSign page to make a signature. After signing, the approved document is attached to the workflow.
Configuration
To implement the second scenario, a similar workflow as in the first scenario can be used. The only difference will be to remove the action of sending documents for signature (“SendEnvelope”) on the transition path, and instead adding the “SendEnvelopeToEmbededSign” action on entry to the “Waiting for signature” step. This action should be added on entry to the step because this will allow you to automatically move the instance to the “Signed” step at the moment of signing the document.
In the “SendEnvelopeToEmbededSign” action configuration, fill out the connection parameters and the method of attachment selection (like in the “SendEnvelope” action). In the section of recipients selection, instead of the item list, indicate the name, e-mail, and phone number of the current user.
Fig.11. The action configuration
The last parameter that should be provided is the link to which the person is to be redirected after signing the document. The following link was used in the example:
https://poc.webconbps.com/db/1/app/{AP:71}/element/{WFD_ID}/form?PATH_ID={PH:1125}
where:
- {AP:71} – variable on the electronic signature application (application ID: 71)
- {WFD_ID} – the current instance ID
- {PH:1125} – the „Signed” path (ID: 1125)
By using the functionality of following the path via URL, you can automatically redirect the user to the “Signed” path on which the signed document is downloaded.
By adding the above action to the workflow, the document will be sent to be signed to the current user and automatically loaded back into the workflow, where it can be further processed.
The SDK plugin that enables digital signatures is available in the GitHub repository: https://github.com/WEBCON-BPS . Please note that this is just a sample plugin, delivered under this license.
Note: Using the SDK plugins in your WEBCON BPS environment may require an appropriate license depending on the version you are currently running.
+48 12 443 13 90