Skip to content

How to Iterate Over Multiple Records in a HappyFox Workflow

Last updated

This article explains how to process a filtered list of tickets or assets one at a time in HappyFox Workflows, using a counter field and a self-triggering workflow, so you can run the same set of actions against every matching record instead of only the first one.

Applicable Plans: Available on all plans.

Prerequisites

How the pattern works

HappyFox Workflows does not have a dedicated loop or "for each" action. Instead, you build a self-triggering workflow around a master ticket, using seven components. The same seven components apply whether the records you are iterating over are tickets or assets — only the filter action and the field-update action change.

  1. A master ticket with a counter field. This ticket does not change for the life of the run. Its counter field tracks how many records have been processed so far, and is the field the trigger condition below watches.
  2. A trigger condition that checks whether iteration should continue. This condition fires on the master ticket whenever its counter field changes, which is what allows the workflow to run more than once instead of stopping after a single pass.
  3. A filter records action — Filter Tickets or Filter Assets, using the same conditions on every run. Downstream actions always reference the record at index 0 — the first result — in the filter's output. Because processed records are removed from contention (see component 5), the record at index 0 is always the next unprocessed record.
  4. Actions performed on the current record — the ticket or asset actions this workflow actually exists to run: creating a related ticket, updating fields, sending a notification, and so on.
  5. An update to the record itself, so it no longer matches the filter conditions in component 3 the next time the workflow runs. This is what advances the loop from one record to the next.
  6. An update to the counter field on the master ticket, reflecting that one more record has been processed.
  7. The counter update in component 6 is the action that satisfies the trigger condition in component 2. Updating the counter is not a separate notification step — it is the same event the trigger is watching for, so it is what causes the workflow to run again for the next record.

The cycle continues until the filter action in component 3 returns no matching records. At that point the workflow has nothing left to act on and stops.

Note: HappyFox Workflows has no native loop or "for each" action. This counter-and-filter pattern is the recommended approach for acting on multiple filtered records from a single workflow trigger.

Warning: Set up this pattern carefully. All seven components must align exactly — if the filter conditions in component 3, the record-update in component 5, or the counter update in component 6 do not work together correctly, the filter action can keep returning the same record instead of the next one. Because the counter update is also what re-fires the trigger, this can cause the workflow to retrigger itself continuously with no stop condition ever met, creating tickets or updating records without limit until someone disables the workflow manually. Test the workflow against a small, controlled set of records before enabling it against live tickets or assets, and monitor Run History closely the first time it runs.

Building the pattern

Step 1: Create the master ticket (component 1)

  1. Choose a trigger that starts the process, such as Ticket Created, and add a condition that narrows it to the specific ticket that should act as the master ticket — for example, the ticket subject containing a specific phrase.
  2. Add a Filter Tickets or Filter Assets action with the conditions that identify the full set of records you want to process.
  3. Add a Link Assets To Ticket action, or the equivalent action for your record type, to associate the full filtered set with the master ticket. This step is optional and gives you a reference of everything the workflow is about to process.
  4. Add a Set Ticket Custom Fields action to set the Counter field on the master ticket to 1. This starts the self-triggering cycle built in Step 2.

Step 2: Build the self-triggering workflow (components 2–7)

Each sub-step below maps to one of the seven components described above.

  1. Create a second workflow with a Ticket Updated trigger on the master ticket, and add a condition on the Counter field so the workflow fires whenever that field changes. (Component 2 — the trigger condition.)
  2. Add the same Filter Tickets or Filter Assets action from Step 1, using the same conditions, and reference the record at index 0 of its output. Because each processed record is marked as done in sub-step 5 below, the record at index 0 is always the next unprocessed one. (Component 3 — filter records.)
  3. Add a Check Conditions action to test whether the filter action returned at least one record. If it returned none, add a Set Status action to close the master ticket, since there is nothing left to process, and end the workflow here.
  4. Add the actions this workflow exists to run against the current record — for example, Create Related Ticket followed by Link Assets To Ticket to associate the current record with the new ticket. (Component 4 — actions on the current record.)
  5. Add a Set Asset Custom Fields or Set Ticket Custom Fields action to update the record just processed, so it no longer matches the filter conditions from sub-step 2. (Component 5 — update the record.)
  6. Add a Perform Math Operations action to increase the Counter field on the master ticket by 1. (Component 6 — update the counter.)
  7. This same Perform Math Operations action is what satisfies the trigger condition from sub-step 1, since that condition is watching the master ticket's Counter field for exactly this change. No separate action is needed — updating the counter in sub-step 6 is what causes the workflow to run again for the next record. (Component 7.)

Note: The self-triggering workflow runs once for every record in the filtered list. When the counter reaches the total number of records, the next filter action run returns no matches, the check condition fails, and sub-step 3 closes the master ticket with Set Status. The master record in this pattern is always a ticket, since only tickets support the triggers this pattern depends on — that is why Set Status closes it, while Set Asset Custom Fields is used only to mark individual asset records as processed in sub-step 5.

Warning: If the record-update step in Step 2 sub-step 5 is skipped or misconfigured, the filter condition in sub-step 2 keeps matching the same record. This causes the workflow to repeat its output — for example, creating duplicate tickets — indefinitely instead of moving on to the next record.

Worked example: Auditing assets before decommissioning

Suppose you want a monthly reminder to review every asset that is due for decommissioning the following month, with a dedicated audit ticket created for each one.

Every asset carries custom fields for decommission month and decommission year, plus a status field that can be set to a value such as Due. A scheduled ticket, created every month from a ticket template, triggers the starting workflow described in Step 1 above. That workflow calculates the following calendar month from the ticket's creation timestamp — sets the decommission month and year fields on the ticket, filters assets matching those values, links the full filtered set of assets to the ticket for visibility, and sets the Counter field to 1.

The self-triggering workflow from Step 2 then runs once for every matching asset. Each run filters assets using the same decommission month and year conditions plus an active status, creates a related audit ticket, links the current asset to it, sets the asset's status to Due, and increases the counter — which triggers the workflow again for the next matching asset. Once every matching asset has had its status changed to Due, the filter action returns no results, the check condition fails, and the workflow closes the original scheduled ticket with a Set Status action, since there is nothing left to process.

This same pattern applies to tickets: replace Filter Assets with Filter Tickets, and mark each ticket as processed with a Set Ticket Custom Fields action instead of an asset field update.

This pattern lets a single workflow act on every record in a filtered list, one at a time, rather than stopping after the first match. Next, see how to use the Perform Math Operations action to configure the counter increment, or how to use Merge Fields and dynamic variables to reference field values from the record currently being processed.