Backfills

Apply a workflow to past tickets it didn’t run on — paced overnight, resumable, with concurrency caps.

A backfill runs an existing workflow against historical tickets that the workflow’s normal trigger would never re-fire for. The same workflow logic, the same tools, the same approvals — just applied to entities that already exist in your PSA instead of waiting for new ones.

A workflow is the what (triage a ticket, dispatch it, update a time entry). A backfill is the when and how-much — it takes that workflow and applies it to a set of past tickets you choose, paced over execution windows so it doesn’t flood your environment.

When to use a backfill

• You just built a new workflow and want it to handle the last 30 days of open tickets, not only newly-created ones.
• You edited a workflow’s logic, prompts, or tools and want the corrected version to re-process recent tickets that ran under the old version.
• You want to test a workflow on a small sample of historical tickets before enabling it for live trigger events.
• You changed assignment or dispatch rules and want to apply them across an open queue.

A backfill doesn’t modify the target workflow — it just reuses it. Each past ticket that matches the backfill’s filter gets dispatched into the workflow exactly as it would have if a fresh trigger had arrived.

Setting one up

From the dashboard, go to Backfills → New backfill. The wizard has four steps:

1. Pick the target workflow

   Choose the workflow you want to apply to historical tickets. The workflow must be enabled.

2. Choose a filter

   Two options:

   • Reuse workflow filters — the backfill processes the same tickets the workflow normally matches, optionally narrowed with extra rules (e.g. “the workflow’s normal filter PLUS createDate > 2026-04-01”). Best when you want history that matches what’s running live today.
   • Custom filters — the backfill defines its own ticket scope, ignoring the workflow’s own filter. Best when you want to one-off process a set of tickets that the workflow wouldn’t normally match (e.g. an old queue that’s been migrated).

   See Filter tickets for the rule-builder reference.

3. Configure the execution window

   Pick the days of the week and start/end times when the backfill is allowed to dispatch. Times are interpreted in the timezone you select (defaults to your browser’s timezone).

   The classic pattern is weeknights 22:00 → 06:00 in your local timezone: the PSA is quiet, the backfill stays out of business-hours traffic, and you wake up to a fresh batch of processed tickets.

4. Review and create

   The review step previews how many tickets currently match your filter and the upper-bound credit cost so you know what you’re committing to before you click Create backfill.

Execution windows

Windows tell the backfill when it’s allowed to dispatch. Outside the window, it stays paused-but-alive — no new tickets get picked up, and the detail page shows a “Waiting for window” badge with the next opening time.

A window can span midnight (22:00 → 06:00 means from 22:00 on the configured day through 06:00 the next morning), and you can configure different windows per day — or leave a day empty to skip it entirely. The backfill resumes automatically at the next opening; no need to babysit it across nights.

Filters

The filter builder is the same one used to configure workflow conditions, so anything you can express on a workflow’s filter — queue, status, priority, custom fields, contact attributes — works here too.

When you pick Reuse workflow filters, the wizard takes a snapshot of the workflow’s current filter rules at the moment you create the backfill. Editing the workflow’s filter later doesn’t change what an in-flight backfill is processing.

In Custom filters mode, the workflow’s own filter is intentionally bypassed at dispatch time — the backfill is the authority on which tickets run. This is what makes it possible to “re-run a workflow on tickets it wouldn’t normally match.”

States

State	Meaning
Running	Actively dispatching during the execution window, waiting between windows.
Paused	You paused it. No new dispatches until you resume.
Completed	Every matching ticket has finished.
Cancelled	You cancelled it. Tickets already mid-run will still finish on their own.
Failed	Something went wrong that we couldn’t recover from.

When a backfill is Running but currently outside the configured window, the detail page shows a “Waiting for window” sub-status with the next opening time. This is helpful when a backfill is created at 10 AM for a 22:00 window — nothing is broken; it’s just waiting until tonight.

Progress counters

Each backfill row shows four numbers:

• Started — tickets the backfill has dispatched into the workflow so far.
• Succeeded — tickets whose workflow run finished successfully.
• Failed — tickets whose workflow run finished with an error.
• In flight — tickets currently mid-run.

Succeeded and failed counts may briefly lag the started count by a second or two while the latest dispatches are still wrapping up.

Pause, resume, cancel

Action	Effect
Pause	Stops new dispatches at the next moment the backfill checks in. Tickets already mid-run still finish.
Resume	Picks up where it left off and continues dispatching the rest of the matching tickets.
Cancel	Terminal. Stops the backfill permanently. Tickets already mid-run still finish on their own.

Pause and resume are reversible — use them freely to throttle a backfill that’s making more noise than expected, or to pause overnight if you want to review the morning’s results before letting it continue. Cancel is permanent; if you change your mind, create a new backfill with the same filter to pick up the unprocessed tickets.

After clicking Pause, Resume, or Cancel, the button shows a spinner for up to ~30 seconds while the backfill picks up the signal. The status badge updates as soon as the change takes effect.

Cost

Each ticket the backfill processes is billed at the target workflow’s normal credit cost — a backfill of 1,000 tickets through a triage agent at 2 credits per run costs 2,000 credits. Backfills don’t add a markup; they’re just a pacing mechanism for the workflow’s existing per-run cost.

The wizard’s review step shows the upper-bound cost (number of matching tickets × credits per run) before you commit, so the ceiling is explicit at create time.

Concurrency

Backfills cap how many tickets are mid-run at once (default 5). This protects your PSA from rate-limit issues and keeps the backfill out of the way of live traffic.

The cap counts all running executions of the target workflow, not just backfill-driven ones. If three tickets are already running because of live triggers, your backfill (capped at 5) only takes two slots until those finish. This is intentional — the cap protects your PSA, not just the backfill.

Troubleshooting

The status is Running but no tickets are being processed

The backfill is alive but currently outside its execution window. Check the “Waiting for window” badge on the detail page — it tells you the next opening time. If you created the backfill at 10 AM for a 22:00 window, this is expected; it’ll start dispatching at 22:00.

A second backfill for the same workflow won't create

Only one active backfill (Running or Paused) is allowed per workflow at a time. Cancel or finish the existing one first, then create the new one.

Started count is climbing but succeeded / failed stays at zero

Succeeded and failed counts are updated as each ticket’s workflow run actually finishes — there’s a short delay between “dispatched” and “finished.” If they stay at zero for more than a minute or so, the workflow itself may be stuck on a ticket; open one of the ticket’s execution history to see what it’s doing.

My backfill isn't getting all of its concurrency slots

The concurrency cap counts every running execution of the target workflow — including ones triggered by live PSA events, not just by the backfill. If live trigger traffic is consuming slots, the backfill shares the pool. This is by design to protect your PSA.

It's been running for days and hasn't finished

Backfills run only inside their execution window. A weeknight 22:00 → 06:00 window over 1,000 tickets at 5 concurrent will take several nights. If progress looks stuck during the window, check the detail page’s progress card and the workflow’s executions — usually a tool or approval is waiting, not the backfill itself.

Limits

• Concurrency: 1–10 tickets in flight per backfill.
• Filter safety check: the wizard’s review step warns when a filter matches more than 5,000 tickets and blocks creation when it matches more than 100,000. Both thresholds protect you from accidentally kicking off a backfill that’s far bigger than intended.
• Maximum lifetime: 7 days. A backfill that hasn’t finished in 7 days usually means the filter is too wide for the configured window — narrow the filter or widen the window.
• One active per workflow: at most one Running or Paused backfill per workflow in your tenant. Completed and cancelled backfills don’t count.