Microsoft Python in Excel vs. Boardflare Python for Excel

Excel
Python
Comparisons
Compare Microsoft Python in Excel and Boardflare Python for Excel on execution model, recalculation, security, packages, sharing, and which workflow fits each.
Published

August 20, 2026

Microsoft Python in Excel and Boardflare Python for Excel both let a workbook use Python without requiring a separate desktop Python installation. The important difference is not whether they “support Python.” It is where the Python program lives and what execution model surrounds it.

Microsoft makes Python part of Excel’s native calculation surface: you author Python in worksheet cells, reference workbook data with xl(), and Microsoft runs the code in a managed cloud container. Boardflare makes a reactive marimo notebook the Python program: the notebook declares workbook inputs, marimo tracks Python dependencies, and selected values or functions are published back to Excel.

That leads to a practical recommendation:

This comparison was researched and verified against current Microsoft documentation and the Boardflare implementation on August 20, 2026. Boardflare API, template, and network-boundary details were rechecked against the October 3, 2026 runtime on October 12, 2026; Microsoft-side statements were not rechecked in that pass. Both products can change, so deployment-sensitive details should be rechecked against the linked documentation.

The decision starts with the shape of the program

A feature checklist can make these products look more similar than they are. Both can use pandas, read worksheet ranges, run substantial calculations, and return results to Excel. But they organize the program differently.

Microsoft documents Python in Excel as Python formulas in worksheet cells. Its Get started guide explains that Python cells calculate in row-major order, including across worksheets according to worksheet order. When a dependent value changes, Python formulas are recalculated sequentially. Microsoft’s Python Code Editor gives those cells a larger editing surface and shows workbook Python by worksheet and cell.

Boardflare uses one marimo notebook as the primary Python artifact. marimo is explicitly reactive: dependent cells rerun when upstream values change, and its notebooks are stored as Python source. In Boardflare, bf.inputs() declares workbook dependencies and bf.publish() exposes selected results or functions back to Excel. The maintained technical comparison documents the exact integration and conversion behavior.

Conceptually, the difference looks like this:

Microsoft Python in Excel                 Boardflare Python for Excel

Workbook                                  Workbook
├── Setup!B2  Python                      ├── worksheet inputs
├── Model!C8  Python                      ├── BF.OUTPUT formulas
├── Model!F20 Python                      └── BF.FUNCTION formulas
└── Report!B4 Python                               │
                                                  ▼
Program structure partly follows         One reactive marimo notebook
worksheet and cell position.              ├── imports
                                          ├── workbook inputs
                                          ├── transformations
                                          ├── models / checks
                                          ├── controls / charts
                                          └── published outputs / functions

For a few analytical calculations, distributing Python through worksheet cells can be direct and intuitive. As the Python grows into something that looks more like a software program—with shared functions, multiple model stages, validation, controls, charts, and documentation—a notebook can provide a more coherent unit of code.

At a glance

Dimension Microsoft Python in Excel Boardflare Python for Excel
Primary Python surface PY worksheet cells, with workbook-wide Code Editor One reactive marimo notebook
Execution model Row-major Python-cell order; sequential recalculation Python dependency graph; affected descendants rerun
Runtime Microsoft-managed cloud container Browser/WebAssembly Python through Pyodide
Separate desktop Python install No No
Worksheet input model xl() ranges, names, tables, images, Power Query bf.inputs(...) with bf.ref() ranges and names, or bf.selection() for a named table’s active row
Python object in a worksheet cell Yes No generic Python-object cell
Reusable Python callable from ordinary Excel formulas PY itself cannot be composed with other Excel functions BF.FUNCTION("name", ...)
Complete Python source as .py No native whole-workbook .py export documented Notebook can be uploaded/downloaded as marimo .py source
Arbitrary Python network requests No No; external origins are blocked by the notebook child CSP
Package model Microsoft/Anaconda curated environment Browser/Pyodide-compatible Python environment
Interactive Python UI Worksheet-centric Notebook controls, charts, Markdown; optional App mode
Enterprise isolation model Microsoft 365 compliance boundary; no network/device/token access Add-in/browser capability boundary; arbitrary child network egress blocked
Recipient requirement Eligible Microsoft 365 Python-in-Excel environment Boardflare add-in/runtime

The table deliberately does not declare a universal winner. Several rows are tradeoffs rather than advantages.

