Tables: Start Workflow for Each Row

Use this action to to start multiple instances of a Workflow, one for each row of a data table

This action is considered an “iterator”, and creates inline actions, which lets you embed a Workflow directly into another process. Check the Inline actions article to learn more, or see how to use iterators to repeat actions multiple times.

Use Case

The Tables: Start Workflow for Each Row action starts an instance of a Workflow for each row of a specified data table. The instances that are started by this action are referred to as Helper Workflows or subprocesses and the overall functionality is also known as a batch process.

The action has many applications and should be considered whenever the same set of actions or tasks need to be repeated for multiple objects. Examples of this include: sending emails to a list of employees or customers, starting an instance for multiple cities/offices.

A typical use case is first using a Tables: Apply filters or Tables: Remove Duplicates in a Column action to first save specific rows of a data table into a new table and then using Tables: Start Workflow for Each Row on that resulting table.

How to configure this action

The values stored in the specific row of the data table can be referenced within the subprocess using the column name in {{field-names}} format.

All field values in the starter process will be available in all subprocesses. However, the field values in the subprocesses will not be accessible in the starter process.

Fields for this action

  • Process

    • Select a Workflow to start off each row from a list of all Workflows available on your team. The list only includes Workflows you have permission to view.
      • You can also reference a Workflow stored in a field. Change the left hand drop-down to Field then select from any field that is part of the process. Learn more.
      • If necessary, you can enter the Workflow ID directly. Change the left hand drop-down to ID then enter the ID manually. Learn more.
  • Data table

    • Select a table from a list of all tables available on your team. The list only includes tables you have permission to view.
      • You can also reference a table stored in a field. Change the left hand drop-down to Field then select from any field that is part of the process. Learn more.
      • If necessary, you can enter the Table ID directly. Change the left hand drop-down to ID then enter the ID manually. Learn more.
  • Batch instance display name

    • Input the name each sub process instance will adopt. Use field references, text, or references to a column in the form of: columns[‘column-name’] or columns[‘Column Display Name’]
      • For example, with a run name of: “Sales report for columns['sales team']”, the name of each run instance would change dynamically based on the row value in the sales team column, such as: “Sales report for team 1” or “Sales report for team 2”.
  • Child run owner

    • If left blank, all batch runs will be owned by the parent run owner. To have a different user own all batch runs, enter a user’s username or email in {{field-name}} format.
    • 💡Tip: To have the owner of each batch run assigned based on information in the data table, reference a data table column in columns[‘column-name’] or columns[‘Column Display Name’] format.
  • Deadline

    • Select True or False from the drop down to set whether the child instances should inherit the process deadline.
      • Select True to pass the deadline from the parent process to the child instances.
      • Select False or leave blank and no deadline will be set for the batch runs.
  • Owner

    • Email address or username for owner of subprocesses, {{field-names}} acceptable as well. If blank, will default to the owner of the batch Workflow
  • Complete immediately

    • Select True or False from the drop down to set whether the parent Workflow should wait until all sub processes complete before marking this task as completed.
      • Select True to have this task be marked complete as soon as all sub processes are started.
      • Select False or leave blank to have this task stay open until all sub processes are finished.
    • 💡Tip: It’s recommended to leave this blank or False if the sub processes are expected to return data back to the parent Workflow. By leaving this blank or False, the process will pause until all sub processes finish.
  • Output Field Prefix

    • To help keep output fields organized, choose a prefix that will be added to the beginning of each output field name as this action may output more than one field.

How to refer to values within the starter table from a Helper Workflow

Each row of a table starts a unique Workflow instance. In each of those instances, the cells from the starter row are converted to referenceable fields. For example, a 20 column table would be turned into 20 fields.

Every cell from the table is available as a field based on the table headers. For example, each field from a table, Row ID, Name, and Start Date, is available using standard field reference notation: {{row-id}},{{name}}, and {{start-date}}.

screen readers look here

The fields created from each row are available only in the instance that was started from the row. For example, the fields from the second row are only available in the second instance, and not in the 1st or 3rd instance.

screen readers look here

💡Tip: These unique tables fields do not inherit the Output Field Prefix defined during configuration, they are referenced directly by their field name, e.g., {{start-date}}, not {{output-field-prefix--start-date}}.

How to send values from a Helper Workflow back to the parent Workflow

All field values in the starter Workflow will be available in the Helper Workflow. However, the field values in the Helper Workflow are not automatically accessible in the parent Workflow.

The best way to return fields and data from a Helper Workflow back to a parent Workflow is to store values in a data table. This data table acts as an in-between where both the helper and parent can add or edit data.

screen readers look here
For example, create an empty data table within the parent Workflow, then add to the table from the Helper Workflow. Any data added, the parent can reference and use.

What will this output?

This action may generate multiple fields. To help keep output fields organized, the prefix above will be added to the beginning of each of the output field names, separated by two dashes. Each field will result as:{{output-field-prefix--output-field}}.

Output fields for this action

  • Number of Workflows

    • The number of subprocesses started.
  • Successful Runs Data Table ID

    • Stores the Data Table of the data table that logs the successful sub-process runs. Each successful run is a row in the table. The fields of each run are the columns of the table—including the Run ID, Run display name.
    screen readers look here
  • Failed Runs Data Table ID

    • The ID for the Catalytic data table with the failed run data. This is the same data as the CSV. The table has a row for each run, and the columns Start date and Run ID.
  • Failed Runs

    • The number of failed runs, such as if a row had incorrect data and a Workflow could not start from it.
  • Successful Runs

    • The number of successful runs.
  • All runs started successfully

    • If all sub-processes start successfully, outputs true. If a 1 or more runs do not start successfully, outputs false.