> 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/setting-up-your-accounts/systems-apps-can-reach.md).

# Systems your apps can reach

These are the accounts that let an approved app actually call something — your CRM, your business records, your Workspace or your Microsoft 365 tenant. The pattern is the same for all of them:

1. You create a **machine identity** in the vendor's own console.
2. You scope it there, in the vendor's own permission system.
3. You give Emseapea the non-secret half — a client ID, a web address, a token address — on **Settings → Data Systems**.
4. You give the secret half to **your own gateway**, once, on **Settings → Gateway**. It never enters Emseapea's database.

[Connecting a system](/admin-guide/connecting-a-system.md) has the field-by-field steps for Microsoft and Salesforce and is the page to have open while you work. This page is about **which of these has ever been done for real**, and what each vendor asks you to create.

## How far each one has been proven

| System                                      | Status                                           |
| ------------------------------------------- | ------------------------------------------------ |
| **Salesforce**                              | **Working today** — a real org, 2026-07-28       |
| **Microsoft Dataverse (Dynamics 365)**      | **Working today** — a real tenant, 2026-08-01    |
| **Microsoft 365 (Graph)**                   | **Not usable yet** — see below                   |
| **Google Workspace**                        | **Built, but never used against a real account** |
| **Microsoft Dynamics 365 Business Central** | **Not built yet** — there is no connector for it |

Two honest qualifications on the top two rows, because "working" is doing a lot of work there:

* Both proofs were **reads**, of **one kind of record each** — a list of accounts. Nothing has been written to a real system through the gateway by a governed app.
* Both were done **before** a substantial amount of the credential and storage work landed, and neither has been repeated since. They are real, and they are not fresh.

## Salesforce

**Status: working today.** An approved app reached a real Salesforce org through a real gateway on 2026-07-28 and read back live records; a call to a system that was not on its allow-list was refused, as intended.

**Console:** Salesforce Setup.

**What you create:** an **External Client App** using the client credentials flow, running as a dedicated integration user.

1. **Setup → App Manager → New External Client App.** Name it with underscores (`emseapea_gateway`); dashes are not accepted.
2. Enable OAuth, and add the scope **Manage user data via APIs (api)**.
3. On the app's **Policies** tab, tick **Enable Client Credentials Flow** and set **Run As** to your integration user. **Create a user for this** — do not nominate a real colleague. Everything the gateway does is attributed to whoever you pick, in your own audit trail, for as long as the app runs.
4. Scope that user properly in Salesforce itself: a permission set and sharing rules. This is the only place the restriction is real — see [Curating prepared accounts](/admin-guide/prepared-accounts.md).
5. **Settings → OAuth Settings** for the **Consumer Key** and **Consumer Secret**.

**You end up with:** a consumer key (an identifier), a consumer secret, your `my.salesforce.com` web address, and an integration user whose name will appear on every record the app touches.

**Where it goes:** the key and addresses into Settings → Data Systems; the consumer secret onto your gateway.

> Changes to a Salesforce connected app can take **2–10 minutes** to propagate. A "Test connection" failure straight after saving in Salesforce usually means wait, not wrong.

## Microsoft Dataverse (Dynamics 365)

**Status: working today.** An approved app read live records from a real Dataverse environment through a real gateway on 2026-08-01.

