Creating trails in bulk with the Workload Generator

The Workload Generator turns a spreadsheet into trails. Each row of the file becomes one real piece of work: a trail on the flow the row names, already on that flow's first step, assigned to the person the row names or waiting in the queue for whoever is free. It is the fastest way to put a whole list of work in front of a team, and every trail it creates is tracked from its first step to its last like any other.

When to use it

Use it whenever work arrives as a list:

• Onboard a cohort: one onboarding trail per new hire, customer or patient.
• Kick off recurring work: monthly audits, quarterly reviews, inspections across every site.
• Bring a backlog in: turn the rows of an existing tracker or export into trails you can follow.
• Hand a team its week: spread the work across people and agents, or leave it in the queue for whoever picks it up.

One file may mix flows: each row names its own.

Who can use it

You need Edit permission at the level you are working in. The Workload Generator is in the New content menu as Workload, next to new flows, bits and references, and it creates trails in the level you are working in: the account, or the organization or group you have switched to. The flows a file names must be active and approved there.

Everyone you assign trails to must be able to run them, which means at least Engage permission at that same level. In an import at the account level, that permission has to be held on the account itself; a person whose access is only to one organization or group cannot be assigned trails from an account-level import. Run the import from their organization or group instead.

Preparing your file

The file is a CSV or an Excel workbook (.xlsx) with one header row and one row per trail. The page offers a template to download, and it lists the active flows in your level with their ids, and the people and agents you can assign work to, so you can copy them into the file.

Column	Required	What it holds
flow_title or flow_id	Yes, one of them	The flow the trail runs. A title must match exactly one active flow; if two flows share a title, use the id. When both are filled, the id wins.
trail_name	Yes	A name that makes the trail easy to find later, up to 256 characters. Include what makes it unique: a customer, a case number, a date.
status	Yes	transferred to assign the trail to someone, or queued to put it in the queue.
assignee_email or assignee_user_id	For transferred rows	Who the trail is for. People can be named by email or by user id; agents only by their user id. When both are filled, the user id wins.
priority	No	low, medium, high or critical. Left blank, the trail takes its flow's priority.
trail_categories	No	Category tags, separated by commas. Left blank, the trail takes its flow's categories.
trail_context.<field>	As the flow requires	One column per context field of the flow, for example trail_context.customer_id.

A few things the page handles for you: headers are matched without regard to case, spaces or hyphens (Trail Name reads as trail_name), values such as High or Queued are accepted in any case, and a column it does not recognise is ignored with a warning rather than refused.

Context fields

A flow can declare context fields: the details every run of it needs from the start, such as a customer, a patient id or a site. In the file they are columns named trail_context. followed by the field's name. A row fills only the fields of its own flow, so in a file that mixes flows the other flows' columns stay empty on that row. A field the flow marks as required must be filled on every row of that flow.

The values are checked against the type the flow gives each field:

• Text is taken as typed, trimmed at both ends. An empty cell leaves the field out.
• Numbers are plain numbers such as 42 or 3.5, without thousands separators, currency signs or percent signs.
• Yes/no fields accept true, false, yes, no, 1 or 0.
• Dates are calendar dates written YYYY-MM-DD, such as 2026-11-03, or a real date cell in Excel. Anything else is refused, including dates like 03/11/2026 that read differently from country to country, and any value that carries a time of day.

Context is part of the trail's record from its first step and cannot be changed afterwards, so check it before you import.

An example

This file creates three trails on two flows. The first is assigned, the second goes to the queue, and the third is assigned with its priority left to the flow:

flow_title,trail_name,status,assignee_email,priority,trail_context.customer_id,trail_context.account_ref
Refund Review,Refund - ACME Corp - TK-4501,transferred,sue.johnson@example.com,high,ACME-001,
Customer Onboarding,Onboarding - Initech,queued,,medium,,INIT-027
Refund Review,Refund - Globex - TK-4502,transferred,emily.maddox@example.com,,GLBX-044,

Assign it or queue it

Each row decides where its trail goes:

• Assigned (transferred): the trail lands on the person's or agent's list, and each person who receives trails is told once per import that new work is waiting for them.
• Queued (queued): the trail waits in the queue of its level until someone claims it. An assignee on a queued row is ignored, with a warning.

Imported trails never start running on their own: whoever receives one starts it when they are ready.

Checking and importing

Choosing a file does not create anything. The page reads it in your browser and shows what it found:

• Errors block the import until they are fixed in the file: a flow that cannot be found, a missing trail name, a status that is not queued or transferred, an assigned row without an assignee, someone who is not a member of the account, a missing required context field, or a value that does not fit its field's type.
• Warnings let the import go ahead and tell you what will happen, for example that a queued row's assignee will be dropped or that a column will not be imported.

Each problem names its row, so you can fix the file and choose it again. When nothing blocks it, import the rows. Large files are sent in batches, and the page shows each batch as it lands, then how many trails were created.

If an import stops partway

Each batch either lands completely or not at all, but a file sent in several batches can stop partway: the batches before the failing one are already created, and the page says how many trails were created, which batch failed and why, and how many rows were not sent.

The Workload Generator does not recognise rows it has already imported. Do not import the whole file again: the trails already created would be created a second time. Fix the problem, keep only the rows that were not sent, and import those.

Getting help from your AI client

If you have connected an AI client such as Claude, ChatGPT or Grok to Floxar, the page's AI prompts offer two ready prompts:

• Build my file: give your AI an export or a list you already have and it maps your columns onto the Workload Generator's, or give it nothing and it interviews you about the work: which flow, who takes what, what each trail needs to know. It reads your flows' context fields and the people in your account through your Floxar connection, and hands you the rows to check and import here. It creates no trails itself, so the page's checks and the preview still apply to everything you import.
• Set up an integration: your AI helps you plan and write an integration that sends the rows from your own system, as described below.

To connect a client, see Connecting an AI client.

From your own systems instead of a file

When the same kind of work arrives regularly, from a ticketing tool, a scheduler or an HR platform, an integration can send the rows to Floxar directly, with the same columns, the same checks and the same result as uploading a file. The page shows where to send them, and Creating trails in bulk with the API explains how.

Once the trails exist, they are worked like any other: see Running and tracking trails.

Last reviewed: 2026-10-25