> 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/admin-guide/prepared-accounts.md).

# Curating prepared accounts

A prepared account is what powers **"wider access, set up by IT"** — the other kind of access an app can request, alongside always acting as whoever is signed in. See [The two kinds of access](/builder-guide/kinds-of-access.md) if you haven't read that page yet; this one is about setting the accounts up, not about choosing between the two kinds.

Manage them in **Settings → Data Systems → Prepared accounts**, one section per connector you've already added.

## Adding one

| Field                    | What it is                                                                             |
| ------------------------ | -------------------------------------------------------------------------------------- |
| **System**               | Which connector this account belongs to                                                |
| **What to call it**      | A name builders will recognize when requesting it, e.g. "All US accounts"              |
| **What it's limited to** | The exact slice this account can reach, in your own words                              |
| **Vendor credential**    | Not entered here — held by your gateway, same as every other vendor secret (see below) |

Every app that later requests "wider access, set up by IT" for that system picks from this list rather than a bespoke account being created per app — set it up once here, reuse it as many times as it's genuinely the right fit.

## What a good "limited to" description looks like

This field is not a note to yourself. It is shown **verbatim** — the exact same words — to the builder requesting the account and to the approver deciding whether to grant it. A vague description leaves an approver deciding blind.

**Good, because it's specific and checkable against how you actually configured the account in the vendor system:**

* `read-only`
* `US accounts only`
* `excludes HR records`
* `Read-only, excludes HR records` (a real example: a "Corporate policies feed" account limited to exactly this)

**Not good, because it tells an approver nothing they didn't already know:**

* `full access`
* `everything it needs`
* `as required`

If you can't write a specific "limited to" description, that's usually a sign the account itself isn't scoped yet in the vendor system — go do that first, then describe it here.

## What this does and doesn't do

Emseapea records this description and shows it, live, wherever the account is chosen or reviewed — including on the approval screen, so an admin editing a limit later is reflected immediately rather than showing whatever was true when someone first requested it.

**What it doesn't do: enforce itself.** The actual restriction — read-only, US accounts only, excludes HR records, whatever you wrote — has to be real in the vendor system itself: a Salesforce permission set and sharing rule, a Dataverse security role and business unit, a Microsoft Graph application access policy. Emseapea makes that restriction visible, requested, approved and audited; it does not invent a second permission system on top of the vendor's own. The reasoning for why access is built this way — rather than Emseapea trying to rewrite or filter vendor queries itself — is recorded as **D7, "Fine-grained access scope,"** in the [product's architecture decisions](https://github.com/scmjea/emseapea/blob/main/docs/architecture.md) (engineering repo access required), for anyone who wants it.

## The vendor credential

Exactly like a connector's own client secret, a prepared account's sign-in credential is never entered into Emseapea. It's set on your gateway when it's deployed — see [Connecting a system](/admin-guide/connecting-a-system.md) for where that happens. The **Vendor credential** field here is shown disabled as a reminder of that, not because it's missing.

The account itself is something you create in the vendor's console first, and it must be a machine account rather than somebody's login — [Systems your apps can reach](/setting-up-your-accounts/systems-apps-can-reach.md) covers what that looks like per vendor.

## Removing an account

An account still in use by a live app can't be removed — you'll be told which app depends on it, so you can address that first rather than silently breaking something in production.