> For the complete documentation index, see [llms.txt](https://docs.emseapea.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.emseapea.ai/builder-guide/requesting-an-app.md).

# Requesting an app

However it starts — the web form, a Linear card, or telling your AI *"I want to build an expense app that needs the HR and ERP systems"* — a request answers the same set of questions:

1. **Title and purpose** — what it's called, and what it does and for whom (this is the sentence an auditor reads in two years, so make it true).
2. **What kind of information is involved** — public, everyday work information, or something sensitive (commercially sensitive, personal details, financial, health). **This doesn't restrict what the app can see** — the systems and accounts you choose below are what do that. Ticking a sensitive one means a colleague has to sign off before each future deploy; it's recorded in the audit trail either way, whichever you pick.
3. **Whether it needs somewhere to keep its own data** — files, structured data, both or neither. This is your app's *own* storage, not one of the systems below, and it is asked here because the answer to question 2 is what narrows the list of places you can be offered. If you ask for files, you're also asked whether the app may change them or only read them. See [Storing files and data in your app](/builder-guide/storing-files-and-data.md).
4. **Which systems it will touch** — picked from your org's allow-list. You *can* name a system that isn't on the list: the request is then routed to an org admin for review rather than a regular approver. Nothing is silently granted, and nothing is silently dropped.
5. **Whose data each system should see** — the choice that actually decides what the app can reach. For each system you ticked, pick **only what the person using it can already see**, or **wider access, set up by IT** (choosing an already-prepared account, and seeing exactly what it's limited to). See [The two kinds of access](/builder-guide/kinds-of-access.md) if you haven't already — it answers the question everyone asks about this ("Alice builds a dashboard, Bob opens it — whose data does Bob see?") directly.

A request where every system is "only what the person using it can already see" — and every system is on your org's list — needs no human decision at all: it's approved the moment you submit it, because it can never show anyone more than they could already see by signing in directly. Anything else (any prepared account, any off-list system) goes to your approvers as usual.

**Read or also write is asked in exactly one place, and not in the others.** For an app's **own files**, question 3 asks whether it may change them or only read them, and your gateway turns away a write from a read-only app before it reaches the storage. It is not asked for a **system** you reach (question 4) or for a **database**, because nothing there would carry the answer out — and a control that recorded an answer nobody checked would be worse than not asking.

Submitting creates a permanent intent record and notifies the approvers (or, for a fully self-limiting request, approves it immediately — see above). Track it with `check_request_status` or the **My Apps** page. Decisions come with a note and an email either way.