Microsoft fits especially well when Python belongs in the grid

Microsoft’s design is a natural extension of the Excel calculation model. Select a cell, choose Insert Python, write a calculation, and return either a Python object or an Excel value. The PY function documentation describes xl() references to ranges, names, tables, images, and Power Query connections.

That has important advantages.

Python objects can remain worksheet objects

Microsoft can return a DataFrame or another supported value as a Python object in a cell rather than immediately flattening it into worksheet values. Microsoft’s DataFrame documentation shows DataFrames as object cards that can later be converted to Excel values.

That is useful when the worksheet itself is the analytical workspace and an intermediate Python object belongs at a particular coordinate.

Boardflare deliberately uses a different boundary. BF.OUTPUT() publishes Excel-compatible values; it does not emulate Microsoft’s generic Python-object cells. Rich intermediate Python state normally stays in the notebook.

Power Query is a first-class external-data bridge

Python in Excel has no arbitrary network access, but Microsoft provides a supported route for external data: bring it into the workbook with Power Query, then reference the query from Python. Microsoft calls Power Query the only way to import external data for Python in Excel, and notes that this import route is not available in Excel on the web.

If an organization already has governed Power Query connections and wants Python analysis layered over them, that integration can be more valuable than direct Python HTTP access.

Boardflare currently has no equivalent public notebook input contract for Power Query connections. Its bf.inputs() accepts workbook ranges, defined names, and the active row of a named table through bf.selection(); arbitrary notebook HTTP is blocked by the child network boundary.

The security boundary is deliberately restrictive

Microsoft’s data security documentation is unusually explicit. Python runs in a hypervisor-isolated Microsoft Cloud container within the organization’s Microsoft 365 compliance boundary. The Python process has no network access, no access to the user’s computer or devices, and no user token; Microsoft also says data is not persisted in the cloud Python environment.

Those restrictions can be a feature. If policy requires workbook Python to be incapable of directly sending data to arbitrary internet endpoints, Microsoft’s no-network model is a strong design property rather than a limitation to work around.

Boardflare fits especially well when the Python has become a program

Boardflare’s design center is different: keep Excel for workbook data, assumptions, review, and delivery, while giving substantial Python work its own programming surface.

Dependency-driven execution is independent of worksheet position

Microsoft states that Python cells calculate in row-major order and that the rule extends across worksheets. That means worksheet position is part of the Python program’s execution order. Microsoft also states that when a dependency changes, Python formulas recalculate sequentially. Manual and Partial calculation modes can suspend that behavior when the user’s license supports those modes. See Microsoft’s calculation guidance and availability/licensing page.

marimo instead builds a dependency graph from Python variable definitions and references. Change an upstream value and the affected downstream cells rerun. Moving a notebook cell visually does not redefine its dependencies merely because its screen position changed.

This does not prove that Boardflare is faster. Runtime performance depends on the calculation, data size, package implementation, transfer overhead, and compute environment. It does mean the models have different semantics as a program grows.

One implementation can become a reusable Excel function

Microsoft’s PY function is itself a worksheet calculation, and Microsoft states that PY cannot be used with other Excel functions. Boardflare can publish a Python callable once and let ordinary worksheet formulas invoke that implementation:

def discount(price, rate):
    return price * (1 - rate)

bf.publish(functions={"discount": discount})
=BF.FUNCTION("discount", A2, B2)

That pattern is useful when the workbook needs hundreds of ordinary Excel formulas to call one centrally maintained Python algorithm. The tradeoff is that BF.FUNCTION() depends on the Boardflare notebook runtime being available; it is not a standalone server-side UDF service. See Working with Excel for the exact contract.

The notebook can also be the interface

A marimo notebook can contain Markdown, controls, tables, charts, validation messages, and reactive outputs. Boardflare can reopen the saved notebook in App mode when the same analysis becomes a repeatable operator-facing tool.

That is materially different from simply having a larger code editor. The notebook can be both the implementation and an interactive analytical surface beside Excel. Boardflare’s notebook guide explains the reactive/UI model, while App mode and sharing documents an important caveat: App mode changes presentation; it is not a security boundary or source-protection mechanism.

The complete source can be treated as source

marimo stores notebooks as Python .py files. Boardflare saves the notebook source with the workbook and supports uploading/downloading the .py representation.

