The Scrive Flow API
Traditionally, Scrive has provided a means by which a document can be prepared, signed or approved by many different participants. We have handled the process of signing, the integrity and storage of the documents, authentication of the participants, and many of the other aspects of the e-signing process.
Over time, we have finessed this service so that it can meet the needs of most e-signing workflows. There has, however, been one major deficiency of our system as it stands.
Limitations of the standard Scrive e-sign solution
The main issue stems from the fact that many deals involve the signing of multiple distinct contracts and agreements. These may need to be signed in a particular order. Signing workflows may also involve choices which mean that particular auxiliary contracts are sometimes, but not always, necessary.
For example, we may purchase a car and opt into, or out of, also purchasing insurance. Both of these documents will need to be signed as part of the same workflow and in a particular order (purchasing insurance before you own the car is nonsensical).
There is currently no way to express a more complex e-signing workflow that involves multiple documents, ordering, and conditional stages, without building your own integration with our API and managing the process yourself.
How Scrive Flow aims to resolve these limitations
Scrive Flow is a (still experimental) project which aims to allow the description, and automatic execution, of e-signing workflows. Our goal is generality.
These processes are described using our DSL (Domain Specific Language). The DSL allows you to specify, in the abstract, the various participants, documents, orderings, etc that make up your e-signing workflow. The goal at this point is not to talk about specific people or documents, only to describe who does what, when, and to which document.
This can be reused to run through the same process with other participants. To reuse the car purchase agreement example, you may have a different sales representative and different customers, but the process and documents are the same.
You may also have different requirements for how you would like this person to authenticate themselves. Perhaps one customer will be identified via Swedish BankID and another will be a British citizen who uses Onfido passport authentication.
It's also possible that you'd like our system to send callbacks to your own with information about particular events within the process.
All this is currently configurable.
There are many other features which we intend to introduce. Currently stages are linear (a series of fixed steps executed in order) but we intend to support things like conditional execution and parallel stages in the future.
API versus UI
Those of you who require fine grained control will be able to do so via our API. This is suitable for those who wish to have their own systems configure and run Scrive Flow e-signing workflows in an automated fashion. The guides included in this documentation largely assume that you will be using the API.
Those of you who are comfortable setting up your documents in the Scrive web interface will find that you can continue to set up more general e-signing workflows this way too. We are building full support for Scrive flow into our frontend.
For those opting to use the web interface, you may still want to read the Getting Started sections of this documentation so that you gain a greater understanding of what's going on beneath the surface.
This is a rapidly evolving project
Scrive Flow is much an exercise in research and development currently as it is a consumer product. You should be aware of the need to make changes to your own integrations. We will attempt to keep disruption to a minimum and will clearly communicate all deprecations and changes ahead of time. In order to provide a product of the highest possible quality to you, change will be necessary.
We invite you to provide feedback which may be useful in the evolving design of the API. We can only imagine how the system is likely to be used, you can tell us how it's actually used, so please do. The experimental and rapidly evolving nature of the product is an opportunity for you to influence its design so that it better meets your own use cases.
Much of what is included in these guides will change in the future. You should see API Lifecycle for more information.
Further Reading
If you would like a deeper knowledge of the topics covered here, then the following articles may be useful. You are not required to read them in order to understand the rest of this guide.