We decided to create a more powerful Adobe Sign workflow experience in a new ProcessMaker I/O use case. You can see the use case and how it was built by clicking here.
The objective of the use case was to improve the performance of the Adobe Sign Web Widget. This is a very useful widget. The classic use case for the widget is a real estate rental company or equipment rental company that wants to put a copy of its contract on a website so that users can come to the website, fill out the agreement, and sign it with the rental company. This is a common “one-to-many” scenario. In this scenario, one company offers one contract type which can be signed with a single user.
We can imagine another situation which adds a little bit of complexity. What if we need to allow for two signers? Well, this scenario is also very easy to handle. I simply need to route it to a second signer after the first signer and then back to the company.
The Next Level of Complexity
So far these use cases are not too special. However, let’s imagine a third scenario. In this third scenario we will need a more powerful adobe sign workflow. The third scenario is one in which I may or may not have a second signer. It is conditional. This means that my routing engine has to be smart enough to handle the addition of a co-signer and only route the document to the co-signer when and if there is a co-signer. If there is no co-signer, then the signature procedure should occur as usual.
This is a scenario that cannot be handled today in the Adobe Sign widget. So, if we want to do this we will need a way to make a more powerful Adobe Sign workflow.
Using ProcessMaker I/O for more powerful Adobe Sign Workflow
In order to show how ProcessMaker I/O could be used to interface with Adobe Sign and create a more powerful Adobe Sign Workflow, we created the workflow pictured below. We wanted to show how a user could come onto a website to initiate a workflow for document signature. Instead of using a web page, we decided to leverage the Slack connector that we created for some of our earlier examples. The idea of filling out a web form or using a Slack “/” command to start a workflow is basically the same. In either case, I am going to hit enter and then submit a few fields of information and call a web hook to start a ProcessMaker process.
In the picture below the process lane on top represents everything that is done before the signing process happens. The Message Event (the black envelope) is where the magic happens. When I click save on a form or enter after my Slack command, I am essentially submitting the information and calling a webhook. The second process starts with a message receive event. The message receive event is “listening” for any call that wants to generate an instance of the process. This message receive event is sitting inside a ProcessMaker I/O engine instance which is always on and always listening. This is the beauty of a cloud workflow API – it is there and ready to be used.
Handling a Second Signer
Once the signing workflow is kicked off, the second swim lane shows how the process gets handled. The important part to see in this second swim lane is the second gateway or decision point. At the second gateway, the process asks the question, is there a second email – yes or no? The second email is a field that is inside the Adobe contract that we kicked off. This second email will be filled out if, for example, there is a co-signer or co-borrower. If there is no email, then the signature ceremony ends. However, if there is a second email, then we will send the document to the second signer, we will add a field for the second signer’s signature, and we will proceed to obtain his/her signature.
While all of this activity is going on, we will also notify the slack channel of our progress.
A World of Possibilities
You can see how by adding ProcessMaker I/O and its powerful API to Adobe Sign, we have created a more powerful Adobe Sign Workflow. The Adobe Web Widget is great and very popular. However, imagine all of the use cases where more powerful Adobe Sign Workflow would be useful – signature ceremonies with co-borrowers and co-signers for example.