That matters if the Python itself needs code review, backup, diffing, or version-control workflows. Boardflare does not currently claim built-in Git synchronization; the advantage is that the program has a normal source representation that can participate in those workflows.

Microsoft’s Code Editor improves large-code authoring substantially, but Microsoft does not currently document a native workflow that exports all Python cells in a workbook as one complete .py program. For a workbook where code portability is a formal requirement, that difference should be tested early.

Same workbook problem, two different program shapes

The distinction is easier to see with a concrete example. Boardflare’s Sales Scenario Analysis ships one workbook, a Boardflare notebook, and the same expected results. The package does not include a Microsoft Python workbook; the Microsoft version below is the equivalent Python-cell form of the calculation.

The shared worksheet contains monthly units and prices. At a 10% discount, both implementations are validated against the same expected result:

Result Expected value
Total units 650
Base revenue $10,890
Scenario revenue $9,801
Revenue change -$1,089

The Microsoft workbook expresses the analysis as a Python cell that reads the worksheet range and returns the summary:

sales = xl("A5:C9", headers=True)
discount = 0.10
sales["Base revenue"] = sales["Units"] * sales["Price ($)"]
sales["Scenario revenue"] = sales["Base revenue"] * (1 - discount)

That is a good shape for a bounded calculation: source data in Excel, one Python analysis, result back in the grid.

The Boardflare version starts from the same worksheet range but keeps the model in a reactive notebook:

inputs = bf.inputs(
    sales=bf.ref("A5:C9", headers=True),
    discount="I6",
)
analysis = inputs["sales"].copy()
analysis["Base revenue"] = analysis["Units"] * analysis["Price ($)"]
# discount_rate is parsed and range-checked from inputs["discount"] (simplified; see notebook.py)
analysis["Scenario revenue"] = analysis["Base revenue"] * (1 - discount_rate)
bf.publish(outputs={"summary": summary})

The notebook reads the discount rate from the worksheet input cell I6 rather than a notebook control, validates it, and adds a chart. Change the sales range or the discount cell and the dependent notebook cells update; the compact summary can be published back to Excel with BF.OUTPUT("summary").

The useful conclusion is not that one implementation produces a better answer—they intentionally produce the same answer. It is that the same analytical problem can evolve into two different artifacts:

  • a worksheet-centered Python calculation; or
  • a workbook-connected reactive application whose Python is centralized in a notebook.

You can download the template workbook and notebook source from the template page, then compare them with the Microsoft Python-cell form above on the same data rather than relying on screenshots or vendor descriptions.

Runtime and packages: managed cloud vs. browser WebAssembly

Neither product uses your normal desktop Python installation.

Microsoft: curated Anaconda environment in the cloud

Microsoft provides a managed Python environment with core libraries including pandas, NumPy, Matplotlib, seaborn, and statsmodels, plus additional packages from its curated Anaconda distribution. The library documentation states that the recommended libraries cannot make network requests or access local files from the user’s machine; it does not state that restriction for the core libraries.

This gives Microsoft control over the environment and allows workbooks to remain associated with environment versions, which helps reproducibility. The tradeoff is that users cannot treat the runtime like an arbitrary local Conda environment.

Boardflare: Pyodide in the browser

Boardflare runs notebook Python through Pyodide/WebAssembly. Pyodide is CPython compiled for WebAssembly and includes or supports many scientific packages such as NumPy, pandas, SciPy, Matplotlib, and scikit-learn. The shipped runtime is pinned, and package compatibility is constrained by the browser/WebAssembly environment.

But “runs in the browser” does not mean “desktop Python with a different window.” Pyodide has WebAssembly/operating-system compatibility constraints, and Boardflare additionally keeps the notebook child network-isolated with connect-src 'self'. A package that works on a developer laptop may therefore still be unsuitable in the browser runtime.

For either product, the right evaluation is to test the actual package set your workbook needs, including transitive dependencies—not to infer compatibility from the package name alone.

Network access is an explicit capability boundary

Microsoft Python in Excel intentionally has no Python network access. External data should enter through workbook data or supported Power Query connections.

Boardflare also blocks arbitrary external-origin requests from notebook code: the child CSP permanently uses connect-src 'self'.

So the decision depends on the required integration path:

