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

# External users switcher

> Each end user gets their own layer: agents, connections, and data. How the switcher works, with full examples.

The sidebar **End user** control (labeled **External user (eUID)** in the UI) picks **which person you are acting as** inside the current project. It is not your Flowra login, and it is not the project switcher.

Think of it as a **personal layer** under the project: that person’s agents, connections, knowledge, tables, skills, and chat threads live there — separate from everyone else’s.

## Each end user has their own layer

Inside one project, shared pieces stay at the **project** layer — including **API keys**, **auth configs**, **toolkits / tools** (catalog + custom project tools), and **MCP servers**. Everything personal sits under an **external user**:

```text theme={null}
Project: Acme Support Bot
├── Shared (project layer — same for every end user)
│   ├── API key
│   ├── Auth configs (e.g. Slack OAuth app setup)
│   ├── Toolkits & tools (catalog + custom tools)
│   └── MCP servers
├── External user: customer_alice
│   ├── Her Slack connection (her OAuth tokens)
│   ├── Her agent “Alice Support” (she picks which shared tools to use)
│   ├── Her Knowledge (Alice’s FAQ / policies)
│   ├── Her Tables (Alice’s tickets)
│   └── Her Chat threads
└── External user: customer_bob
    ├── His Slack connection
    ├── His agent “Bob Ops”
    ├── His Knowledge
    ├── His Tables
    └── His Chat threads
```

So: **tools and MCP are configured once on the project**; each end user builds **their own agents** on top, with **their own connections and data**. Alice and Bob can both use the same Slack toolkit — they do not share each other’s Slack login or knowledge base.

When you select **customer\_alice** in the switcher, Workflows, Connection, Knowledge, Database, and Chat show **Alice’s** stuff — not Bob’s.

Full nested map: [Projects and API keys](/product/projects-and-keys).

```mermaid theme={null}
flowchart TB
  You[Your dashboard login]
  Proj[Project switcher]
  Ext[End user switcher]
  You --> Proj
  Proj --> Ext
  Ext --> Conn[Connections]
  Ext --> Agents[Agents and skills]
  Ext --> Data[Knowledge and tables]
  Ext --> Chat[Chat threads]
```

## Examples

### Example 1 — SaaS: each customer builds in their own layer

You ship a product where every customer should have their own support agent, their own docs, and their own Slack.

<Steps>
  <Step title="One project">
    Create a project, for example **Acme Support**. Configure Slack **auth config** once at project level.
  </Step>

  <Step title="Add end users">
    **Add end user** → `customer_alice`, then `customer_bob` (or create them automatically when they first connect via your app with `x-username`).
  </Step>

  <Step title="Build Alice’s layer">
    Switch End user to **customer\_alice**. Connect Alice’s Slack. Ingest Alice’s FAQ into [Knowledge](/product/data/knowledge). Create agent **Alice Support**, attach that knowledge and Slack tools, save, test in Chat.
  </Step>

  <Step title="Build Bob’s layer">
    Switch to **customer\_bob**. Connect **Bob’s** Slack (different workspace). Create **Bob Ops** with Bob’s knowledge and tables. Alice’s agent and docs do not appear in this list.
  </Step>

  <Step title="Run from your backend">
    Your API always sends `x-api-key` for the project plus `x-username: customer_alice` or `customer_bob`. Each customer only ever uses their own connections and data. See [Multi-tenant basics](/recipes/multi-tenant-basics).
  </Step>
</Steps>

**What Alice never sees:** Bob’s Slack token, Bob’s knowledge chunks, Bob’s agents, Bob’s chat history.

### Example 2 — You test “as the customer” in the dashboard

You are developing; you want to see exactly what customer `shop_42` sees.

<Steps>
  <Step title="Create or pick the end user">
    **Add end user** with label `shop_42` (same string you will use as `x-username`).
  </Step>

  <Step title="Switch to them">
    End user switcher → **shop\_42**.
  </Step>

  <Step title="Build in their layer">
    Create an agent, connect Gmail/Slack for that shop, add a Knowledge collection with *their* policies, attach under **Data access**, chat to verify.
  </Step>

  <Step title="Switch back">
    Select **Default user** (or another username) when you return to your own experiments. Lists change with the switcher — that is expected.
  </Step>
