Collaboration & Workflow

Recipe Workflow Variables

Last Updated: Jul 05, 2017 12:32PM PDT

 

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

When setting up a recipe workflow in GoFormz, you can use variables when entering field values. In this document, we go over the syntax.

The syntax for using variables is as follows:
              #{STEP_ID.[VARIABLE_NAME]}
where:

  • 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.

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.
  • Shared/GoFormz/#{trigger.[formName]}.pdf is a combination of plain text and a variable. #{trigger.[formName]} is the variable portion, and it refers to the formName variable from the trigger step. The trigger in this case is form completion, and the formName variable refers to the name of the form that was completed and triggered the workflow. So if the form name is “AXIS Mobility Report 113238”, then the destination file path will be “Shared/GoFormz/AXIS Mobility Report 113238.pdf”.

 

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 Name” — then [Customer Name] 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.

 

Example

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:
        Shared/GoFormz/#trigger.[Customer Name]/#{trigger.[formName]}.pdf

In this example, the Customer Name 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 “AXIS Mobility Report 113238”, then the PDF will be stored in your third-party app with the path “Shared/GoFormz/Acme/AXIS Mobility Report 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 Name]/
        #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/AXIS Mobility Report 113238.pdf”.

f96791875af3f069482b7b5788b9b70b@goformz.desk-mail.com
http://assets1.desk.com/
false
desk
Loading
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
about
false
Invalid characters found
/customer/en/portal/articles/autocomplete?b_id=13874