This introduction to approval workflows explains what they are and how they function. The Weagree Wizard’s approval workflows are highly flexible and easily (re)configured, and allow for great complexity and versatility. In order to maximise both their utility and efficiency, a solid understanding of how they operate is essential when designing your approval process.
A. THE BASICS
The essence of any approval workflow is the same: a contract draft must be reviewed by at least one person before it can be finalised and signed (or offered to the counterparty, at least). Its basic purpose is to discover and fix any errors or omissions. The person reviewing the contract must therefore verify that its contents are accurate, complete, compliant with the law and in line with the organisation’s policies. Although this can be arduous work for one person, it is at least logistically fairly manageable. This will quickly change, however, if multiple people become involved in the approval process – and even more so if each should examine different parts of a contract. Communicating becomes increasingly cumbersome, keeping track of whatever changes are being made increasingly difficult, and delays increasingly likely.
The Weagree Wizard makes it easier, faster and more reliable by automating much of the entire approval process. Simply using contract automation templates, of course, already serves to eliminate much of the double-checking that might otherwise be required. Apart from the variables determined by the questionnaire, any contract generated in the Weagree Wizard will ordinarily be correct and complete. Via the questionnaire, workflows are triggered when applicable and in a predetermined order, e-mail notifications are sent, communication is facilitated, and progress logged. Workflows can be tied to specific questions or even specific answers, so that redundant checks are prevented and reviewing a contract will be highly focused and efficient.
A Weagree approval workflow ultimately consists of two basic components, which will be discussed next: approval units and individual workflows.
B. APPROVAL UNITS AND WORKFLOWS
Not unlike Weagree’s contract automation templates, approval workflows are constructed by fitting together different components in order to create a logical structure. These are the approval units and workflows.
An approval unit contains one or more users. These are the persons designated as approvers within that particular unit. They can be used to differentiate, for example, between departments within your organisation or less and more senior employees. Any user can be assigned to multiple approval units.
In turn, a workflow contains one or more approval units. It is possible to insert any particular approval unit into multiple workflows, but the primary purpose of the workflow is to enable the creation of either sequential or parallel approval processes – or even combinations of both.
A sequential process is the most straightforward of the two, meaning that multiple approval units are activated in succession. After approval is granted by one approval unit, the next unit will be activated to also review the contract. By contrast, in case of a parallel process, multiple approval units are simultaneously activated. This means that different approvers must conduct the same review and each give their approval before the process can continue (or finish), for instance if both the senior legal counsel and chief financial officer need to sign off on a contract. Again, combinations are possible: a sequence of approval units may be followed by a parallel set or vice versa. Such configurations may fit within a single workflow, but can also be created by stringing together multiple workflows.
C. TEMPLATE-WIDE AND QUESTION-SPECIFIC WORKFLOWS
As mentioned above, workflows are triggered via the questionnaire: by creating a new contract and answering questions, the user in effect indicates that an approval workflow is required (or not). Therefore, after creating approval units and assigning them to workflows, the workflows themselves must be linked to one or more contract automation templates.
Workflows can operate on two levels, namely on the level of the template as a whole or on the level of a single question within the template.
Template-wide workflows are always activated whenever the questionnaire is started, and are not restricted to any particular part of the template. As such, they should be used for general reviews in which the approver will ordinarily check the entire questionnaire (and, if desired or required, examine whether an individual contract’s particulars should be tailored beyond the scope of the questionnaire, by adding components from the clause library or directly editing the text in the WYSIWYG view).
Question-specific workflows are linked to the answers of multiple-choice questions used in the template. These will only be triggered when the questions appear in the questionnaire and any linked answers are selected. The same workflow can be used for multiple questions and answers. Question-specific workflows are therefore intended to narrow down the scope of the review, so that a senior legal counsel for example might only have to check questions related to intellectual property rights or liability.
As with sequential and parallel workflows, it is possible to use both template-wide and question-specific workflows.
D. APPROVAL ORDER
Knowing how approval workflows are constructed and how they relate to either the entire questionnaire or certain parts of it is enough to design simple approval workflows, but even then an understanding of who will get to approve and when is vital. There are three main rules to keep in mind:
1. If multiple users have been assigned to a single approval unit, only one of them will need to approve (or reject) the contract.
2. Question-specific workflows are triggered, and therefore must be completed, before template-wide workflows.
3. Question-specific workflows are all triggered simultaneously, while template-wide workflows are triggered successively in the order specified by the administrator.
Combined with the ability to add any user to multiple approval units and add multiple approval units in various configurations to any workflow, these three rules allow for the construction of highly complex approval workflows. It may be helpful to draw a flowchart when you are designing your approval workflow.
An example: let’s say that either user A or B should perform a general, preliminary check before anyone else gets to review the contract. They should effectively act as gatekeepers, ensuring that the questionnaire is complete and that the draft should not obviously be rejected. After their initial approval, the answers to several different questions need to be reviewed by stakeholders C, D and E. Once they’re satisfied, a general approval from F (the CFO) is required before G (the CEO) finally signs off on it. Based on the rules outlined above, the approval workflow would be composed of the following elements:
a. An approval unit containing both A and B (unit AB), so that it will suffice if one of them grants approval.
b. Separate approval units for C, D, E, F and G.
c. Three question-specific workflows, sequentially composed of unit AB followed by the unit for C, D or E. The result is that the three workflows can start at the same time and will always require A or B to review the contract before C, D or E gets to take a look at it.
Note: questions that are not part of the workflow are hidden by default. If all three workflows are triggered, A and B will get to see all questions linked to those workflows. The questionnaire includes a switch that will make all other questions visible as well, however, allowing for a complete review. C, D and E will not have to bother with that and can simply work with the default setting, showing only those questions relevant to them.
d. Two template-wide workflows for F and G, which will trigger one after the other.
The question-specific workflows will be completed first, always with A or B performing the first check. Once C, D and/or E (depending on which workflows were actually triggered) have given their approval, F will be next to review the contract, followed by G for final approval. This can be illustrated as below:
The next tutorials in this section will explain how to fully configure an approval workflow in the Weagree Wizard.
