Python for Excel

A Python application environment for Excel: build reactive notebook logic around workbook data, publish results and functions back to Excel, and hand off a focused App presentation.

A Python application environment built into your Excel workbook.

Boardflare adds a reactive Python notebook to Excel so a technical workbook owner can build substantial logic in one inspectable program while keeping Excel for data, assumptions, review, and delivery. When the work becomes a repeatable tool, the same saved notebook can reopen in a focused App presentation for another workbook user.

Get it from Microsoft AppSource

Build once, hand off a simpler experience

Boardflare is most differentiated when a workbook has a technical owner and downstream users.

  1. The author works in Edit mode, connects workbook inputs, writes and tests Python, adds controls and charts, and publishes workbook-facing outputs or functions.
  2. The notebook source and preferred opening presentation are saved with the workbook.
  3. A workbook user can reopen the same notebook in App mode and operate the intended controls and outputs without the normal authoring surface.

App mode is optional and remains the same saved notebook. It is a presentation boundary, not a permissions, encryption, or source-protection boundary. See App mode and sharing before distributing executable workbooks.

Why a notebook?

One coherent Python workspace

Keep transformations, models, validation, Markdown, intermediate results, charts, diagnostics, and controls together instead of distributing substantial Python logic across worksheet coordinates.

The notebook is reactive: when an upstream value changes, marimo reruns dependent cells so code and outputs stay consistent.

Excel can consume the notebook

Read live workbook values through bf.inputs(), then expose selected notebook work back to Excel:

=BF.OUTPUT("summary")
=BF.FUNCTION("discount", A1, B1)

The complex implementation can remain centralized in Python while workbook users consume results and reusable functions where they need them.

The notebook can become the interface

A notebook can contain controls, tables, charts, explanations, and reactive outputs. When the same analysis becomes a repeatable tool, choose Open as: App to reopen it as a simplified app-style presentation of the same notebook.

Many exploratory notebooks never need App mode. It becomes important when the workbook is being handed to somebody who should operate rather than maintain the Python implementation.

The Python remains portable source

A marimo notebook is Python source. Boardflare saves that source with the workbook, while the underlying .py representation remains suitable for normal source-oriented practices such as review, diffing, backup, and version control when your workflow supports them.

NoteCurrent product boundary

Saving the notebook stores its source with the Excel workbook. This documentation does not imply built-in Git synchronization, repository management, source protection, or application permissions.

The product model

flowchart TD
    A[Excel workbook<br/>data • assumptions • schedules • review] --> B[Reactive Python notebook]
    B --> C[Notebook results<br/>tables • charts • diagnostics]
    B --> D[Excel cells<br/>BF.OUTPUT]
    B --> E[Excel functions<br/>BF.FUNCTION]
    B --> F[App mode<br/>focused presentation]
    B --> G[Python source]

The notebook and workbook are complementary surfaces. Returning results to Excel is useful when the workbook needs them; it is not a required final step for every notebook.

Current AI authoring boundary

Notebook AI can draft, revise, explain, debug, and complete normal source code using the context supplied to the authoring request. The generated Python remains visible and editable.

The current assistant does not independently read arbitrary workbook cells, inspect live Python objects, execute notebook cells, or verify a business result. Workbook-derived data can leave the local calculation path when the author explicitly includes that information in AI context. See AI authoring for the exact current behavior and review requirements.

Runtime and trust

Boardflare’s Python runtime executes in the browser by default. That does not mean every authored application is isolated from external services: notebook code can make browser-permitted network requests, load packages, and send data to APIs chosen by the author.

A notebook-enabled workbook therefore contains executable source. Before sharing one, review what worksheet data it reads, which outputs/functions it publishes, which packages it loads, which network services it contacts, and who maintains the logic when business rules change.

For the exact trust boundaries and data paths, read Security and Data Flow.

Learn by task

  • Getting started — use the bundled starter, connect live worksheet data, publish a result and function, save with the workbook, and safely upload/download Marimo .py source.
  • Working with Excel — read cells and ranges, return results with BF.OUTPUT(), create worksheet functions with BF.FUNCTION(), and check supported values and limits.
  • Boardflare vs. Microsoft Python in Excel — compare calculation order, source organization, type conversion, limits, runtime/security boundaries, packages, source export, and the scenarios where each approach fits better.
  • Building notebooks — understand marimo reactivity, structure larger analyses, use controls and charts, and work with packages in the browser runtime.
  • AI authoring — use the current text/code assistant while understanding its context and execution limits.
  • App mode and sharing — use Open as: App, understand the presentation boundary, and validate a workbook before distribution.
  • Templates — open the canonical published template catalog and see the application patterns currently available.
  • Excel ↔︎ Python type conversion — look up exact scalar, pandas, NumPy, date/time, missing-value, error, and spill behavior, and download the executable comparison harness.
  • Troubleshooting and reference — diagnose common failures and look up the exact public API contract.
  • Legacy Functions Editor — maintain workbooks that still use the earlier standalone function-authoring workflow.

Advanced implementation documentation

Most workbook authors do not need the transport internals. For engineering and security review:

  • Architecture and Runtime — shared-runtime startup, marimo/Pyodide ownership, capabilities, worksheet invocation, source lifecycle, persistence, and the legacy boundary.
  • Security and Data Flow — iframe trust boundaries, capability validation, executable-workbook risk, AI eligibility/context, external networking, packages, and persistence integrity.

What this is for

Boardflare is most compelling when the Python work is substantial enough to benefit from being understood as a coherent program while Excel still matters to the workflow. Common capability fits include:

  • cleaning and reshaping workbook data;
  • forecasting, regression, simulation, and statistical analysis;
  • optimization and constrained planning;
  • validation, reconciliation, controls, and exception analysis;
  • scientific and engineering analysis;
  • interactive analytical tools with controls and visualizations;
  • reusable calculations that should have one centralized Python implementation.

These are product capabilities, not a claim that every category already has a published template. See Templates for the current worked examples.

When another approach may be simpler

Use ordinary Excel formulas when they remain clear and maintainable. A small native Python-in-Excel calculation can also be a good fit when the Python naturally belongs to a worksheet cell. For a detailed technical comparison, see Boardflare vs. Microsoft Python in Excel.

Use external Python when the workflow centers on unrestricted file-system automation, scheduled jobs, desktop automation, databases, large batch processing, or packages that require capabilities unavailable in a browser runtime.

Need exact behavior or recovery help?

Use Troubleshooting and reference for API signatures and symptom-driven recovery. Use Architecture and Runtime or Security and Data Flow when you need the implementation model.