Requirement Better starting point
Python must be unable to call arbitrary external endpoints Either, after reviewing each product’s documented data paths
External data already comes through Power Query Microsoft Python in Excel
Python must call an arbitrary REST API, use raw sockets, SSH, or unrestricted networking External/managed Python

Boardflare’s Security and Data Flow documents the current child CSP and workbook/AI data paths.

Sharing and deployment deserve their own test

A workbook that works for its author can still fail as a deliverable.

Microsoft’s availability documentation ties Python in Excel to qualifying Microsoft 365 subscriptions and supported platforms/update channels. Qualifying subscriptions include standard compute and automatic recalculation; Microsoft’s separate add-on licensing FAQ says the add-on provides premium compute plus Manual and Partial calculation modes.

Boardflare requires the Python for Excel add-in and its runtime. A recipient does not need desktop Python, but does need access to the add-in/notebook assets and to every package the notebook imports being available in its browser runtime. Those requirements are spelled out in App mode and sharing.

For either option, test the second-user experience before standardizing on it:

  1. Send the workbook to someone who did not build it.
  2. Open it on the platforms your organization actually uses.
  3. Recalculate it from a cold start.
  4. Confirm licensing/add-in/policy requirements.
  5. Confirm package and external-data dependencies.
  6. Confirm what users see when the Python runtime is unavailable or slow to start.
  7. Save, close, reopen, and verify that the workbook reconstructs the expected state.

This is more informative than comparing a feature list because deployment failures usually occur at the boundaries: identity, policy, runtime startup, packages, external data, and recipient configuration.

Which should you use?

The following scenarios are more useful than declaring an overall winner.

Your workbook looks like this Start with Why
A few pandas/statistical calculations belong directly beside worksheet data Microsoft Native PY cells are direct and grid-centered
You want DataFrames or other supported Python objects to live in worksheet cells Microsoft Python object output is built into the model
External data already arrives through governed Power Query connections Microsoft xl() can reference Power Query connections directly
Policy requires no arbitrary notebook network access Either, after capability review Microsoft blocks Python networking; Boardflare blocks child external-origin networking and exposes only explicit managed capabilities
The Python has grown into a substantial multi-stage program Boardflare One notebook keeps functions, transformations, checks, controls, charts, and explanation together
Execution should follow Python dependencies rather than worksheet/tab order Boardflare marimo uses a reactive dependency graph
One Python algorithm should be callable from many ordinary Excel formulas Boardflare BF.FUNCTION() publishes a centralized callable
The notebook itself should contain interactive controls and an app-style presentation Boardflare Reactive notebook UI + optional App mode
The whole program needs a portable .py representation for review/diff/backup Boardflare The notebook is Python source
Python needs to call an arbitrary REST API directly External/managed Python Neither in-workbook Python runtime provides arbitrary direct notebook egress
The workflow walks local folders, automates desktop apps, runs scheduled jobs, or needs unsupported native packages External Python Neither in-Excel runtime is designed as unrestricted desktop/server Python

A good proof-of-concept should therefore start from your hardest architectural requirement, not your easiest pandas example. If Power Query integration, network isolation, reusable worksheet functions, or source-control review is mandatory, test that first.

The practical dividing line

Microsoft Python in Excel fits best when Excel remains the program’s primary organizing surface and Python adds analysis to the grid. It has deep native integration, a managed environment, Python object cells, Power Query references, and a deliberately restrictive enterprise execution boundary.

Boardflare fits best when Excel remains important, but the Python deserves its own coherent program. A reactive notebook provides dependency-based execution, interactive controls, centralized source, explicit workbook inputs/outputs, reusable worksheet functions, and a path to app-style presentation.

Neither replaces ordinary Excel formulas where formulas are already clear. Neither replaces external Python when the real job is file-system, desktop, server, or batch automation.

For a deeper field-by-field comparison—including source limits, exact type conversion, input/output limits, worksheet-error behavior, and security boundaries—use the maintained Boardflare vs. Microsoft Python in Excel technical comparison. To evaluate both approaches against the same calculations, start with the Python in Excel template library.

Primary sources used for this review

The Microsoft side of this article was checked against current first-party documentation on August 20, 2026:

The Boardflare side was checked against the current repository implementation and maintained documentation, especially Architecture and Runtime, Security and Data Flow, and Working with Excel. The underlying notebook/runtime behavior is also consistent with the official marimo documentation and Pyodide documentation.