Skip to main content
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:
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.

​
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.
1

One project

Create a project, for example Acme Support. Configure Slack auth config once at project level.
2

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).
3

Build Alice’s layer

Switch End user to customer_alice. Connect Alice’s Slack. Ingest Alice’s FAQ into Knowledge. Create agent Alice Support, attach that knowledge and Slack tools, save, test in Chat.
4

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.
5

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.
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.
1

Create or pick the end user

Add end user with label shop_42 (same string you will use as x-username).
2

Switch to them

End user switcher → shop_42.
3

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.
4

Switch back

Select Default user (or another username) when you return to your own experiments. Lists change with the switcher — that is expected.

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

An agency keeps one Flowra project per practice area, and one end user per client. 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 or widget 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 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 (resource usage per user when the UI shows it).

​
Default user vs named users

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

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. Hands-on API: Multi-tenant basics.