Executions

Current status: the Executions page (/admin/executions) is in a superadmin-only preview. It preserves the history of two legacy features — agent schedules and follow-ups — that were retired on August 23, 2026. Organization users do not see the sidebar item and are redirected to Agents when they open the route directly.

Use Automations to create, test, and monitor a new routine. The Idle conversation trigger replaces legacy follow-ups, and scheduled routines must also be built in the automation editor. See Triggers and Runs and tests.

Access and purpose

The route still requires the technical executions.view (View executions) permission, but the preview gate is stricter: in the current state, only a superadmin can remain on the page. Granting the permission to an organization role does not expose the interface while preview is active.

The history remains available for traceability. It is not the log for current automations and does not receive runs from the Automations engine.

The two tabs

Schedules

This tab queries historical conversations whose source_trigger_id points to a former schedule trigger. Each row is a conversation created by one legacy run, not an independent cron job.

The table shows:

• Agent: the agent’s current name; if the relationship no longer exists, it shows Agent removed;
• Schedule: the part of the conversation title before the first -; when no name is available, it shows Schedule;
• Date/Time: the conversation creation time, formatted for the interface language;
• Status: the conversation’s current status — Active, Completed, or Failed. The filter still offers Pending, although the current conversations table contract does not accept that value;
• Credits: cumulative credits_used on the conversation, or — when no value is available;
• Actions: View conversation opens /admin/conversations?id=<conversation-id>.

When a conversation has Failed status and an error_message, the alert icon exposes that text in a tooltip. This is the error stored on the conversation; the table does not provide a step timeline.

Follow-ups

This tab reads the historical record of each attempt made by the former agent follow-up feature. It shows:

• Sent at: when the attempt was recorded;
• Channel: the channel value stored on the record;
• Attempt: the attempt’s sequence number;
• Status: Sent, Skipped, or Failed;
• Message: recorded text, visually truncated in the cell and available in full through its title attribute.

The alert icon explains why an attempt was skipped or failed. Translated skip reasons include an expired 24-hour window, disconnected channel, a lead who replied during the batch, and missing credentials. The human_intervention_active reason has no current UI translation and appears as a technical key.

Filters

Both tabs reuse the same fields:

• Agent — All agents or one specific agent;
• Status — values depend on the active tab;
• Start date and End date — applied to conversation creation on Schedules and to sent_at on Follow-ups;
• Clear filters — only appears while at least one filter is active.

Each change refreshes the data immediately. Status also remains in memory when you switch tabs. Because the two tabs use different sets, moving from Schedules with Active, Completed, Pending, or Failed selected to Follow-ups can produce an empty list; use Clear filters after switching. The same applies in reverse to Sent and Skipped.

Pagination

Each tab loads 20 records per page. When more than one page exists, the footer shows the total, the page / total position, and previous/next arrows.

On Schedules, changing a filter returns to the first page. On Follow-ups, the current page is not reset; if a new filter produces an unexpected empty state, navigate back to page one manually.

Where to investigate current routines

• For a run from the current engine, open the automation and select Activity. It contains status, executed version, path taken, cost, and each step’s input and output.
• To test without sending messages to a customer, use Test in the automation editor.
• For a new follow-up, use the Idle conversation trigger and configure re-entry and give-up safeguards in the flow itself.
• Use the legacy Executions page only when internal support needs to inspect preserved data from the retired features.