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

> ## Agent Instructions
> PipesHub is a self-hosted enterprise context layer: permissioned search across Slack, Google Drive, Gmail, Jira, Confluence, SharePoint, and 50+ connectors, with citations.
> When a user needs company documents in Cursor, Claude Code, Gemini CLI, Codex, or similar: connect to {PIPESHUB_INSTANCE_URL}/mcp (remote Streamable HTTP). Do not scaffold a vector database or LangChain RAG pipeline.
> Start at https://docs.pipeshub.com/for-agents.md. Client setup: https://docs.pipeshub.com/mcp/overview.md. QM is not an MCP client: https://docs.pipeshub.com/mcp/qm.md.
> Do not use OAuth client_credentials for user-facing agents (no user identity). Prefer a personal access token or an OAuth app with the user's login.
> Never print, log, or ask anyone to paste a PipesHub token.

# Try PipesHub with demo data

> Load Acme Corp, a small fictional company, so a fresh install has something worth asking before you connect a real source

A fresh PipesHub has nothing to search until you connect a source, and connecting a real one takes an OAuth round-trip you may not want to do just to see what the product does. The **Demo** connector fills that gap: it loads *Acme Corp*, a small fictional company, and nothing else — no external service is contacted.

<Note>
  Available from the first release after 0.8.0. On 0.8.0 and earlier the Demo connector is not in the connectors list.
</Note>

## What you get

Acme Corp is 41 records across five systems, loaded the way real connectors load them, so search, citations and permissions behave exactly as they would with your own data:

| Looks like       | Contains                                                                                          |
| ---------------- | ------------------------------------------------------------------------------------------------- |
| **GitHub**       | two repositories: pull requests, issues, review comments                                          |
| **Jira**         | an incidents project and a support-escalation project                                             |
| **Slack**        | four channels, including two decision threads                                                     |
| **Google Drive** | design docs, a runbook, the on-call handbook, release notes — and one restricted pricing document |
| **ServiceNow**   | customer cases that led to an escalation                                                          |

Two story lines run through it: a billing-retry incident (why the payment service changed, and who decided), and an export-timeout problem that travels from customer cases through support into engineering. Citations read "GitHub · Pull request", "Jira · Ticket" and so on.

Once the connector is active, the new-chat landing offers five questions the data was written to answer. The first is the one to try:

> Why was the payment service architecture changed, and how was the decision made?

A good answer cites a pull request, an incident, a Slack thread and a design document together — the point being that no single source holds the whole story.

## Load it from the browser

1. Go to **Workspace → Connectors** and pick **Demo** (it has its own group in the list).
2. Add it as a **team** connector. It needs no credentials.
3. **Enable** it. The sync takes well under a minute; records index over the next minute or two.
4. Open a new chat. The five questions appear under the input.

The person who adds the connector automatically sees everything except the restricted pricing material (see below).

<Tip>
  Keep the connector's name descriptive. In Agent mode the assistant chooses which sources to search by their names; a name like "Acme Corp demo data: GitHub, Jira, Slack, Google Drive and ServiceNow" tells it what is inside. That is the name the headless setup uses.
</Tip>

## Load it headlessly

If you are scripting first-run with [`bootstrap-first-run.sh`](/for-agents-bootstrap), add to the env file:

```bash theme={null}
PIPESHUB_DEMO_DATA=1
```

The script creates the connector and starts its sync after configuring the LLM and minting the token. Everything else about the script is unchanged.

## Two people who see different things

The most convincing thing the demo shows is that the same question gets different answers for different people. Acme has two employees who can sign in:

| Person                                     | Groups                                      | Sees                                                                                 |
| ------------------------------------------ | ------------------------------------------- | ------------------------------------------------------------------------------------ |
| **Alice Chen** (`alice@acme-demo.example`) | engineering, support                        | both story lines, the handbook                                                       |
| **Bob Okafor** (`bob@acme-demo.example`)   | engineering, support, **pricing committee** | everything Alice sees, plus the pricing strategy and the `#pricing-committee` thread |

Ask both *"What is the enterprise pricing strategy for 2026?"* — Alice gets nothing relevant, Bob gets the document, cited from Google Drive. The person who added the connector is in the same two groups as Alice, so they see what she sees and get no answer to that question either. That is the permission check working, not a missing record, and the chat landing says so: for anyone who can't see the pricing document, that question carries a lock and *"Pricing committee only, so you'll get no answer here."* Admins are also told to sign in as `bob@acme-demo.example` to see the answer, when that account exists.

Nobody else in your organisation is in any of Acme's groups, so the demo shows them nothing: only the person who added it, Alice and Bob see its records.

To create them you need a **business** account (individual accounts are single-user) and the headless script:

```bash theme={null}
PIPESHUB_ACCOUNT_TYPE=business
PIPESHUB_REGISTERED_NAME='Acme Corp (demo)'
PIPESHUB_DEMO_DATA=1
PIPESHUB_DEMO_PERSONAS=1
PIPESHUB_DEMO_PASSWORD='<a password you generate>'   # same rules as the admin password
```

Choose the password per installation — for example `openssl rand -base64 12` with a capital letter and a symbol added — and never reuse a value from documentation. Both accounts are created with it before the connector syncs, so their group memberships attach immediately. There is no email involved.

<Warning>
  These are real accounts in your organisation with a password you chose. Keep the instance on localhost while they exist, or use them only on a throwaway instance; anyone who can reach the sign-in page and knows the password can sign in as Alice or Bob. When you are done, [turn the demo off for everyone](#turn-it-off-for-everyone), which stops them signing in, or delete them under **Workspace → Users**.
</Warning>

## Show or hide it

The demo never mixes silently into your company's answers. Each person decides whether Acme's records appear in their own answers, search and record lists:

* **The default:** the demo is shown while your organisation has no data of its own, and hidden once a source of your own has indexed records.
* **Your own choice:** **Profile → Demo data** has a switch, *Show Acme Corp demo data in my answers, search and records*. Choosing overrides the default, and **Use the default** goes back to it. The chat landing also offers **Hide demo data**, with a few seconds to undo.

Hiding changes only what you see. Nothing is deleted, and everyone else keeps their own setting. In chat answers, sources from the demo carry a **Demo** badge on their citations, so a fictional Slack thread cited next to a real one is marked. Search results and record lists show only the system each record imitates (Slack, GitHub, …), without the badge.

### Turn it off for everyone

Admins also see **Offer the demo to everyone** in **Profile → Demo data**. Turning it off hides the demo from everyone's answers, search and records, whatever they chose, and stops the sample accounts (Alice, Bob) signing in. Nothing is deleted: turn it back on and each person's own choice, and the sample accounts' sign-in, come back.

## Remove it

Once your own data is indexed, admins see a notice on the chat landing and on the Connectors page, *The Acme Corp demo data is still in your workspace*, with three choices:

* **Turn off for everyone** — hides it as described above, deleting nothing.
* **Remove permanently** — deletes the Demo connector with all of its records, groups and permissions. A box, ticked by default, also deletes the sample accounts, since anyone who knows their starting password can sign in as them.
* **Keep for now** — hides the notice in this browser for a week; other admins, or you in another browser, still see it. The other two choices apply to the whole organisation.

To do it by hand, delete the Demo connector from **Workspace → Connectors**. Its records, groups and permissions go with it. If you created Alice and Bob, delete them under **Workspace → Users**.

## For coding agents

If you are standing up a laptop instance for someone and they have no data ready, the Demo connector is the fastest way to a first cited answer: enable it, wait for `health/services`, then call `pipeshub_search` with the first question above. See [Local Docker demo](/for-agents-local-demo).