Note: This article is about variables used in workflows. For variables used in template events and elsewhere, see here.

When setting up a workflow in GoFormz, you can use variables when entering workflow properties. In this document, we go over the syntax, and review some examples.

The syntax for using variables is as follows:



  • STEP_ID is the ID of a preceding action step, or the word “trigger” for trigger steps. Trigger steps do not need a separate ID because there is only one trigger per workflow.

  • VARIABLE_NAME is a variable that’s available at the output stage of the step being referenced. The set of available variables depends on the step.

In case your variable name has a space in it, use square brackets around the name:


This explanation is a little bit abstract, so let us look at some examples. The image below shows two key-value pairs, each of which uses variables in the value:

  • #{ExportPDF.pdfUrl} refers to the pdfUrl variable from the ExportPDF step. This step has to precede the current step in the workflow sequence in order for the variable to be accessible. In this case, the ExportPDF step creates a PDF from a form and stores it at an internal URL location. The pdfUrl variable being retrieved here references this location.

  • Demo/Customers/#{trigger.Customer/Work Orders/#{trigger.[FormattedDate]}/ is a combination of plain text and a variable. #{trigger.Customer} is the variable portion, and it refers to the customer variable from the trigger step. The trigger in this case is form completion, and the customer variable refers to the name of the form that was completed and triggered the workflow.

Form Variables

Form variables are available as part of any trigger that has to do with a form, like a “form completed” trigger or a “form transfer” trigger. Since these are the most common trigger types, it’s important to know what form variables are available for you to use.

There are two types of form variables: metadata variables and field variables.

Metadata Variables

Form metadata variables provide information about the form itself, rather than the values of any specific fields within the form. The following metadata variables are supported in recipe workflows:

  • formName: The form name. Note that this is the name of the form rather than the template. Depending on your configuration, each form created from the same template may or may not have a unique name.

  • formId: The unique 32-digit hexadecimal identifier associated with the form.

  • formTemplateId: The unique 32-digit hexadecimal identifier associated with the form template.

  • formStatus: The form’s status; this can be one of the following values: “complete” or “draft”.

  • formChangeDate: The timestamp when the form's status last changed, in the following format: MM/DD/YYYY hhmmss. This includes form completions and form transfers.

  • formLastUpdateDate: The timestamp when the form was last updated (e.g. saved), in the following format: MM/DD/YYYY hhmmss.

Field Variables

Field variables represent the value contained in a form field, and are represented by the form field name in square brackets. So if, for instance, your form has a field called “Customer” — then [Customer] is the workflow variable representing that field’s value. You can find your form’s field names by opening your form template in the Template Editor and looking at the “Name” property in the Field Properties pane, as shown below.


Let us take a look at an example that uses both types of form variables — metadata and field. Suppose you are constructing a workflow to send form output to a third-party app, and you enter the following as your destination:


In this example, the Customer form field determines the name of the folder where your form PDF will be placed, and the form name determines the name of the file. The end result is a set of subfolders corresponding to your customer names. So, for instance, if the customer name is “Acme” and the form name is “Demo Work Order 113238”, then the PDF will be stored in your third-party app with the path “Shared/GoFormz/Acme/DemoWork Order 113238.pdf”.

The above example creates a single set of subfolders, but you can use variables to build folder hierarchies that are as deep as you need them to be. For instance, the following creates a hierarchy that is three levels deep:

Shared/GoFormz/#trigger.[Job Type]/#trigger.[Customer]/
#trigger.[Street Address] - #trigger.City/#{trigger.formName}.pdf

Each completed form PDF is placed into the folder hierarchy based on the job type (e.g. HVAC vs Electrical), customer name, and customer location as determined by the Street Address and City fields from the form (this is useful for customers with multiple locations). Using our Acme example from above — if the job type is HVAC and it was done at Acme’s 555 10th Street, New York location, then the form will be stored with the following folder hierarchy: “Shared/GoFormz/HVAC/Acme/555 10th Street - New York/Demo Work Order 113238.pdf”.

Did this answer your question?