> ## Documentation Index
> Fetch the complete documentation index at: https://help.statisfy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuring a Digital Worker

> Set a Digital Worker's persona, knowledge, tools, account assignment, autonomy, and the channels it works on.

<Note>
  **Preview feature.** Digital Workers are available to selected workspaces while we refine them. Behavior and controls may change.
</Note>

A **Digital Worker** is an AI teammate (for example, a Digital CSM) that reads a customer's context and responds on the channels you enable. This page is the reference for everything you configure on a worker.

## Opening a worker

Go to **Digital Workers** and open (or create) a worker, then click **Configure**. Each worker card shows its name, a status badge (**Active**, **Draft**, or **Archived**), and a shield if it's a built-in system worker.

The configuration form has five tabs: **Overview**, **Portal**, **SDK**, **Email**, and **Slack**. Make your changes, then click **Save changes** (the button stays disabled until there's something valid to save).

## Overview tab

### Identity

How the worker presents itself to customers.

| Field                      | What it does                                                                                                                                                 |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Avatar**                 | The picture shown on the worker's messages (PNG, JPG, or WebP, max 10 MB).                                                                                   |
| **Name**                   | The worker's display name (e.g. *Rosie*).                                                                                                                    |
| **Status**                 | **Draft**, **Active**, or **Archived**. Only active workers respond.                                                                                         |
| **Description**            | A short internal description shown to admins.                                                                                                                |
| **Greeting**               | The first message the worker sends in a new conversation.                                                                                                    |
| **Persona voice**          | A paragraph describing tone and style, merged into the worker's system prompt.                                                                               |
| **Guardrail instructions** | Hard safety rules the worker must always follow — injected with the highest precedence.                                                                      |
| **AI disclosure mode**     | How clearly the worker identifies as AI: **Transparent** (always discloses), **Branded** (mentions only the worker name), or **Hybrid** (context-dependent). |

### Capabilities

**Knowledge bases** — the datasets the worker can query at runtime to ground its answers. Without a knowledge base, replies are generic. See [Knowledge Base](/knowledge-base/overview).

### Third-party MCP tools

Choose which connected [third-party MCP tools](/integrations/third_party_mcp_servers) this worker may use, and add an **injected prompt** that steers when and how it uses them (for example, *"Use the Jira tools to file a ticket when a customer reports a hardware issue"*). The injected prompt is appended to the worker's system prompt.

<Note>
  Which tools require human approval is set on the **Integrations** page, not here — tools marked **Approval** pause for review before they run. See [Third-Party MCP Servers](/integrations/third_party_mcp_servers).
</Note>

### Account assignment

An **account segment** defines which customer accounts this worker is responsible for. This is required before you can save.

### CSM assignment

Who reviews the worker's escalations (held drafts and approval-required actions).

* **Named** — route each escalation to the owner named in an account **owner field** you pick.
* **User pool** — a set of app users eligible to review, with an assignment **strategy**: **Smart** (picks the most relevant reviewer), **Round robin** (distributes evenly), or **Unassigned** (left in a shared bucket for someone to claim).

### Autonomy

Controls when the worker can act without human approval.

* **Default mode** — **Smart** sends automatically, looping in a human only when needed; **Human-in-the-loop (HIL)** always queues replies for human approval.
* **Per-surface overrides** — optionally set a different mode for a specific channel (Portal, SDK, Email, or Slack). Any surface without an override follows the default mode.

## Channel (surface) tabs

Each channel has an enable switch. When a reply is **held for human approval**, the customer can be shown an **acknowledgement message** in place of the drafted reply, so they know their message was received.

### Portal

Makes the worker reachable on your customer portal. When enabled, set the **Acknowledgement message** (required).

### SDK

Embeds the worker in your own app via the Statisfy SDK. When enabled, set the **Acknowledgement message** (required). This tab also gives you the **Worker ID**, **Base URL**, and **Publishable key**, plus copy-paste snippets to mint a session token on your server and render the widget in your app.

### Email

The worker can work email two independent ways (turn on either or both):

* **Scan connected mailboxes** — watch the mailboxes you connect and reply from the address each email arrived at. Add mailboxes from the **Add mailbox** picker (Gmail or Microsoft 365); only mailboxes connected with both read and send permission appear.
* **Receive forwarded email** — auto-forward support mail to the worker's tenant address; replies come from a verified sending domain. This requires at least one verified domain (**Settings → DNS**). Set the **Company address** replies come from and copy the per-tenant **Forwarding address** to set up auto-forwarding in Gmail or Microsoft 365.

An **Auto-reply on hold** toggle sends an automatic acknowledgement in-thread when a reply is held for approval; turning it on reveals the **Acknowledgement message**. See [Email surface](/digital-workers/email_surface) for the full setup.

### Slack

The worker replies to customer messages in the Slack channels it can access. Requires a connected Slack app (**Settings → Integrations**). The same **Auto-reply on hold** acknowledgement option is available here. See [Slack surface](/digital-workers/slack_surface).

## Preview a worker (dry run)

Click **Preview** (in the footer) to open a dry-run page for the worker. Pick an **Account**, a **From (contact)**, and type a **Message**, then click **Run preview** to see the reply the worker *would* send — **nothing is saved, sent, or executed**. The preview reflects the **saved** configuration, so save first to preview recent edits.

The result tells you whether the reply would be **Deferred** (held for a human — always the case on a channel set to HIL, or when the worker isn't confident) or sent directly.

## Related

<CardGroup cols={2}>
  <Card title="The Digital Workers pool" icon="inbox" href="/digital-workers/worker_pool">
    Watch conversations, review held drafts, and approve tool calls.
  </Card>

  <Card title="Trying out Digital Workers" icon="flask" href="/digital-workers/trying_out_digital_workers">
    End-to-end walkthrough across Slack, email, and the portal.
  </Card>
</CardGroup>