This article will cover the basics for creating a diagram which is representative of a Gatekeeper workflow
These diagrams are a super useful first step to take when embarking on the setup of a brand new Gatekeeper workflow; key benefits being:
- Visualising the underlying configuration & process behind a kanban board, getting all your thoughts and requirements onto paper
- Teaching new users & collaborators, helping them grasp the high level process
- Solidifying your design to ensure its robustness, confirming that all the necessary scenarios and compliance requirements are accounted for
After the workflow is built, it can also be a useful resource for reviewing the underlying design without needing to click through the workflow itself to painstakingly assess the configuration within....
This does not just apply to you & your users, but a workflow diagram can serve as in invaluable resource for enabling your CSM or the Gatekeeper Support Team to provide guidance and support with any future queries you encounter!
Below we will see a 5 step methodical process for extracting all requirements for your business process and laying them out in a visual representation of how they will function in Gatekeeper
Step 1 - How does it start?
"How a process begins" is simple, but key since it is possible in Gatekeeper to configure workflows which automatically initiate based on predefined conditions ("Triggers") or those which can be started by users when the need arises ( Public Forms, Employee Portal Forms, Touchless Forms) for a new contract/vendor relationship
See Configuring a Workflow Trigger
See Public Forms
Therefore, before you even begin designing the kanban board itself, make the decision and capture in your diagram the method/s how the workflow can be initiated:
Trigger/s (including Supplier User Invitation/Registration triggers):
Employee Portal Form / Public URL Form / Touchless Form
Step 2 - The Phases
Now that you know how your workflow starts, it's time to begin assembling the foundations of your process. You should begin creating your phases and ordering them how you want the process to flow....
💡 It is helpful to have a grasp on how Gatekeeper workflows fit together when approaching this step, or to have seen a fully functioning workflow so that you know what makes up an end-to-end process.
"Phases" are the Kanban-term for the stages of a process
"Swimlanes" or "Checkpoints" may be more commonly used in your organisation.
A handy way to think of the "Phases" of a workflow is like a series of "Queues":
In a workflow, cards want to get from the left hand side of the board to the right where they can 'rest' (on a "Done" phase)...
But first, they must complete the action required from each queue, stopping and waiting for input from a dedicated individual or team (like an Approval being received, a Contract Draft being created, a Form being populated & submitted, and so on) 💡
It helps with the design process to follow the below rules when assembling your workflow phases:
(a) Name your phases after the action being performed and the responsible party. e.g. "Line Manager Approval", "Legal Team Draft Review"
(b) Create phases in your flowchart to resemble how they appear in a Gatekeeper workflow:
Below is a list of the general categories a phase can be sorted into. However, keep in mind that there can be variations to these and even some instances where multiple action categories occur on the same phase.
- Form Submissions - Collating form data throughout a workflow process is a necessary step for building metadata records
- Approvals - These are simple blocks in the process where a particular user/team needs to give official sign off before a request can proceed
- Contract Draft Actions - These cover any phases in the eNegotiate/eSign school of workflow processes (see Configuring eNegotiate for what these are!)
- Metadata Actions - These are the stages of workflows where input made on Form Submission phases should be published out to the Gatekeeper repository either via creating new records or updating existing ones
- AutoActions version of the above! - For (most of) the above "Metadata Actions", Gatekeeper can alleviate some of the administrative burden by performing the action automatically for your users. Remember, these phases still need to be represented on your diagram!
- "Done" phases - These are the final stages of a workflow. The defining part of these is that no further human activity needs to take place on this workflow
(The phrase "human activity" is used because events can still take place on "Done" phases such as automated notifications & AutoActions.)
Contract Approval Workflow Example Phases: XML / PDF
See also Workflow Phases guide
Step 3 - The Actions
After designing the Phases of your process, you will likely have already considered what needs to happen at each of those stages, so now is time to begin assigning those action markers to your workflow phases, including:
- Forms being completed/updated
- Approvals
- "Actions" (Both AutoActions and Manual)
To make your diagram easier to read, it is beneficial to give these different actions a unique design element, such as:
Contract Approval Example continued:
See also: Configuring Workflow Actions for a summary of how they all function
Step 4 - The Transitions
While most kanban boards are generally already laid out in the order every step should be completed, it is still necessary to plot the path through through the process.
One reason to do this is to capture what Actions can cause a card to move, of which below are some types in Gatekeeper:
- Standard transitions
- Forms being completed & submitted
- "Action"-based movements
- Create/Update Contract or Vendor Metadata Record
- eSignatures being Completed/Declined
- Draft Updates & Submissions (eNegotiate)
- AutoActions versions of the above!
- Approvals/Rejections
- SLA Timers (see Workflow SLA Timers)
Another reason is to chart any alternative routes a workflow card can travel. These generally fall into 2 options:
- Conditional Logic gates: Gatekeeper's transition engine can be configured to route cards differently based on any value within the card's data
- An example in the below diagram is a conditional Line Manager Approval for contracts over the value of £10,000. Contracts below this value will transition past this initial approval, skipping it!
- Dynamic Actions: Not all workflow actions have the same output. For some phases, the action taken by the user could influence where a card should go next
- A simple example here is Approvals - in the below diagram you will see 2 outputs of the Line Manager Approval phase based upon whether the user Approves (green arrow) or Rejects (red arrow) the form
Contract Approval Example continued: XML / PDF
See also Configuring Workflow Transitions
Step 5 - The Extra Details/Configuration
Now that you have the essential requirements documented, the final step is applying the detail which will be needed to make the most of the available configuration within the workflow engine.
The extra points to note in a workflow can include elements from the below list:
- Workflow Title
- Phase Owners (& Notification recipients)
- Other Notifications (i.e. beside the phase owner)
- Automated Reminder emails
- SLA Timers
- "Done" phase Card AutoArchive Timers
- Phase Instructions for users (if necessary)
- Connection points with other systems (if necessary)
Contract Approval Example continued: XML / PDF
Note: If unsure of a diagram tool to use, LucidChart & draw.io are 2 Gatekeeper recommendations (with draw.io being the free-to-use equivalent)