> Source: https://builder.ema.ai/v2/builder-guides/dashboard-ai-employee
> Title: Creating a Dashboard AI Employee

# 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](/builder/v2/builder-guides/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.

> [INFO]
> **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](/builder/v2/builder-guides/build-your-first-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](/builder/v2/agent-reference/intent-classification), a [Data Extractor](/builder/v2/agent-reference/extraction), a [Search & Respond](/builder/v2/agent-reference/search-and-respond) agent, a [Rule Validator](/builder/v2/agent-reference/rule-validation) — 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](/builder/v2/core-concepts/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](/builder/v2/builder-guides/voice-ai-employee)).

> [TIP]
> 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](/builder/v2/builder-guides/build-your-first-workflow) for scheduling.

## Step 1 — create the AI Employee as a dashboard

1.  In the AI Employees area, create a new AI Employee.
2.  Give it a name, description, and (optionally) a group and icon.
3.  Set the **interaction type** to **Dashboard**.
4.  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.

1.  Open the **Configuration** tab and edit the workflow, or open the AI Employee builder directly.
2.  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**.
3.  Save the schema.

> [WARNING]
> 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](/builder/v2/builder-guides/build-your-first-workflow) for the full walkthrough and [Writing effective Instructions](/builder/v2/builder-guides/writing-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](/builder/v2/builder-guides/designing-hitl-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:

1.  Add a **Publish** node and connect your final agent(s) to it.
2.  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](/builder/v2/builder-guides/build-your-first-workflow) for the save / test / publish model.

> [INFO]
> **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.

> [TIP]
> 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](/builder/v2/builder-guides/build-your-first-workflow) — the workflow that powers each row, including the Start, Publish, save / test / publish, and schedule mechanics.
-   [Worked examples](/builder/v2/builder-guides/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](/builder/v2/builder-guides/designing-hitl-forms) — pause a row for a person with an inline or external form.
-   [Data Extractor Agent](/builder/v2/agent-reference/extraction) and [Rule Validator Agent](/builder/v2/agent-reference/rule-validation) — the agents most often wired into a dashboard.