</Steps>

### Example 3 — Agency: one project, many client layers

An agency keeps **one Flowra project** per practice area, and one **end user per client**.

| End user           | What lives in that layer                                           |
| ------------------ | ------------------------------------------------------------------ |
| `client_northwind` | Northwind’s agent, Notion/Slack connects, Northwind knowledge base |
| `client_contoso`   | Contoso’s agent, Contoso’s tables for leads, Contoso’s Gmail       |

Switch End user before you edit a client’s agent or connect their OAuth. Never connect Contoso’s Slack while `client_northwind` is selected.

### Example 4 — Channel or widget creates the layer for you

You do not always pre-create usernames.

1. Attach a [messaging channel](/product/entry-points-and-channels) or [widget](/product/widgets-and-embeds) to an agent.
2. Someone messages Telegram / visits the embed.
3. Flowra creates an external user (source **Channel** or **Widget**).
4. That person’s threads (and later connections/data you add under them) stay in **their** layer.

Open [External Users](https://flowra.dev/dashboard/external-users) to see those rows; use the switcher to inspect or extend that layer (for example attach Knowledge for that visitor’s tenant).

### Example 5 — Same tools, different data (support vs ops)

Project shares the Gmail/Slack **auth configs**. Two end users:

* `role_support` — agent with Knowledge = refund policy; table = tickets
* `role_ops` — agent with Knowledge = runbooks; table = incidents

Both can use the same toolkits. Switching End user swaps which agent list and which RAG/tables you see — so support never accidentally chats with ops runbooks selected.

## Where to find it

In the sidebar, under the project switcher, open **End user**. Search, pick **Default user**, pick another row, or **Add end user**.

Full list and management: [External Users](https://flowra.dev/dashboard/external-users) (resource usage per user when the UI shows it).

## Default user vs named users

| Selection          | Meaning                                                                                                 |
| ------------------ | ------------------------------------------------------------------------------------------------------- |
| **Default user**   | Project default identity. Fine for solo work when you are not simulating a customer.                    |
| **Named end user** | A person/tenant you created, or one created from a channel/widget. **Their** agents and data live here. |

When you switch, Chat threads reload, and Workflows / Connection / Knowledge / Database follow that user’s scope. If something “disappears,” check **project** and **end user**.

## How users get into the list

| Source (UI)                  | How it is created                                             |
| ---------------------------- | ------------------------------------------------------------- |
| **Manually created / Panel** | **Add end user** — stable label (`email`, `customer_1042`, …) |
| **Channel**                  | Message on Telegram, Slack, WhatsApp, Discord, Gmail, …       |
| **Widget**                   | Visitor on a [site embed](/product/widgets-and-embeds)        |
| **Project default**          | Built-in default                                              |

Allowed characters for manual labels: English letters, numbers, and `.` `_` `@` `-` (no spaces or emoji). Use the **same** label as `x-username` on the API.

## Practical tips

* Build agents and connect OAuth **while the correct end user is selected**.
* Each end user can have **their own agents** with **their own Knowledge/Tables** — that is the point of the layer.
* Deactivated users cannot stay selected; the UI falls back to default. The project default user cannot be deactivated.
* Deep API rules: [Multi-tenancy](/guides/multi-tenancy). Hands-on API: [Multi-tenant basics](/recipes/multi-tenant-basics).

## Related

* Nested project vs end-user map: [Projects and API keys](/product/projects-and-keys)
* [Toolkits and tools](/product/toolkits-and-tools) · [Skills](/product/skills)
* [Workflows in the dashboard](/product/workflows-in-dashboard)
* [Knowledge](/product/data/knowledge) · [Database](/product/data/database)
* [Connections](/product/connections)
* [Entry points and channels](/product/entry-points-and-channels)