# Permissions

Which permission set an account needs depends on how it uses the extension, a headless API integration, an interactive user who already holds Business Central rights, or an internal clerk who works staged documents in the client. The extension ships three assignable sets; assign the one that matches the account.

## The three permission sets

| Permission set | Grants | Use it for |
| --- | --- | --- |
| `EONE Integration` (caption “eOne Integration”) | **Execute only** on the API pages, queries and the availability codeunits: plus the extension's own tables (Item Availability snapshot & buffer, staging tables). It grants **no** access to the extended base tables (Customer, Item, Sales/Purchase documents, journals…). | An account that **already has** the necessary Business Central data permissions (e.g. a licensed user running the integration under their own role). This set opens only the endpoints on top of their existing rights. |
| `EONE Integ. Full` (caption “eOne Integration Full”) | Everything the lean set grants, **plus full read/write on the base Business Central tables the endpoints touch**: it composes the standard `D365 BASIC` and `D365 BUS FULL ACCESS` sets rather than hand-listing tables. | A **dedicated service-to-service (S2S) or Microsoft Entra application account** that has no other permissions of its own. This is the usual choice for a headless integration. |
| `EONE Documents` (caption “eOne Integration Documents”) | A **narrow, client-UI-only** set: read/write on the four staging tables and execute on the pages, fact boxes and processing/archive codeunits for the three staged-document families: **ledger documents** (customer/vendor/employee payments, refunds, credit memos, invoices, bank & G/L entries), **expenses**, and **inventory adjustments**: plus **read-only access to route stops** (the Route Stops part shown on warehouse shipments and receipts). Configuration/setup is **read-only**. It grants **none** of the API pages or queries. | An **internal clerk** who reviews, edits, processes, or archives staged integration documents in the Business Central client: not through the API. Pair it with the clerk's normal Business Central role (or `EONE Integ. Full`) so posting to the GL has the base-table rights it needs. |

## Why writes usually need base-table access

Executing an API page, or processing a staged document to the GL, is not enough on its own. Creating or updating a document, a [resolver](https://eonesolutions.github.io/eone-bc-integration/resolvers.md) looking a customer/item up by its key, and the validation Business Central runs on post all read and write the underlying base tables. An account with only `EONE Integration` (or only `EONE Documents`) and no base-table rights of its own gets authorization errors on those operations. For a dedicated integration account, assign `EONE Integ. Full`; for an internal clerk, rely on their existing Business Central role.

> **Note:** Page and table *extensions* are not securable objects, so there is nothing per-endpoint to grant for a covered table. Access to it is governed by the permissions on the base table, which is what `EONE Integration` and `EONE Integ. Full` differ on. The exception is an embedded **part**: the Route Stops list shown on warehouse shipments and receipts is a real page object, so a user who works those standard pages needs a set that grants it, `EONE Documents`, `EONE Integration`, or `EONE Integ. Full` all do.

> **Note:** `EONE Documents` is deliberately API-free. Do not hand it to an S2S account expecting it to open the endpoints. It does not. It is the opposite trade-off from `EONE Integration`: client UI over the staged documents, no API surface.

> **Caution:** Read-only feeds and queries still need the base-table read permission behind them. If a GET returns 403 (or an empty result where you expect data), confirm the calling account holds `EONE Integ. Full` or an equivalent Business Central data permission set, not `EONE Integration` alone.

**Next:** [Endpoint setup](https://eonesolutions.github.io/eone-bc-integration/endpoint-setup.md). The last required step.