Advanced Spreadsheets and Reporting Documentation

Spreadsheets are saved as documents in Business Central and can be shared with other users at controlled access levels. This page covers the Spreadsheets list, saving, and the permission model.

The Spreadsheets List

The Spreadsheets page lists every sheet you have access to — sheets other users have restricted stay hidden. Each row shows the code, description and when the sheet was last saved. The one exception is SUPER: administrators see every sheet in the list (they still cannot open restricted ones), so an orphaned sheet whose owners have left can be deleted or given a new owner. The Spreadsheet Agent's list_sheets tool likewise shows only the sheets you may open.

Action	What it does
New Blank Sheet	Opens the editor with a fresh, empty sheet. It gets its code when you save it.
Edit	Opens the sheet in the editor. With read-only access it opens in preview instead.
Preview	Presents the sheet read-only, with its page regions as tabs at the bottom.
Permissions	Manages who can open the sheet and what they may do. Owner only; opening it on an unrestricted sheet makes you its owner.
Export	Downloads the selected sheet as a compressed `.bcsheet` file — see the section below.
Import	Uploads such a file and creates or replaces a sheet from it.
Refresh	Reloads the list, picking up sheets created or deleted elsewhere and any permission changes.
Create Self-Test Sheet	Creates (or refreshes) DEMO-TEST, a sheet that tests the calculation engine on itself — every row computes something and grades itself.
AI Provider	Opens the AI provider setup used by the Spreadsheet Agent.

Deleting a sheet from the list deletes the document and everything belonging to it: cells, regions, region fields, virtual cell values, conditional formats, scenarios and permissions.

What a Document Stores

A saved spreadsheet document holds the cells (content, styles and write-back bindings), the regions and their field lists, virtual-column values, conditional formats, scenarios, the init code, dragged column widths and row heights, and the sheet's remembered colour scheme. Region paging position and report/SQL result caches are session state and are not saved.

A cell whose content exceeds 2,048 characters cannot be saved — the save fails with a clear message rather than silently truncating a formula.

The Permission Model

Access is controlled per sheet through permission rows:

A sheet with no permission rows is unrestricted — everyone effectively has full access. All sheets start this way.
Saving any sheet with no permission rows automatically inserts an Owner row for the saver. This applies to a new sheet, an unrestricted imported sheet, and an existing sheet whose permissions were removed. From then on, only listed users can open it.
Owners manage the list through the Permissions action.

Access levels

Level	What it allows
Owner	Full control: edit, save, delete, manage permissions.
Read Only	Open in preview, pick slicers, drill down, print. No editing, no saving.
Read Only (No Print)	As Read Only, but the print function is blocked.
Edit Budget Entries	Open the editor locked down: only budget matrix amount cells and slicer picks can be edited. Budget edits write straight to the G/L budget entries; nothing else on the sheet can be changed and the document itself is never saved.

Who a row applies to

Each permission row targets one of:

User — a single user, picked from the user list.
Security Group — every member of a Business Central security group.
Everyone — all users (the name field stays blank).

When several rows could apply, resolution is: a personal User row wins outright; otherwise the most permissive matching Security Group row; otherwise the Everyone row. If nothing matches, the user has no access and the error names the sheet's owner(s).

Rules worth knowing

Save As to a fresh code is always allowed — the saver becomes the new sheet's owner. Overwriting an existing code requires owner access to that code, and you are asked to confirm before its contents are replaced.
The first permission row must make someone Owner. Adding a non-owner row to an unrestricted sheet automatically adds you as Owner first; adding yourself at a lower level as the first row is refused.
The last owner cannot be removed or downgraded while other assignments exist — assign another owner first. Removing the very last permission row entirely is allowed: the sheet becomes unrestricted until someone saves it or opens Permissions and becomes its owner. For shared access that survives saving, keep an Owner row and add an Everyone or Security Group row at the required access level.
SUPER users get no implicit content access — an administrator cannot silently read restricted sheets. SUPER sees every sheet in the list and may always delete one; when a sheet's owners no longer exist, SUPER may also edit its permission list to hand it to a new owner. That is the recovery path for a sheet whose owners have left.
Users with read-only access are routed to the preview automatically wherever they try to open the sheet.

The controller builds BUDGET-2027, a sheet with a budget matrix and a dashboard page, and wants three levels of access:

Type	User / Group	Access	Result
User	ANNA (controller)	Owner	Full control — created automatically on first save.
User	CFO	Owner	A second owner, so the sheet survives Anna's holiday.
Security Group	DEPT-MANAGERS	Edit Budget Entries	Managers open the editor locked down: they can type amounts into their budget cells and flip the department slicer — nothing else.
Everyone	(blank)	Read Only (No Print)	Everyone else can look at the preview but not print or change anything.

A manager who is also listed personally gets their personal row's level — a personal row always wins over group and Everyone rows. If Anna later wants the sheet private again, she deletes the Everyone row; if she deletes all rows, the sheet returns to unrestricted until its next save or permission setup claims it again.

Moving Sheets Between Environments

Export downloads the selected sheet as a file named after its code (BUDGET-2026.bcsheet). It is a zip archive holding a single sheet.json, so it stays small and can be opened with any zip tool for inspection. The file holds everything the document stores: cells with styles and write-back bindings, regions and their field lists, virtual-column values, conditional formats, scenarios, init code, column widths, row heights and the colour scheme. It does not hold the permission list — user and security-group names belong to the environment the sheet came from. Exporting needs the same right as saving the sheet, so a read-only or budget-entry user cannot take a sheet's definition with them.

Import asks for the file, then shows the save dialog prefilled with the code and description from the file so you can import under a different code. If a sheet with that code already exists you are asked to confirm; its content is replaced but its permission rows are kept, and replacing needs save rights on that sheet. A sheet imported under a new code starts unrestricted.

Things worth knowing:

Region filters, financial report names, budget names, table and field numbers travel as they are. A sheet built on customised tables or a company-specific financial report needs those to exist in the target as well.
Virtual-column values are keyed by the record's SystemId, which differs between environments. They import without error but only match records in the environment the sheet came from.
Import checks the file's format version, not the app's release number. A file with a newer, unsupported format is refused. A newer app can still produce a compatible file; fields the receiving app does not recognize are ignored, and fields missing from the file keep their defaults. Features unknown to the receiving app are not preserved.

Saving Semantics

Save on a sheet that already has a code overwrites it in place.
Save As prompts for code and description.
Preview and Scenarios need a saved sheet, so they save first (a brand-new sheet prompts for a code; cancelling skips the action).

Documents & Sharing