Creating a Dashboard AI Employee

A Dashboard AI Employee runs your workflow once per row. You add a row, fill in the workflow's inputs, and the AI Employee (AIE) runs the workflow against those inputs; the published outputs land back in the row as new columns. It's the right interaction type whenever the job is "run this same process across many items" — review a stack of contracts, extract fields from a batch of invoices, triage a queue of tickets, score a list of leads.

Where a chat AI Employee is a back-and-forth conversation and a Voice AI Employee handles phone calls, a dashboard AI Employee is a table: each row is one independent run, and the table is the place you launch runs, watch them finish, review anything paused for a person, and export the results.

Prerequisites. You need a builder role (builder, builder admin, system admin, or env admin) to create and configure an AI Employee. The dashboard itself is the default view for any AI Employee that isn't chat, voice, or recruiter.

What a dashboard AI Employee is

A dashboard AI Employee is a normal AI Employee with its interaction type set to dashboard. The interaction type is one of chat, dashboard, voice, or recruiter, and it's fixed when you create the AI Employee (and editable on the AI Employee's details). It changes how the AI Employee is driven and displayed, not how the workflow itself is built:

The AIE's main tab is the Dashboard — a table of runs — instead of a Chat or Voice settings tab.
The Start node's input schema becomes the set of input columns you fill in for each row.
Each Publish node's output fields become the output columns that populate as runs finish.
The underlying workflow is a directed acyclic graph (DAG) of typed nodes — exactly the same building blocks as any other AI Employee.

The dashboard does not change agent behavior. Whatever agents you wire up — an Intent Classifier, a Data Extractor, a Search & Respond agent, a Rule Validator — run identically. The table is just the front door for launching and tracking many runs of that workflow.

How a row maps to a run

Every row in the dashboard is one workflow run:

The row's input fields are the values you supplied for the Start node's input schema.
Its status tracks the run — for example, a row sits in a draft state while uploaded files are still being processed, moves to running, can become paused when a node needs a person (see Human in the loop), and reaches a terminal completed or failed state.
Its output columns are the published outputs of that run, filled in field by field as the run produces them.
The dashboard streams updates in real time, so rows advance in front of you without a manual refresh.

Because each row is an independent run, rows succeed, fail, pause, and re-run on their own — one bad input doesn't stall the rest of the table.

When to use it

Reach for a dashboard AI Employee when the work is batch, structured, and repeatable:

Document and data processing at volume — extract structured fields from many documents, then validate each against a ruleset.
Queue triage — classify and route a backlog of incoming items, with a person reviewing the edge cases.
Scoring and enrichment — run the same evaluation across a list and collect a comparable result per item.
Anything you'd otherwise do in a spreadsheet — one input row in, one structured result row out.

Choose a different interaction type when:

The job is a single ongoing conversation with a user → chat.
The AI Employee answers phone calls → voice (see Creating a Voice AI Employee).

A dashboard AI Employee pairs naturally with a schedule. If the Start node carries a cron schedule, the published workflow runs automatically and new rows appear without anyone opening the table. See Build your first workflow for scheduling.

Step 1 — create the AI Employee as a dashboard

In the AI Employees area, create a new AI Employee.
Give it a name, description, and (optionally) a group and icon.
Set the interaction type to Dashboard.
Create it. A workflow is provisioned for the AIE, and it opens with a Start node and an End node already placed.

The interaction type you pick here is what makes the AIE render as a table rather than a chat or voice surface.

Step 2 — define input columns on the Start node

The Start node's input schema is the contract for every row: each declared field becomes a column you fill in when you add a row.

Open the Configuration tab and edit the workflow, or open the AI Employee builder directly.
Select the Start node and add one field per input you need. For each field set its Key (the machine name, e.g. message), Type (Text, Number, Integer, Boolean, or File), Display Title (the column header), and whether it's Required.
Save the schema.

A dashboard workflow must declare at least one input field. The Start node shows a warning badge and an "Add at least one input" pill until you do — without inputs there's nothing to collect per row, so adding rows is blocked. (Chat workflows are the exception: they expose reserved per-turn keys instead.)

