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 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.

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.

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.

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. The last required step.