MV2 Transaction Workflow - Basics

Agreement Express is a robust platform that offers a great deal of workflow configuration. What does that mean? That means that the way that user interaction, data entry, and data flows are set up can be greatly customized to the point where it is impossible to document every single scenario.

However, there are five basic transaction workflows that enable everything that's needed to account for nearly any scenario - all other customization is added on top of this. In order to understand these workflows, it is important to understand five states that a transaction can exist in. These states are not always obvious when navigating the workspace, and aside from design purposes, it's not really necessary to know them. However, visualizing them can greatly aid in deciding which workflow needs to be adopted to achieve a specific task:

Landing Pages vs Signing Package

Both Landing Pages and Signing Package will consist of templates that are pre-defined within the company. Template creation will be handled in another section, as it in itself allows for great deal of configuration, but it's important to note that landing pages consists of one set of templates, while the signing package consists of another.

Landing pages are very close in behavior to the Signing package. The main purpose for their presence is to perform data entry prior to the generation of signing package - as such, landing pages will never contain visible signature blocks. Once the landing pages are filled in and the next step is triggered, the signing package is generated.

Signing package is the group of documents that undergoes signing, and contains physical signature blocks. The signing process can consist of multiple levels (levels are an order in which certain signatures get signed), and while data entry can be done during the signing package if the template allows for it, it's best practice to handle all data entry during the landing pages.


1. Publisher - This is the landing pages, during Draft status. During this state, the only accounts that can view the agreement are those with the role of Publisher and Company Administrator. Any other account will be unable to access the transaction while it's in this state. 

2. Recipient - This is the landing pages, during Active/Sent/New status. This should only exist when there's a need for data entry to be done by someone other than the original publisher (creator) of the transaction. 

3. Publisher - This is the Draft status of the signing package. During this state, it cannot be viewed by any account with the role of User (just like 1. Publisher). During this state, a Publisher or Administrator can modify various elements within the signing package:

  • Add/Remove/Edit signatures
  • Add/Remove/Edit text fields
  • Insert additional documents for signing
  • etc

4. Recipient - This is New/Sent/Active status of the signing package. During this state, the signing package is undergoing signing. Some data entry is possible if the template of the signing document allows for it, but for the most part this state is intended for signatures to be placed.

5. Complete - This is once all signing has been completed. Once the transaction is completed, it cannot be modified and its state and contents are final. 


There are some natural flows through these states that can exist, while others cannot. For example, it's possible to have a transaction exist just for the purpose of data entry (if signing is not deemed necessary for a specific workflow) - in this workflow, states 3 and 4 are bypassed. 

As mentioned earlier, there are a total of 5 basic workflows that can be used to fulfill almost any scenario - these workflows, and instructions on how to set them up, will be covered in their own individual articles.

Have more questions? Submit a request


Please sign in to leave a comment.