Microsoft Python in Excel vs. Boardflare: Which Should You Use?
Excel
Python
Comparisons
A practical comparison of Microsoft Python in Excel and Boardflare Python for Excel, covering programming model, recalculation, security, packages, APIs, sharing, and the workflows each fits best.
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:
Start with Microsoft Python in Excel when the Python is bounded analysis that naturally belongs in the grid, when Python object cells or Power Query references matter, or when Microsoft’s managed no-network execution boundary is an organizational advantage.
Evaluate Boardflare when the Python has become a substantial multi-step program, when dependency-driven notebook execution and interactive controls matter, when you want the complete source as a .py file, or when ordinary Excel formulas need to call reusable Python functions.
Use external Python instead of either when the real requirement is unrestricted local files, desktop automation, scheduled jobs, database pipelines, or native packages that do not fit a managed-cloud or browser/WebAssembly runtime.
This comparison was researched and verified against current Microsoft documentation and the Boardflare implementation on August 20, 2026. 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
Microsoft 365 compliance boundary; no network/device/token access
Add-in/browser capability boundary; notebook code can make permitted browser requests
Recipient requirement
Eligible Microsoft 365 Python-in-Excel environment
Boardflare add-in/runtime and required package/API access
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 external-data import path for Python in Excel.
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. It can consume workbook ranges/tables and can make browser-compatible HTTP requests, but those are different integration models.
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:
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 two workbooks built from the same inputs and expected results: one using Microsoft Python in Excel and one using a Boardflare notebook.
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:
The notebook also owns an interactive discount slider and chart. Change a worksheet input or the slider 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 both workbooks from the template page and evaluate the difference with 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 also reiterates that those libraries cannot make network requests or access local files from the user’s machine.
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. Compatible pure-Python wheels and Pyodide-supported packages can be loaded in the browser.
But “runs in the browser” does not mean “desktop Python with a different window.” Pyodide documents WebAssembly and browser constraints, including limitations around sockets, operating-system modules, and browser networking policies. A package that works on a developer laptop may 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 a tradeoff, not a score
This is one of the clearest differences.
Microsoft Python in Excel intentionally has no network access. External data should enter through workbook data or supported Power Query connections. That reduces the ways Python code can communicate outside the managed environment.
Boardflare notebook code can make browser-compatible HTTP requests. That can be valuable for a REST API or another service designed for browser clients, but Pyodide networking remains subject to browser security rules, including CORS and authentication constraints. It is not unrestricted socket/network access.
So the decision depends on the requirement:
Requirement
Better starting point
Python must be unable to call arbitrary external endpoints
Microsoft Python in Excel
Python must call a CORS-compatible web API directly
Boardflare may fit better
Python must use raw sockets, desktop credentials, SSH, or unrestricted networking
External Python
Boardflare’s Security and Data Flow documents its workbook/browser capability boundary and the separate data path created when notebook authors call external services.
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 any package hosts or external APIs the authored notebook depends on. Those requirements are spelled out in App mode and sharing.
For either option, test the second-user experience before standardizing on it:
Send the workbook to someone who did not build it.
Open it on the platforms your organization actually uses.
Recalculate it from a cold start.
Confirm licensing/add-in/policy requirements.
Confirm package and external-data dependencies.
Confirm what users see when the Python runtime is unavailable or slow to start.
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 benefits from Python having no arbitrary network access
Microsoft
The cloud runtime deliberately removes network/device/token access
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 a browser-compatible REST API directly
Boardflare, after testing CORS/auth
Browser HTTP is available within normal browser constraints
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, a browser API, 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.