Why Put a Python Notebook Inside Excel?
Putting a Python notebook inside Excel is useful when the Python has become a program, not merely a calculation.
For a small transformation, an Excel formula or a Python-enabled worksheet cell can be the most direct solution. For a scheduled pipeline, a normal Python script outside Excel may be better. A notebook earns its place when the workbook needs several dependent stages, intermediate diagnostics, interactive controls, reusable functions, and an author-to-user handoff while Excel remains the durable input and review surface.
Boardflare uses marimo, a reactive Python notebook. marimo analyzes variable dependencies and reruns dependent cells when an upstream value changes; its notebooks are stored as Python source. In Boardflare, that notebook is connected to workbook inputs and can publish selected outputs or functions back to Excel.
The advantage is not “notebooks are better than spreadsheets.” The advantage is that a workbook application can have one coherent Python program behind the grid.
Start with the simplest shape that works
A notebook should not be the default answer to every spreadsheet calculation.
Consider four common program shapes.
| Program shape | Good fit | Where it starts to strain |
|---|---|---|
| Excel formulas | Visible, local calculations and familiar workbook logic | Complex state, algorithms, loops, repeated helper structures |
| Python in worksheet cells | Bounded analysis that naturally belongs at specific grid locations | Larger programs whose structure becomes tied to worksheet placement |
| External Python script | Automation, files, databases, scheduled jobs, unrestricted desktop/server packages | Interactive workbook operation and in-context review |
| Workbook-connected notebook | Multi-stage Python analysis that should remain connected to Excel inputs, outputs, controls, and users | Very small calculations or workloads requiring unrestricted desktop/server capabilities |
The point is to choose the shape that matches the job rather than maximize the amount of Python in the workbook.
One workbook problem, four possible implementations
Take the Sales Scenario Analysis. It starts with monthly units and prices and applies a worksheet discount assumption.
The calculation is intentionally simple:
base revenue = units × price
scenario revenue = base revenue × (1 - discount)For this exact model, ordinary Excel formulas are enough. The template says so explicitly. That makes it a useful way to see what the notebook contributes without pretending the arithmetic requires Python.
Excel formulas
A formula-first implementation is transparent and familiar. Each row can calculate base and scenario revenue, and totals can sum the results.
That is probably the right answer if the model is going to remain this simple.
Python in worksheet cells
A Python-cell implementation can read the sales range into a DataFrame and return a summary. This keeps the analysis close to the grid and is a natural fit for bounded analytical work.
The tradeoff appears as the program grows. If data cleaning, validation, model fitting, scenario logic, diagnostics, and charting are spread across many worksheet locations, the workbook grid starts to double as the source-code structure.
External Python script
A normal script could read an .xlsx file, calculate the scenario, write results, and exit.
That can be excellent for batch work. But it changes the operating model: Excel is now a file consumed by an external program rather than the live input/review surface. If a workbook user needs to change an assumption and immediately inspect the result in context, the script needs additional orchestration.
Reactive notebook
A workbook-connected notebook keeps the program separate from worksheet position while still using Excel as the durable business surface.
inputs = bf.inputs(
sales=bf.ref("A5:C9", headers=True),
discount="I6",
)
analysis = inputs["sales"].copy()
discount_rate = float(inputs["discount"])
# validate, calculate, visualize
bf.publish(outputs={"summary": summary})Change the workbook input and the dependent notebook computation updates. The author can add diagnostics, explanatory Markdown, controls, or charts without turning those elements into more worksheet calculation cells.
Reactivity changes how you organize the program
Traditional notebooks are often associated with manual execution order and hidden state. marimo uses a different model: it derives a dependency graph from variable references and executes dependent cells when upstream state changes. Its current documentation describes execution order as dependency-based rather than page-position-based.
That matters in a workbook because Excel itself is reactive. A user changes an input and expects dependent results to follow.
A Boardflare notebook can make that relationship explicit:
Excel demand table ─┐
Excel assumptions ──┼─> validation ─> model ─> diagnostics ─> published outputs
Notebook control ───┘ └────> chart / operator viewThe program can be organized by concepts—inputs, validation, transformations, model, diagnostics, publication—rather than by where a Python cell happens to sit in the workbook.
See Building Notebooks for the maintained explanation of Boardflare’s reactive notebook behavior.
Intermediate state can stay out of the worksheet
Substantial analytical programs create intermediate objects that are useful to the author but not to the workbook user.
A reconciliation model may create candidate pairs before deciding which matches to accept. A forecast may create error tables for several candidate models. An optimizer may create coefficient arrays, bounds, and solver diagnostics.
If every intermediate object is forced into Excel, the workbook accumulates helper sheets and ranges that are implementation details rather than business artifacts.
A notebook gives those objects a natural home. Publish only the tables or functions that the workbook needs.
That is one of the clearest reasons to use a notebook once the calculation becomes software-like.
Diagnostics can live beside the implementation
The operator may need only a final answer, but the author needs to know whether that answer is trustworthy.
For example, the Nonlinear Curve Fitting template reports fitted parameters, RMSE, R², AIC, parameter uncertainty, covariance conditioning, residual diagnostics, and predictions. Some results belong in Excel because users need them. Others are easier to inspect as notebook diagnostics during model development and review.
A notebook can keep those diagnostic views close to the code that creates them without requiring a permanent worksheet for every development check.
Interactive controls have a different role from workbook assumptions
marimo supports UI controls such as dropdowns and sliders. That does not mean every business input should become a widget.
A useful design rule is:
- Excel controls durable business state. Values such as budget, tolerance, model choice, forecast horizon, or approved policy thresholds should usually remain visible and saved in the workbook when they define the actual business case.
- Notebook widgets control exploration or presentation. Filtering an exception queue or choosing which diagnostic view to inspect can be appropriate when it does not redefine the durable workbook assumptions.
The Bank Reconciliation Exception Review demonstrates this split. Date tolerance, amount tolerance, and auto-match confidence are worksheet policy. A notebook dropdown filters the visible exception review between all, bank-only, and GL-only items without changing the durable reconciliation output.
That distinction becomes important when another person operates the workbook.
Source review is easier when the program is one artifact
A large workbook can contain calculations in formulas, names, Power Query, VBA, add-in functions, and hidden sheets. Sometimes that distribution is appropriate. Sometimes it makes technical review unnecessarily difficult.
A Boardflare notebook is stored as Python source. The author can inspect the program as one coherent artifact and can download the .py representation when source-oriented review or version-control workflows are useful.
This does not eliminate the need to review the workbook itself. The workbook still owns inputs, formulas, and published output locations. It does make the Python portion less dependent on worksheet geography.
App mode turns the same notebook toward the operator
During development, the author needs code, diagnostics, and the full notebook surface. During recurring operation, another user may need only instructions, controls, warnings, tables, and charts.
Boardflare’s App mode is an optional presentation of the same saved notebook for that second use case.
It is not a security boundary and does not remove the source from the workbook. Its value is simpler: the authoring artifact can also provide a focused operating surface.
That is a stronger reason for putting a notebook inside Excel than “it is a nicer code editor.” The notebook can carry the implementation, diagnostics, and operator presentation while the workbook remains the durable business artifact.
When not to use the notebook model
A notebook is the wrong abstraction when it adds structure the problem does not need.
Prefer ordinary Excel when the calculation is small, transparent, and naturally expressed in formulas.
Prefer an external Python process when the job requires scheduled execution, unrestricted filesystem access, desktop automation, raw sockets, long-running services, or native packages that do not fit a browser/WebAssembly runtime.
Prefer a worksheet-centered Python model when the analysis is bounded and the grid itself is the most natural location for the Python calculation.
Use a workbook-connected notebook when the Python has enough structure that program organization, reactivity, diagnostics, controls, publication, and handoff all matter at the same time.
The notebook is infrastructure for the application
The user is not buying a notebook for its own sake. The useful artifact is still the workbook and the job it enables.
The notebook is valuable when it gives that workbook a maintainable program behind it:
- Excel holds durable business inputs and outputs;
- Python holds substantial software-like logic;
- dependencies update coherently;
- intermediate diagnostics have a home;
- only intentional outputs cross back into the grid;
- the same source can support an authoring view and a focused operator view.
If you want to see the model with the smallest possible example, start with Sales Scenario Analysis. If you want to see why the structure matters in a more substantial workflow, compare it with the Demand & Inventory Planner or Bank Reconciliation Exception Review.