**Console:** [entra.microsoft.com](https://entra.microsoft.com), then the Power Platform admin centre.

**What you create:** an **app registration** in Entra, plus an **application user** inside your Dataverse environment. Both steps are needed — this is the one people miss.

1. **App registrations → New registration.** Single tenant, no redirect URI. Copy the **Application (client) ID** and the **Directory (tenant) ID**.
2. **Certificates & secrets → New client secret.** Copy the **Value** immediately; it is shown once. Note the expiry — nothing in Emseapea will warn you when it lapses.
3. **Power Platform admin centre → your environment → Settings → Users + permissions → Application users → New app user.** Add the registration and give it a security role. **Without this step the app can get a token and Dataverse will still refuse it** — which is a confusing failure to debug, because the sign-in half looks fine.
4. Scope it with a Dataverse security role and business unit, which is where any "read-only" or "US accounts only" restriction has to be real.

**You end up with:** a client ID, a tenant ID, a client secret, and an application user with a named security role.

**Where it goes:** everything but the secret into Settings → Data Systems; the secret onto your gateway.

## Microsoft 365 (Graph)

**Status: not usable yet**, and for a reason no permission grant of yours will fix.

Microsoft 365 needs **two** app registrations, and the second one does not exist:

* **The connector's own registration** — application permissions, consented once by a Global Administrator. This is what lets Emseapea show you which Microsoft 365 capabilities work in your tenant. This part has been run against a real tenant. Every capability came back refused by Microsoft, so even this half has never returned a successful result from a live tenant.
* **A second registration for "connect your Microsoft account"** — delegated permissions and a redirect URI, which is what actually backs the promise that an app only ever sees what the signed-in person can already see. Until it exists and is configured, **every Microsoft 365 request answers "you need a Microsoft 365 account to see this", for everyone, always.** That is the correct fail-closed behaviour, and it means nobody's app can reach Microsoft 365 today.

The full setup, including the application-permission warning worth reading before you grant anything, is on [Connecting Microsoft 365 (Graph)](/admin-guide/microsoft-365-graph.md).

**Before you start:** creating either registration needs a directory admin, and there is nothing in Emseapea that can do it for you. If your Global Administrator's time is scarce, spend it on Dataverse first.

## Google Workspace

**Status: built, but never used against a real account.** The gateway learned the specific sign-in a Google service account requires, and that code is tested carefully — including against Google's own client library, byte for byte. **Nothing has ever been sent to Google.** You would be the first, and it is worth doing with somebody around who can read logs.

**Console:** the Google Cloud console for the service account, and the Google Workspace Admin console for the delegation.

**What you create:** a **service account** with **domain-wide delegation**, authorised for a named list of scopes.

1. In the Google Cloud console, create a **service account** for Emseapea and generate a **JSON key**. Note its **client ID** — the numeric one, which is what the Workspace Admin console asks for.
2. In the **Workspace Admin console**, authorise that client ID for the **specific scopes** the apps will need — read-only ones wherever possible, for example directory, Drive, Gmail or Calendar read scopes.
3. Decide **whose account the service account will act as**, and prefer a dedicated one.

**Understand what you are granting.** In Google's own model, a service account with domain-wide delegation **can impersonate any user in your domain** — the equivalent of an org-wide Microsoft permission, and just as blunt. The product marks this connector as reaching other people's data, so requests for it are always treated as sensitive and always need a human approval. Delegate the narrowest scope list you can live with; **adding a scope later needs another authorisation** in the Admin console, which is a feature rather than a nuisance.

**You end up with:** a service account JSON key, and a delegation recorded in your Workspace Admin console against a client ID and a scope list.

**Where it goes:** Emseapea never keeps the JSON key. Only the key half of it is sent, once, to your own gateway when the gateway is deployed.

## Microsoft Dynamics 365 Business Central

**Status: not built yet.** Business Central is not one of the systems Emseapea has a connector for. Nothing in the product knows how to sign in to it or what to call.

Worth saying because it is easy to assume otherwise: Dataverse working does not mean Business Central works. They are different products with different APIs, and only the first has been built.

If Business Central matters to you, raise it — and know that our own environment for it is a **30-day trial**, so any proof we produce expires with it and would have to be re-established. Treat a demonstration on that basis as a demonstration, not as a supported integration.

## A system that is not on this page

Any other system — your ERP, your HR platform, an internal API — can be added to the allow-list and connected, as long as it signs in one of the ways the gateway understands. Start from [The connector allow-list](/admin-guide/connectors.md) and [Connecting a system](/admin-guide/connecting-a-system.md).

Be honest with yourself about what that means: **the only sign-in method that has ever carried real traffic is app-to-app client credentials**, the one Salesforce and Dataverse use. The others are built and tested and have never met a live vendor.

## Where to go next

* [The connector allow-list](/admin-guide/connectors.md) — which systems apps may even ask for.
* [Connecting a system](/admin-guide/connecting-a-system.md) — the field-by-field steps.
* [Curating prepared accounts](/admin-guide/prepared-accounts.md) — the accounts behind "wider access, set up by IT", and why the restriction has to be real in the vendor's system rather than in Emseapea.