Basic Configuration
      Back to home
      1. Knowledgebase
      2. Workflows
      3. Basic Configuration

      High-Level Workflow Build Process

      This article will walk you through the high-level end-to-end process of creating a Workflow in Gatekeeper.

      This article is intended for those that wish to build simple workflows themselves. If you require support or advanced functionality, please reach out to your Customer Success Manager.

      Estimated Read Time: 10 Minutes 

      In this article:

      Requirements Gathering

      The initial step to a Workflow build is to ensure that the required process is a good fit for the Workflow Engine.

      Before diving into a Workflow Build, several key questions need to be addressed to ensure that your process fits smoothly into the Gatekeeper Workflow Engine.

      • Does this process involve multiple people and/or groups? 
      • Is this a flow of work containing many tasks/processes owned by different people/groups? 
      • Is this a form-based process? 
      • Does the process result in updating either a Contract or Supplier record?

      Providing the answer to these questions is ‘Yes’, you are ready to proceed with the Workflow Build. 

      Supported Use Cases

      The following is a list of Supported Use Cases within Gatekeeper’s Workflow Engine. Please select each example to see a completed diagram of the relevant process.

      Additionally, please see an example of a Contract Approval Form here.

      Creating a Process Flow Diagram

      For an in-depth guide to creating a Process Flow Diagram, please refer to our Knowledge Base Article.

      Once you have gathered your requirements and confirmed that your process fits into one of the four use cases above, it's time to begin mapping out the Process Flow Diagram that will guide you through the Gatekeeper Workflow Build.

      The Gatekeeper Workflow Engine operates on Kanban. For further information on Kanban, please refer to this article. 

      Many tools can be used to create process flow diagrams. Here at Gatekeeper, we use Lucid Chart.

      When building your process flow diagram, ensure that it follows the Kanban style, as this will provide a seamless experience when building Workflows.

      Considerations

      A Process Flow Diagram is an essential step in the Workflow Build process as it serves as a map and also assists with protecting against scope creep.

      When scoping out your Workflow requirements into a Process Flow Diagram, it is important to consider all of the phases that will be involved within this process. 

      Always aim to keep your Process Flow Diagram up to date with any changes made to your Workflow. This will ensure that if support is required, Gatekeeper can assist.

      If your Process Flow is not up to date, Gatekeeper will be unable to provide support.

      Phases & Phase Ownership

      For a detailed guide on Phases, see our Knowledge Base Article here.

      A Phase is defined as a container with one or many owners. In the below example, the phases are highlighted in red.

      Each Phase can have one or many Owners. Below, you will see an example of how basic ownership can be assigned per phase within a Workflow.

      For a detailed guide on Phase Ownership, see our Knowledge Base Article here.

      Transitions

      For a detailed guide on how to create transitions in Gatekeeper, please see our Knowledge Base Article here.

      Transitions are defined as the logic required to move a card from one phase to another. These are highlighted below in red.

      In the above example, we use simple yes/no transitions to move a card, though this could easily be replaced with fields that are specific to your business.

      For example, IT is only required if this Contract involves a risk to Cyber Security. So, 'IT Required = Yes' could be replaced with 'Does this Contract have access to My Business's Personally Identifiable Information (PII) = Yes'

      Additionally, we can also create multiple transitions per rule:

      Using the example above, IT may be required when there is both Personally Identifiable Information AND the work performed will give access to My Business's Database.

      Ensure that during scoping, you liaise with each separate team to understand the transitional requirements for this process, including the circumstances surrounding when they should be involved (E.g. IT is required when there is Personally Identifiable Information) and, once involved, what they should see/do.

      Transition fields must be a 'Dropdown' field. In our list of Custom Data Field Types, the following field types can be used for transitions:

      • Yes/No
      • Dropdown
      • Multi-pick Dropdown

      Workflow Actions

      Workflow actions are an important part of any Workflow, as they allow the creation/updating of records.

      For additional information on Workflow Actions, please see our Knowledge Base Article here.

      As per the below diagram, we are using an auto-action to first create the Contract record in phase two of the Workflow using all of the information collated in the start phase. The card will then move to the Legal Review phase to collate more information from legal before finally moving into the update contract phase and collating the information from the Legal Review phase into the created record.

       

      All Workflows will require Actions to be enabled. Without Actions, the information collected throughout a Workflow will not be created or updated to a record.

      Approvals

      Approvals are defined as decisions about whether the request should move forward through the process or whether a decision is made to end the current request.

      As per the below diagram, Approvals have two options:

      • Approve
      • Reject

      Approvals can be best utilised when a stakeholder can make a decision as to whether a request should proceed or not.

      For example, Finance may reject a request as the cost may exceed the current budget etc.

      For an in-depth guide to Approvals, please see our Knowledge Base Article here.

      Considerations

      It is important to consider each phase of the process and understand the requirements of the owners of that phase.

      • When are they required versus not required
      • If required, what information do they need to see
      • If required, what information do they need to create
      • Are they approving a request or reviewing a request
        • If so, can their answers change the course of the card
      • Can they reject a request
        • If so, what happens

      Following this mindset, continue to scope out your process until the point of completion.

      Process Flow Diagram Sign-Off

      Once your diagram has been completed, it is essential to circulate this among all relevant stakeholders within your organisation to get sign-off before beginning the Workflow build process.

      This will allow for changes in scope to be discussed, and a decision can be made on whether the Process Flow Diagram is required to change before the Workflow build begins.

      Workflow Build

      The build phase of a workflow involves converting your Process Flow Diagram into a Gatekeeper Workflow.

      This involves three key areas. Form Creation, Basic Configuration and Advanced Configuration.

      These key areas are outlined below. Please, take the time to work through these articles before commencing your Workflow build.

      Form Creation

      For an in-depth guide to Form Creation, please see our Knowledge Base Article here.

      In addition to the Workflow build process, this is also time to begin creating the various Form's that your teams/business require as part of your chosen process.

      Forms make up an important part of every Workflow, as this is where we collate data points as 'Form Fields' and 'Custom Data Fields'.

      There are two different types of fields available within Workflows.

      Form Fields

      Form fields are fields that do not require reporting. They are relevant to the Workflow only and do not appear against the created record within the repository.

      Following our previous example, a form field could be:

      "Is Legal required?" as this field is only relevant to the Workflow and does not need to be reported on.

      Custom Data Fields

      Custom Data Fields are fields that do require reporting. Once a record has been created from our Workflows, any custom data fields can be set to automatically populate against the record.

      Following our previous example, a custom data field could be:

      "Does this Contract have access to My Business's Personally Identifiable Information (PII)" as this field is a reporting requirement.

      For additional information, please see our Knowledge Base Article on Custom Data here.

      Configuration Guide

      Step

      Instructions

      Knowledge Base Links

      Starting your Workflow build

      To create the base version of the Workflow

      Create a Workflow

      **Create a trigger for your Workflow

      From the Workflows overview screen, select the ellipses on your workflow, then select ‘Workflow Triggers’ > ‘Add Trigger’


      **Note - if your Workflow is not triggered, you may skip this step

      Creating Triggers

      Add Phases to your Workflow

      Within your Workflow, select ‘Add’ to create phases. 

      Creating Phases

      Setting up a Form within your Workflow

      Within the first phase of the Workflow, first, select the ellipses, then select ‘Form’ 


      Be sure to distinguish field types between ‘Form Data’ & ‘Custom Data’


      Form Data and Custom data will need to be created in the first phase of the workflow, then form visibility (mandatory, hidden, etc) will need to be set in all phases.

      Creating a Form


      Creating Custom Data

      Configuring Approvals

      On the phases that require Approval, select the ellipses > ’Edit this Phase’ > Approval’

      Create Approval Phases

      Configuring Owners

      Within each phase, first select the ellipses, then select ‘Edit this Phase’ > ‘Form Access’. 

      Workflow Ownership 


      Workflow Groups

      Configure transition rules

      Select the ellipses in each phase of the workflow, then select ‘Edit this Phase’ > select ‘Transitions’ from the right-hand side menu.


      You can toggle between simple and conditional transitions on the right-hand side of the page, above the green ‘Update’ button.


      Transitions will need to be completed on all phases within the workflow.

      Transition Rules

      Configure Workflow Actions

      On the required phases, select the ellipses > ‘Edit this Phase’ > Actions

      Create Actions

      Configure Notifications

      On the required phases, select the ellipses > ‘Edit this Phase’ > Form Access

      Configure Workflow Notifications


      Configure Markdown and Dynamic Notifications


      Testing your Workflow

      Upon completion of your build, it is vital to test the Workflow. A number of tests should be run through all the different combinations of logic to ensure that no logic has been missed and cards move through the Workflow as expected.

      It is important to involve multiple parties in your testing scenarios. Please consider using any teams involved in your workflow for your testing, as they will be able to provide feedback on items relating to what their team should see/do within the Workflow.

      We have created a testing checklist below to assist with your test cases.

      Testing Checklist:

      • Can a card move from one end of your workflow to the other, following all transitional logic?
      • Could each team see the specific information they required?
      • Were emails sent accordingly?
      • Were any Contract/Vendor records created correctly and are visible within your repositories?
      • Are the correct approvers/owners assigned to each phase?
      • Are auto-actions including all appropriate fields?

      Testing Feedback

      From testing, teams will likely have feedback to provide on the process.

      This feedback can be split into two categories.

      Minor Changes & Major Changes:

      Minor Changes

      Minor changes can be categorised as changes that do not require a change in or addition to logic.

      Minor changes can include:

      • Addition of form/custom data fields
      • Changes of ownership
      • Addition of fields to Auto-Actions
      • Change of email notifications

      Minor changes can be rectified within the Workflow immediately. 

      Major Changes

      Major changes are categorised as changes to logic or the flow of the Workflow.

      In the instance that Major Changes are required, Gatekeeper recommends going back to the Process Flow Diagram step and refining your process on paper prior to adding it to the Workflow. This ensures that documentation stays up to date and that no piece of logic is missed.

      Major changes should be scoped. This should always be reflected within your Process Flow.

      Sign-Off

      Once the Workflow has been completed, and all testing has passed, the Workflow can be signed off in preparation for Go-Live.

      Go-Live

      Go-Live can occur once all testing has been finalised and the Workflow has been signed off.

      Gatekeeper recommends one of two forms of Go-Live:

      • Soft rollout
        • Using the Workflow in a Live capacity but only using key members of the team or a limited number of cards for rollout.
      • Full Launch
        • Going Live with the Workflow in all capacities. Full user base and cards.