Fields collect, store, and pass information within a Workflow, such as text, numbers, dates, and files. A field is both the place where data is entered, and where the data is stored.

Examples of use

Fields are likely to be a part of every Workflow that you create on Catalytic.

  • An Approval field could capture whether or not a travel request is approved or rejected.
  • A Campaign Start field could define when a marketing campaign should launch.
  • An Upload Spreadsheet field could be in a task for the assignee to upload an Excel spreadsheet.

How fields work

To understand how fields work, here is quick illustrated example of how a field collects data, how a field stores data, and how a field passes data between actions:

For this example, we have a Vacation Approval Workflow. The Workflow stores all of the field data from each instance in a master data table.

screen readers look here
  • Each row of the table is an instance of that Workflow. Every time an employee requests a vacation, a new row is added for their instance.

  • Each column is a field collected from that instance, like the individual employee’s name, department, and if the request is approved. For example, Zoe’s instance started on Sep 20th: he submitted his name and department and his request is approved.

Another employee Michael wants to ask for some time off and has started his own instance on Sep 24th. He hasn’t entered anything into any fields because the task was just assigned to him. Here’s his first task; let’s walk through it:

screen readers look here

Michael fills out the Name and Department fields. When he completes the task, his entries are collected and entered into the data table shown above. This is how a field collects data.

screen readers look here

And here, Michael’s name and department were added to the data table when he completed the task. The fields of the data table are storing his entries. They were added to the second row because that’s his instance of the Vacation Approval Workflow. This is how a field stores data.

The Name and Department fields are going to be referenced in another task for Michael’s manager.

screen readers look here

Michael’s manager receives the next task to approve the request. The information Michael submitted into the name and department fields are passed into this task automatically. This is how a field passes data between actions.

screen readers look here

If Michael’s manager approves the request, his response will be added to the Approval Response field, where it is stored to be reused.

How to add fields to a task

Not all tasks will need or have fields. Fields are typically used for actions like Assign Task to a Person where a team member enters information into a field, like a name or file.

  1. Select Workflows from the top navigation bar.
  2. Choose a Workflow, this will open the Workflow detail page
  3. Select in the upper-right corner to get to the Workflow Builder page
  4. Select a task, then select Fields. Here is an example, of the fields section of an Assign Task to a Person action.

    screen readers look here
  5. Select Add a Field, type the name of your first field and press Enter
  6. Add additional fields by typing the field names and pressing Enter

How to configure fields

To change and configure a field, like the type or other attributes, select the field and then select the attribute to modify. In the example below, the screen shows the configure field page for Department field from the Vacation Request task.

Basic Field Configuration

screen readers look here
  1. Create a New Field, or Select an Existing Field: By default, adding a field will create a new field. Alternatively, use Select an Existing Field to pick an existing field from anywhere in the process, and add it as a form field. See the section on Select an existing field
  2. Display Name: Change the field name that is displayed to people. Note that the display name is cosmetic and can be changed at any time—it is the field reference name that is used to reference the field value.
  3. Field Reference Name: Refer to the field by this field reference name. You can set a unique name for this field, but only when the field is first created.
  4. Type: Select the field type, such as Text, Decimal, Integer, or Date. See the field types article for more information on each type.
  5. Default Value: Set the default value of the field that users can choose to leave as is or change. For example in a true or false field, setting the default value to “True” will mean true will be preselected.

  6. Description: Appears above the field, directly below the display name, providing guidance to the user. Description fields do not support Markdown. To add more detailed instructions, see the Instruction field type.
  7. Example: Appears directly below the description field, and is useful to provide an example or typical value for a field.

  8. Required Field: By setting a field to required, the user must add a value before completing a task or submitting a web form.

Entry validation for text, integer, and decimal fields

Text, integer, and decimal fields support entry validation, which prevents or restricts a user from submitting a form or task when a field has incorrect data. The Entry validation and Error message fields are used to set a custom validation. Check out Apply entry validation to fields to learn more.

Advanced Field Configuration

screen readers look here
  1. Conditions: Show or hide the field based on other field values, see Field Conditions for specifics on configuring conditions.
  2. Permissions: Limit which users can view values for the field. See Field Permissions for details on permissions.

💡   Tip: If you use short names for fields, they’ll be easier to reference and keep track of. Also, to help any users filling out fields, we recommend adding descriptions and examples to provide additional guidance.

Common Solutions for Fields

Let users see or edit existing fields with Select an Existing Field

By default, you can only add new fields to a web form or manual task. With the Select an Existing Field option, you can find and pick an existing field, and add it to the form.

This is useful when you want a user to see and optionally edit an existing field value. For instance, you might have a choose one type “Shipment Status” field that one user sets to “Enroute”. In another manual task, use Select an Existing Field to add the same field, so a user can change the status again to “Delivered”.

Set fields as required if they’re essential to automation

When fields are necessary for automated actions, always set them to be required. This prevents unexpected issues in automation if someone were to mistakenly not fill out a required field.

Using the same field name twice will change the original field type

If you add a field with the same name as a field that already exists, Catalytic will treat these as the same field and change any of the original field settings.

For example, if you have a Choice field in Task 1, then in Task 2 create an integer field with the same field name as the output of the Choice field, the Choice field will take on the new Integer field type. It will no longer be Choice.

Set the default value of a file field to use it in every instance

Default values can be used to insert various files into the process for use within each instance of a Workflow. A common example would be uploading Excel or word templates as default values so they are included in every Workflow instance.

When a file type field contains a default value, it will automatically change to hidden so it doesn’t appear during a Workflow instance.

Where to find more information on fields

Get help with a problem or question

If something’s not working as expected, or you’re looking for suggestions, check through the options below.

Why can’t I change the field reference name for my field?

The field reference name must remain static so it can be consistently used throughout your workflow. For example, if the field reference name changed, you would have to update every reference you’ve added.

You can always change the display name, which is how the field appears throughout Catalytic. If the field name is changed, the name of the field reference name will NOT change. For example, if a field is created with the display name First Name and it’s changed to Customer First Name later, the field reference name will stay as {{first-name}}, even though the field name was changed. See more under basic field configuration

Sorry about that. What was the most unhelpful part?

Thanks for your feedback

We update the Help Center daily, so expect changes soon.

Link Copied

Paste this URL anywhere to link straight to the section.

Need more help?

If you're signed in to Catalytic Community, you can ask other users a question. You'll be redirected to Community where you can add more info.