How the inputs are shown as columns depends on how many you declare:

File inputs always get their own column.
1–2 non-file inputs each get their own column.
3 or more non-file inputs collapse into a single Inputs column to keep the table readable.

Step 3 — build the workflow

Build the workflow exactly as you would for any AI Employee — add agents from the library, wire edges, map each agent's inputs with {{...}} references, and branch with conditional edges where you need to. See Build your first workflow for the full walkthrough and Writing effective Instructions for tuning each agent.

Two things behave specifically for dashboards:

Human in the loop runs in form mode. A dashboard run can't hold a live chat with a row, so conversation-mode HITL isn't available on a dashboard agent — the builder switches any conversation-mode HITL to form mode automatically. Use form or external_form to collect a person's input mid-run; the paused row surfaces the form for review. See Designing human-in-the-loop forms.
Outputs come from Publish nodes. Only fields declared on a Publish node become dashboard columns.

Step 4 — declare output columns with a Publish node

A Publish node declares the fields the workflow exposes as its result. For a dashboard AI Employee these are the output columns, and they're the single source of truth for what the table shows:

Add a Publish node and connect your final agent(s) to it.
Define the output fields and wire each upstream value to the field it should populate.

A workflow with no Publish node simply shows no output columns — rows still run, but the table won't display a result. If you later remove a field from the Publish node, any column that was populated from it is shown as a legacy column so historical rows keep their data.

Step 5 — publish

Real runs always execute the active published version. Save your draft, test it, then Publish to make the version live. Publishing validates the whole graph — a missing LLM provider, an invalid HITL assignee, or a structurally invalid DAG blocks the publish. See Build your first workflow for the save / test / publish model.

Scheduling needs a published version. Scheduled runs always execute the latest published version, so set a schedule on the Start node only after you've published once.

Running the dashboard

Open the AI Employee's Dashboard tab. It's organized as one or more tables (use the table selector to switch). From the toolbar you can:

Add a row — opens a form built from your input schema. Fill in the fields (including uploading files), and the row is created and the run is triggered. When a row includes file inputs, it waits in a draft state until the files finish processing, then runs automatically.
Export the table — download the current table as CSV or XLSX. The export columns mirror the input and output columns.

On the rows themselves you can:

Re-run a single row — re-runs the workflow with the same inputs (handy after you fix Instructions or a knowledge base).
Edit a row's inputs and re-run.
Show work — open a step-by-step trace of the run for that row, labeled by node, so you can see what each agent did.
Review a paused row — when a node pauses for a person, the row goes to a paused state and a review drawer lets the assignee complete the form (or cancel the request). The run resumes from where it paused once they respond.

Select multiple rows to use the bulk actions bar: run selected re-runs them all, or delete selected removes them.

Dashboard AI Employees show per-row execution history inline (via Show work and the paused-row review), so there's no separate Audit tab the way other interaction types have — the table is the audit trail.

Reference

Concept	Where it comes from
Interaction type	`dashboard` — set at creation, shown as the AIE's main tab.
Input columns	The Start node's input schema (one column per field; 3+ non-file fields collapse into one Inputs column).
Output columns	The fields declared on each Publish node. No Publish node → no output columns.
A row	One independent workflow run, with its own status, inputs, outputs, and trace.
Triggers	Manual Add / re-run from the table, a schedule on the Start node, or the workflow run API.
HITL	`form` / `external_form` only — conversation mode is converted to form mode for dashboards.
Export	CSV or XLSX of the active table.

What's next

Build your first workflow — the workflow that powers each row, including the Start, Publish, save / test / publish, and schedule mechanics.
Worked examples — end-to-end builds, including a document-extraction dashboard that uses the Data Extractor and Rule Validator agents.
Designing human-in-the-loop forms — pause a row for a person with an inline or external form.
Data Extractor Agent and Rule Validator Agent — the agents most often wired into a dashboard.