Skip to content
SumOfficeSumOfficeSumOffice
Menu
What SumOffice isProduct and deliveryAI and MCPContact us
Overview
SumSheet — what it isCapability map next to ExcelArchitecture: four layers and objectsWhat happens from open to saveStrengths and tradeoffs
Getting started
Installing SumSheetQuick start: your first project
Guides
How the API session worksRequests used in the exampleResponding to clicks and the context menuIntegrating into an applicationEmbedding kit: structure, events, menuSurface eventsDiagnosticsVerified script
Runtimes
The core in the browser through WebAssemblyA separate core process alongside your applicationSumSheet as a server-side processorPhone and tabletRuntime environments and the end-to-end scenario
Contract and boundaries
Readiness checklistFrom concept to pilotSumSheet version history
Examples
Live example: a budget spreadsheetSumSheet examplesMinimal sheetSheet with the ribbonEmbedding into a third-party pageA million rowsCrosshairRead-onlyCustom headersSheet without header stripsCustom menu itemCustom keyboard shortcutCustom languageDrop a workbook hereTwo people in one documentAssistants drive the sheetCustom eventHyperlinkFind and replaceNotesSheet outlinePage layoutAllow editing rangesWorkbook linksHeadless
Reference
SumSheet referenceSumSheet transport and message formatSumSheet session and conventionsWhat you can do with each formatSession and workbookCells and rangesSheetsPrinting and layoutFormulas and calculationFormattingData, filters, and objectsPivot tablesPower Query: M expressionsPower Query: connectorsPower Query: queries and stepsPower Query: tables from queriesPower Query: execution and progressPower Query: trust and privacyPower Query: external mashupsVBA and macrosProtection and reviewTypes: session, workbook, and sheetsTypes: cells and rangesTypes: formulas and calculationTypes: formattingTypes: data and sheet objectsTypes: pivot tablesTypes: charts and graphicsTypes: printing and page layoutTypes: Power QueryTypes: VBA and macrosTypes: protection and reviewTypes: general and utility

What happens from open to save

The workbook's full path through the layers, and the main point of the design: only a viewport goes outward, only filled cells sit in memory, and an edit either goes through whole or changes nothing.

The workbook’s path from file to saved file: seven steps, and at each one it’s clear who’s responsible for what happens — your application, the shell, or the core.

  1. Your application opens a session. It checks the user, picks the document, and passes the file, its identifier, the mode — view-only or editable — and the interface settings.

  2. The core opens the workbook. The adapter passes it the file’s content. The core parses the format, starts a workbook session at revision zero, and returns the first projection — what needs to be shown.

  3. The shell draws the visible part. It only gets the viewport that’s currently on screen, and information about it. A large workbook doesn’t have to turn entirely into page markup.

  4. The user performs an operation. Editing a cell, sorting, inserting a shape, changing the format. The shell passes the intent and the expected revision number through the operations contract.

  5. The core checks and applies it. It checks permissions, sheet protection, and whether the revision is stale. On success, the workbook and its history change together; on refusal, no half-operation is left behind.

  6. The shell and your application get the response and the event. The shell updates the screen, and the application can log it to audit or change a status. Which request and session the response ties to is visible from the identifiers in it.

  7. Saving returns the finished file. The core assembles the workbook back into a file. Your application takes its content, creates a version, and carries its own process through to the end — approval, signing, posting, whatever’s behind it on your side.

The key execution model

Section titled “The key execution model”

The workbook never turns entirely into a screen. Between the file and what the user sees is a chain, and every link passes on less data than it received:

part of the workbook → sparse storage → viewport → editor shell → your application

  • Part of the workbook. The core takes from the file the sheet and the range needed right now, not the whole workbook.
  • Sparse storage. Only filled cells are stored. A sheet with a million rows, of which two hundred are filled, takes up memory as two hundred cells.
  • Viewport. Only the rectangle currently on screen goes outward, and only the non-empty cells inside it.
  • Editor shell. Draws the rectangle it received and collects the user’s intent. It has no copy of the workbook of its own: it never computes formulas and never changes the file itself.
  • Your application. Gets events and operation outcomes — what changed, how the save turned out — not the workbook itself. It doesn’t need to know the internal structure of the XLSX file.

That gives you three consequences worth knowing in advance.

  • Workbook size isn’t capped by the browser. A large file opens because a viewport goes into the page, not the document.
  • An operation either goes through whole or changes nothing. Success adds one entry to the history; a refusal never leaves the workbook half-changed, and undo stays consistent.
  • Checking happens before the change. A stale revision, an invalid request, or a policy block gives an explicit refusal, not a silent corruption of the workbook.

Next

Section titled “Next”

Documentation assistant

Answers are assembled from the documentation and may be inaccurate — check the sources.