Goal
This guide will demonstrate the steps of creating a workflow template, it will cover the process end-to-end. However, there are separate guides specifically for designing effective workflow (stages) and managing notifications.
Before you get started
You will need to have the correct permissions set in order to design workflow templates. To check this, navigate to:
Settings ➡️ Admins ➡️ Edit your chosen admin ➡️ Select Roles & Permissions ➡️ Scroll down to Access Detail ➡️ Expand Workflows and ensure that Workflows has Full Access selected.
Designing a template
Step 1 - Let's begin
Login to the admin dashboard and click on Workflows, then click requests. Click on the top-right corner button, manage templates. From here you can see and manage your workflow templates.
Please see this article for more on managing workflow templates.
Now click on + add template in the top right to begin designing your own workflow template.
Step 2 - Details
The first page for designing your form template requires the following fields:
Title: This will be the name of the template, subsequent workflow and requests. As an example, if this is for residents to request a new swipe access card then consider titling the template 'New Access Card'.
Description: Succinctly introduce the requestor to the workflow, highlight any prerequisites they may need to complete the workflow, or let them know of any processing times. This field can be used for your desires, ultimately.
User Types: Allows you to select one or more resident types (eg, owner or tenant) and this selection will be the only users with access to the form - great for managing specific forms based on whether the resident is the owner or a tenant.
Image: This will display to all residents using the app or portal and provides a visual aide to the residents.
Attachments: If there are any external attachments needed you can upload them here. PDF documents explaining things further or image files, you can upload them here.
When you have completed this page, click Next.
Step 3 - Form
This step is all about configuring fields to collect relevant information from residents submitting these workflows. You have total control over what fields, their order and type.
There are effectively two columns to this screen; the left-hand side shows the items or fields, their type and order. You also have a button to add additional items (there is no limit). The right-hand side shows the field properties. You need to first select an item before its properties will show here.
Finally, in the middle at the top there is a preview link which allows you to see how the workflow will look like as a finished product to the residents. This useful feature allows you to fine-tune your workflow to perfection before publishing!
Adding an item and editing it
By default, every workflow includes the summary field. This cannot be removed and serves as both the subject and short description of the request.
Click the + add item button and it will append a new item to the bottom of the left-hand side list of items. Clicking this item will show the properties for that item on the right-hand side. The last property in the list is perhaps the most important, and the best place to start; property type which determines what data you want to collect from the resident. We will go through each type in detail, but first two common properties are:
Title: The name of the item which will show to the resident, typically above the item.
Description: Depending on the item type this may or may not show under the name, but above the item, to the resident.
Types and their properties
Section Heading
Use this type to divide your workflow into various sections. This type only needs a title and description.
Short Text
Will appear as a single line of text which the resident can use for input. There are three additional options for this type:
This field is required: Ticking this will make this item mandatory for the resident to enter data into before being able to submit the workflow.
Show field in submission table: Ticking this will allow the request data entered into this item to be shown on any request dashboard as an optional column.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Long Text
Will appear as a paragraph box of text which the resident can use for input. There are two additional options for this type:
This field is required: Ticking this will make this item mandatory for the resident to enter data into before being able to submit the workflow.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Number
Will appear as a single line restricted to numerals which the resident can use for input. There are four additional options for this type:
Min: You can specify what the minimum accepted value is. If you want nothing less than 10, for example, you will enter 10 into this field.
Max: You can specify what the maximum accepted value is. If you want nothing more than 1000, for example, you will enter 1000 into this field.
This field is required: Ticking this will make this item mandatory for the resident to enter data into before being able to submit the workflow.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Checkbox
Will appear as a checkbox with the item description to the right of it. The resident can tick this or leave it blank. There are two additional options for this type:
Does user have to check this field before submitting: Ticking this will make this item mandatory for the resident to tick before being able to submit the workflow. Great for having the resident confirm they have read the terms and conditions, and consequently agree.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Image Upload
Will appear as a button to select file, allowing the resident to select an image to upload. It will show a line under the button with the filename and an X which can be used to remove the file. Multiple images are allowed. There are two additional options for this type:
This field is required: Ticking this will make this item mandatory for the resident to upload an image into before being able to submit the workflow.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
File Upload
Will appear as a button to select file, allowing the resident to select a file to upload. It will show a line under the button with the filename and an X which can be used to remove the file. Multiple files are allowed. There are two additional options for this type:
This field is required: Ticking this will make this item mandatory for the resident to upload a file into before being able to submit the workflow.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Date
Will appear as a date field which the resident can use for input. There is a calendar icon on the far right of the field which opens a more visually appealing calendar from which to select a date. There are two additional options for this type:
This field is required: Ticking this will make this item mandatory for the resident to enter data into before being able to submit the workflow.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Single Select
Will appear as a drop-down box with all the options from which the resident can select a single choice. There are four additional options for this type:
This field is required: Ticking this will make this item mandatory for the resident to enter data into before being able to submit the workflow.
Option list: Here is where you can define all the options from which the resident can choose from. There is a grab icon to the left of the name which allows you to manually sort the options. To the right of each option is a rubbish bin icon which can be used to delete an option. Finally, at the bottom is a text field and + icon which is used to add more options. By default, three options are provided.
Show field in submission table: Ticking this will allow the request data entered into this item to be shown on any request dashboard as an optional column.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Multiple Select
Will appear as a drop-down box with all the options from which the resident can select more than one choice. There are four additional options for this type:
This field is required: Ticking this will make this item mandatory for the resident to enter data into before being able to submit the workflow.
Option list: Here is where you can define all the options from which the resident can choose from. There is a grab icon to the left of the name which allows you to manually sort the options. To the right of each option is a rubbish bin icon which can be used to delete an option. Finally, at the bottom is a text field and + icon which is used to add more options. By default, three options are provided.
Show field in submission table: Ticking this will allow the request data entered into this item to be shown on any request dashboard as an optional column.
Hide the field in community requests: Ticking this will hide the item if the request is subsequently made visible to the community. Use this to hide private resident information from accidentally showing to the wider community.
Deleting an item
To delete an item that is not required for your workflow, click the item and a rubbish bin icon should appear on the item itself. Simply click that, and the item will be gone.
When you have completed this page, click Next.
Step 4 - Workflow
Here is where the lifecycle of the workflow is constructed. To briefly explain, each workflow is a stage the workflow can enter into which can quickly inform all stakeholders where that workflow is at within its lifecycle. Each workflow you create will have its own unique lifecycle needs, so being able to customise these is crucial.
It is important to note that while you may build this in a logical forward-step approach, workflows can go to any workflow stage, even previous ones - there is no limitation.
Creating or editing workflows
Each workflow is represented as a row, these can be re-ordered by grabbing the two-line handle and rearranging. Next, there is a colour picker which allows you to choose the colour for that workflow stage. Then there is the status which is name that will appear in dashboards and the property itself; this is limited to 35 characters. Next, is a drop-down list of types to link this workflow to, these are explained below. You can enter in a description for the workflow stage, but this is limited to 45 characters.
Finally, to delete a workflow stage you can click the garbage bin icon on the far-right. There is a button at the bottom to add additional status.
Workflow types
While you can create as many workflow stages as desired, each needs to have a workflow type, and there are only three. These tie the workflows to platform business rules to assist with functionality.
Unactioned: The workflow request has not received attention.
Actioned: The workflow request is receiving attention from one or more stakeholders but is not complete.
Complete: The workflow request no longer requires attention.
These types will show on all request dashboards throughout the platform.
Default workflows
Each new template will have pre-loaded default workflows. These are named and described as follows:
New: Request has been created.
In Progress: Request is being worked on.
In Review: Pending approval from another party.
Complete: Request was completed successfully.
Declined: Request was invalid of cancelled.
More workflows can be added, and these default ones can be edited or deleted to suit your needs.
When you have completed this page, click Next.
Step 5 - Communities
Workflows can be targeted towards one or more communities. What this means is that workflows can be filtered to only some of your communities, as required. This page has a single drop-down where you can select all communities or individual ones.
The workflow will not be available in communities left unselected.
When you have completed this page, click Next.
Step 6 - Advanced
This page has various options to customise how this workflow will act in certain circumstances. We will go through these options by section heading.
Editing
Enable admins to edit submissions from residents: If selected those with the full access to workflows will be able to edit whatever the resident has submitted via a workflow. Otherwise, it is read-only.
Submission Message
Show a popup after the user submits a request: If selected, a text will appear allowing you to write the message you would like to appear once the workflow has been submitted.
Payments
Does this request require a payment: If selected, you will need to enter in the payment ID (see our future article for integrating with Stripe payments) and the amount to be paid. The resident will have to pay before they can submit their workflow.
App Settings
Allow specific submissions to be shared on the app in 'Community Requests': If selected, you can share a request from a single resident with their wider community. This is great, for example, if a resident raises a maintenance request for something broken in a common area. Sharing their request with the wider community can prevent other residents from 'duplicating' the request. However, it may be prudent to prevent this from every happening with some workflows, so you can disable it.
Submissions related to this form will be visible for committee members via the resident app and portal: If selected, it will allow all requests from this workflow to be seen by committee members. This is fantastic to provide transparency to the committee.
Notifications
Send email notification for new workflow requests:
Send email notification to submission assignee:
Send email notification to primary community manager:
Send email notification if requestor sends message to assignee:
When you have completed this page, click Next.
Step 7 - Save
Once you have completed designing the workflow template, you can click Save and it will be ready for dissemination. Otherwise, you can click the previous button to go back and amend the details on the relevant page.
Training video
This video shows the steps to building a workflow template.