Creating a Workflow Diagram 📐

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?

Step 2 - The Phases

Step 3 - The Actions

Step 4 - The Transitions

Step 5 - The Final Details

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

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:

Icons Version: XML / PDF

Colours Version: XML / PDF

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

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)