A workflow is a repeatable automated process. GoFormz Workflow Automation lets you set up form actions that happen automatically based on certain triggers. For example, you may want to send an email to your customer whenever a form is completed. In this case, form completion is the trigger, and emailing the customer is the action.
Workflow automation lets you implement and enforce business processes having to do with your forms. For instance, instead of asking all employees to remember to execute certain steps each time they complete a form (e.g. emailing certain people upon form completion, storing completed forms in a third-party destination, etc.), these steps can be automated, making the whole process more streamlined and less error-prone. This is a powerful tool for collaboration, compliance, and overall efficiency. At the end of this article, we go over an extended use case of automation that should make this versatility clear.
At this time, GoFormz supports two parallel workflow models — a template model, and a recipe model — with each model being used to manage a subset of all possible workflows. The recipe model is the newer one, and eventually all workflows will be transitioned to use this model. We go over the two models below.
Template Workflow Model
This workflow model will be gradually phased out over the coming months.
In this model, workflows are template-specific. This means that a given workflow only operates on forms created from a specific template. For instance, you would have separate sets of workflows for your Work Order Form and your Service Activation Form. (The one exception to this is email notifications, which can be set up on a per-template level or a global account level.) These workflows are managed from within the Template Editor via the Manage Events window.
Each workflow is treated as an event, which is composed of a trigger (what initiates the workflow) and an action (what you want GoFormz to do when the trigger occurs).
Let’s look at some examples of workflow events:
- When Jane Doe completes a Work Order form, transfer it to John Q Manager
- When a Supervisor completes a Work Order form, email the customer
- When anyone in the organization receives a Work Order form transfer, tag the form with Work Order Received
In all of these examples, the portion before the comma is the trigger, and the portion after the comma is the action.
A trigger is what activates the workflow. A trigger has two components — who does it, and what they do. The “who” can be an individual user (e.g. Jane Doe), a user group (e.g. Supervisors), or any user in your GoFormz account. The “what” can be one of the following:
- Form completion: When the user hits the Complete button on a form.
- Form transfer: When the user receives a form via a form transfer.
- Public Form submission: When a Public Form is submitted for a form owned by the user.
Actions are what you want GoFormz to do when the trigger occurs. GoFormz currently supports the following actions:
- Email: Send an email to an email address or addresses of your choosing.
- Tag: Associate a tag with the form.
- Transfer: Transfer the form to another user or group.
- Save to Box: Upload a PDF of the form to Box.
Recipe Workflow Model
This is the new workflow model. In the future, all workflows will use this model.
In this model, a workflow is modeled as a recipe that consists of a series of steps. The first step is always a trigger (what initiates the workflow), and the subsequent steps are actions (what GoFormz should do when the trigger occurs). Think of a recipe as a template for creating a workflow: it provides the framework for your workflow (i.e. the trigger and actions), but does not fill in the details. For instance, the Egnyte File Upload workflow consists of the following steps:
- Form Completed trigger
- Export Form to PDF action
- Upload File to Egnyte action
The details for these steps — like the form template to be used for the trigger and the Egnyte file path in the Upload step — are filled in when the workflow is created.
Recipe workflows are not inherently configured with the template the way that template workflows are. They are managed via the Workflow Tab, which is a new tab in the top-level menu of the GoFormz interface, separate from any templates.
In addition to not being configured with the template, this model has several other features that make it more flexible, streamlined, and transparent than the template model:
- You can manage all your workflows in one place with this new model, rather than having to open individual templates to see the workflows associated with them. This lets you see a fuller picture of your account, leading to greater transparency and fewer errors. It can be a big time-saver when you want to make changes to multiple workflows.
- A workflow can have multiple actions strung together after the trigger, rather than just a single action.
- Workflow creation is less error-prone when you start with a recipe as your initial framework.
- You can track workflow jobs and view job details with this new model, which is useful for both record-keeping and troubleshooting. A job is a single workflow execution. For instance, when an individual form is completed and uploaded to an Egnyte folder — that constitutes a job.
The following workflow recipes are available at this time:
- Upload to Egnyte: Upload a PDF of the form to Egnyte.
- Upload to Google Drive: Upload a PDF of the completed form to Google Drive.
The triggers and actions for each recipe are described in the recipe’s documentation.
Extended Use Case
Suppose your service organization has a Work Order Form governed by the following rules. The tasks where workflow automation may be useful are marked with numbers in parentheses.
REQUEST: There are two ways that forms are created:
a) A dispatcher gets a request from a customer regarding a new work order, and creates a new form accordingly.
b) Your organization has a public work order template on their website, allowing customers to enter their information and problem description directly into a new Work Order form. When a customer submits such a form, it should go directly into the support queue by sending an email to the support email alias (1). Dispatchers monitor this queue, and process all emails that come in.
Dispatchers select a technician based on their schedule and location, and assign the form directly to that technician for fulfillment.
- FULFILLMENT: Technicians should receive an email on their mobile device (2) when they get a new form assigned to them. Technicians then fill out the form in the field.
- APPROVAL: The regional supervisor must approve all forms completed by a technician in their region. So when a technician completes a form, it should be transferred to the appropriate supervisor based on the region (3a,3b,3c). There are three regions — East Coast, West Coast, and Midwest. The supervisors are Bill, Tara, and Karen, respectively.
- CUSTOMER NOTIFICATION: When a supervisor signs off on a form, the form is deemed complete, and an email with the form attachment should be sent to the customer (4).
- STORAGE & CATEGORIZATION: Your organization uses Box for enterprise storage. The form should be saved to Box (5) once the supervisor signs off on it. In addition, all forms should be tagged (6) as work order forms, and with the customer’s name.
This is similar to a standard workflow at many organizations. So how do we set this up? First, we need to set up some user groups. For this scenario, we suggest the following user groups: East Field Techs, West Field Techs, Midwest Field Techs, Supervisors. Once we have these groups, we can set up the following workflow events. They are numbered to correspond with the numbers in the description above.
1. When anyone submits a public form: Email email@example.com to add a new work order to the queue
2. When anyone in the groups East Techs, West Techs or Midwest Techs receives a transferred form: Tag form as "Tech Received", and also tag with the technician's name.
3a. When anyone in the East Techs group completes a form: Transfer form to Bill.
3b. When anyone in the West Techs group completes a form: Transfer form to Tara.
3c. When anyone in the Midwest Techs group completes a form: Transfer form to Karen.
4. When anyone in the Supervisors group completes a form for the first time: Email form PDF to the customer using their email address from the form.
5. When anyone in the Supervisors group completes a form: Save form to Box.
6. When anyone completes a form: Tag form as "Work Order" and with the customer's name, as provided in the form.
Use the links above to learn how to configure the various workflow actions. The use case was intentionally constructed to take advantage of most available workflow actions.