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

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.

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.

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

bf.publish(functions={"discount": discount})

=BF.FUNCTION("discount", A2, B2)

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:

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))
analysis = inputs["sales"].copy()
analysis["Base revenue"] = analysis["Units"] * analysis["Price ($)"]
analysis["Scenario revenue"] = analysis["Base revenue"] * (
    1 - float(discount.value) / 100
)
bf.publish(outputs={"summary": 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.

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:

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:

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.

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.

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:

• Introduction to Python in Excel — runtime and platform model.
• Get started with Python in Excel — xl(), calculation order, recalculation, outputs, and external-data boundary.
• PY function — static Python source, supported Excel references, return types, and formula-composition restriction.
• Python in Excel code editor — workbook-wide editing surface.
• Python in Excel DataFrames — Python object and Excel-value output modes.
• Data security and Python in Excel — cloud isolation, network/device/token restrictions, workbook access, and environment persistence behavior.
• Open-source libraries and Python in Excel — managed package environment.
• Use Power Query to import data for Python in Excel — external-data integration.
• Python in Excel availability and add-on licensing FAQ — eligibility, compute tiers, and calculation modes.

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.

What the linked discussions show

The source material supports a qualitative pattern rather than a precise adoption statistic:

The useful finding is behavioral: AI assistance and self-written code are no longer opposites. In many workflows, the user still owns the logic and testing while an assistant supplies a growing share of the syntax. The linked discussions are self-selected anecdotes, so this article does not turn them into percentages or market-share estimates.

flowchart LR
    A[Business requirement] --> B[AI-assisted draft]
    B --> C[Inspectable Python / VBA]
    C --> D[Test data]
    D --> E{Correct and reconciled?}
    E -->|No| F[Error / result back to assistant]
    F --> B
    E -->|Yes| G[Reusable deterministic tool]

External chat tools: describe, run, debug, repeat

The most detailed automation stories in the reviewed sample often follow a simple loop:

1. describe the process and representative inputs;
2. ask for Python or VBA;
3. copy the code into the real execution environment;
4. run it on test data;
5. return tracebacks or unexpected output to the assistant;
6. refine the code;
7. retain the final script as a normal software artifact.

That workflow is attractive because an external assistant can discuss Python, VBA, SQL, command-line behavior, PDFs, APIs, and file-system errors in one place. It is particularly useful when the automation extends beyond Excel.

One property-management controller described using ChatGPT and Python for invoice processing. The user reported adapting a base template to six vendors, identifying roughly ten more candidates, and uploading a 400-invoice monthly batch in roughly 3–4 minutes. That is an anecdotal, user-reported result rather than an independently measured benchmark, but it illustrates the pattern: a domain expert specifies the workflow, AI helps write the implementation, and the output becomes a repeatable script.

A separate staff-accountant discussion emphasized using AI to build deterministic tools rather than asking a model to inspect a workbook and provide an unverifiable conclusion. The accountant supplies the requirements and reviews the resulting automation; the assistant handles much of the technical writing.

Integrated Copilot: less copying, more workbook context

Integrated Excel assistants solve a different friction problem: context and execution can stay closer to the workbook.

Microsoft’s current Copilot documentation distinguishes direct Python-backed analysis from an advanced-analysis mode. Direct answers can expose the generated code, while advanced analysis opens a new sheet, runs Python, and lets the user modify or insert the underlying code as a refreshable Python cell. That makes the analytical path more inspectable than a prose-only answer while avoiding the copy-and-paste loop for bounded workbook analysis. Availability still depends on the relevant Microsoft 365 product, client, and licensing context.

Official references:

• Get direct answers to your data analysis questions
• Frequently asked questions about Copilot in Excel
• Introduction to Python in Excel

The tradeoff is that integrated analysis operates within the product’s supported workbook and runtime model. It is not a substitute for an external automation that must walk local folders, process arbitrary documents, run on a server schedule, or coordinate several desktop applications.

Deterministic tools versus model-generated conclusions

For consequential spreadsheet work, this is the most important architectural distinction.

Suppose an accountant needs to reconcile two systems. There are two very different requests:

Request A: “Look at these files and tell me whether the accounts reconcile.”

Request B: “Write a script that joins on these keys, applies these tolerance rules, produces an exceptions table, and proves that source totals reconcile to output totals.”

The second request creates something that can be:

• reviewed before use;
• tested against known cases;
• rerun next month;
• version controlled;
• reconciled independently;
• logged when inputs are malformed;
• handed to another maintainer.

An LLM can still make a business-logic mistake in the generated code. The advantage is not that generated software is automatically correct; it is that the logic becomes explicit and testable. That review requirement is visible in the Excel AI-tools discussion, where users describe plausible-but-wrong suggestions, security constraints, and the need to double-check outputs. The thread is anecdotal, but it is a useful counterweight to treating code generation itself as validation.

The domain expert still has to specify the rules

AI is weakest where the prompt silently assumes business knowledge that has never been made explicit.

A model cannot safely infer organization-specific rules such as:

• fiscal-calendar conventions;
• entity and account mappings;
• sign conventions;
• revenue-recognition treatment;
• which duplicates are legitimate;
• missing-data policy;
• outlier handling;
• forecast horizons;
• acceptable reconciliation tolerance;
• when a human approval is required.

The strongest practitioner stories are therefore not “AI replaced the accountant/analyst.” They are examples of a domain expert converting tacit knowledge into a specification and using AI to accelerate the implementation.

What minimum skill does the user still need?

A person does not need to become a full-time software engineer to benefit from AI-generated Python. They do need enough literacy to recognize dangerous or obviously incorrect behavior.

At minimum, recurring business automation owners should understand:

• data types and missing values;
• DataFrame filtering, joins, and grouping;
• functions, parameters, and return values;
• file paths and overwrite behavior;
• exceptions and tracebacks;
• the difference between test and production inputs;
• how to compare totals before and after a transformation;
• how dependencies and credentials are supplied.

This is also why a generated script should become maintained organizational code once it supports a recurring business process.

A review pattern for finance and accounting automation

For high-impact workflows, ask the assistant to produce controls along with the implementation.

A useful checklist is:

1. Define inputs and outputs. State schemas, required columns, units, signs, and allowable missing values.
2. Make assumptions explicit. Put mappings, thresholds, and dates in configuration rather than hiding them in prose.
3. Add assertions. Check row counts, uniqueness, ranges, and required totals.
4. Preserve source records. Never overwrite the only copy of an input file.
5. Log exceptions. Skipped or malformed records should be visible.
6. Reconcile. Compare source and output totals with documented tolerances.
7. Test known cases. Include both expected successes and expected failures.
8. Version the code. Record what changed and which version produced an output.

The AI can generate much of this scaffolding. The owner still decides whether the controls prove what the business process actually requires.

Where Boardflare’s notebook AI fits

Boardflare uses AI on the authoring side of a workbook-connected notebook.

The notebook assistant is instructed on the public workbook API and marimo’s reactive programming rules. Depending on the authoring action, supplied notebook context can be used to create cells, revise a selected region, explain code, or provide inline completion.

The assistant does not become the runtime for the notebook. It does not receive an unrestricted tool that can execute arbitrary notebook code or mutate live workbook state on its own. The durable artifact remains inspectable notebook source plus explicit workbook inputs and published outputs/functions.

That creates the same pattern seen in the strongest practitioner evidence:

Author intent
    ↓
AI-assisted implementation
    ↓
Inspectable reactive Python
    ↓
Validation and testing
    ↓
Saved workbook + notebook source
    ↓
Operator uses deterministic behavior

See AI authoring for the current product behavior and Designing notebooks for the notebook design guidance.

What to expect next

AI will continue reducing the amount of syntax a spreadsheet expert has to write manually. That does not remove the need for architecture, validation, or domain ownership. It makes those disciplines more important because more people can now produce code quickly.

The most useful question is therefore not “did a human or an AI write this Python?” It is:

Can another person inspect the logic, reproduce the result, detect bad inputs, and maintain the tool when the business rule changes?

That is the standard that turns AI-assisted code generation into dependable spreadsheet automation.

Methodology and limitations

This article is a qualitative synthesis of a purposive set of public practitioner discussions and official documentation. Representative sources include Python as a middleman between Excel and Claude, an invoice-processing case study, an accountant’s automation examples, how a staff accountant uses AI, and Excel users discussing AI tools at work. The sources support qualitative observations about development workflows; they do not establish tool adoption, market share, productivity gains, or error rates across the broader Excel population.

The recurring use cases

The linked discussions point to six recurring application families. They overlap: one workflow can clean data, run a forecast, create a chart, and publish a workbook at the end.

flowchart LR
    A["Cleaning / ETL"]
    B["Automation / reports"]
    C["Modeling / forecasting"]
    D["Visualization"]
    E["Validation / reconciliation"]
    F["Functions / integration"]
    A ~~~ B ~~~ C ~~~ D ~~~ E ~~~ F

The more useful conclusion is qualitative: Python is rarely valuable because someone wants “Python syntax in a spreadsheet.” It is valuable when a spreadsheet workflow has crossed into work that is easier to express as software.

1. Data cleaning and reshaping

The most common analytical use case in the linked discussions is pandas-style transformation of tabular data.

Practitioners repeatedly describe tasks such as:

• joining exports from different systems;
• converting wide data to long form and back;
• grouping and aggregating large tables;
• correcting data types and missing values;
• parsing irregular text;
• normalizing JSON-like data;
• deduplicating records;
• applying regular expressions;
• replacing long chains of helper columns.

This is not automatically an argument against Power Query. Power Query is often the better choice when the transformation is transparent, refreshable through standard connectors, and maintained by Excel-oriented users.

Python becomes attractive when the transformation is easier to understand as a short program, needs a library that Excel does not provide directly, or is already part of a larger Python analytical model.

2. Automation and recurring report production

Repeatable automation is another recurring task family, but this is also where the phrase “Python in Excel” becomes misleading.

Users describe workflows such as:

• reading hundreds of XLSX or CSV files;
• processing invoices and PDFs;
• creating one workbook or worksheet per business entity;
• renaming, moving, and archiving files;
• refreshing reports;
• combining data from APIs or databases;
• creating recurring month-end or management-report packages.

Those jobs generally require Python around Excel, not merely Python running inside a workbook.

A browser or managed workbook runtime is deliberately bounded. If the job needs unrestricted local folders, desktop applications, scheduled execution, email, or arbitrary system integration, external Python, VBA, or another automation service is usually a better architecture.

The workbook can still be the artifact stakeholders receive. Python simply does not need to live inside it.

A concrete accounting example shows the scale that can make this worthwhile. In a property-management controller’s case study, the author reported adapting a ChatGPT-assisted Python template to six invoice vendors, identifying roughly ten more candidates, and uploading a monthly batch of 400 invoices in roughly 3–4 minutes. The result is anecdotal and self-reported, not a benchmark, but it is representative of the recurring many files + deterministic rules + Excel output pattern in the source material.

3. Modeling, statistics, forecasting, and simulation

This is the category where Python inside an Excel-centered workflow is especially compelling.

Practitioners discuss:

• regression and nonlinear models;
• time-series forecasting;
• correlation and covariance analysis;
• Monte Carlo simulation;
• scenario analysis;
• risk modeling;
• demand and sales forecasts;
• optimization;
• specialized numerical methods.

The hybrid pattern is straightforward:

Excel assumptions and source data
              │
              ▼
        Python model
              │
      ┌───────┴────────┐
      ▼                ▼
interactive UI   worksheet outputs
      │                │
      └───────┬────────┘
              ▼
       stakeholder review

Excel remains useful for assumptions, review, reconciliation, and distribution. Python owns the part that benefits from explicit code, numerical libraries, or multidimensional data structures.

The Sales Scenario Analysis follows this pattern with workbook assumptions, reactive scenario controls, charts, and published worksheet results. The Demand & Inventory Planner shows the same notebook/workbook boundary for constrained replenishment decisions.

4. Visualization and dashboards

Python is also used for visualizations that are cumbersome to reproduce with normal Excel charts:

• heatmaps;
• probability distributions;
• correlation graphics;
• model diagnostics;
• specialized statistical plots;
• application-specific dashboard graphics.

The tradeoff is portability and editability. A Python-rendered chart can be analytically richer while still being less convenient for an Excel user who expects to restyle every element as a native Office chart.

The right question is not “which charting library is better?” It is whether the visualization is an analytical output of the model or a workbook artifact that users need to manipulate directly.

5. Validation, reconciliation, and controls

Accounting, finance, analytics, and operations discussions repeatedly show Python being used as a deterministic checking layer.

Typical work includes:

• reconciliations;
• duplicate and exception detection;
• control totals;
• cross-system comparisons;
• malformed-input checks;
• completeness tests;
• rule-based classifications.

This is an important contrast with open-ended AI analysis. For high-consequence work, a short deterministic script with explicit checks can be rerun, tested, reviewed, and reconciled. The user does not have to trust a model’s unsupported conclusion.

The published templates illustrate that pattern inside a workbook-connected notebook: worksheet data and controls feed deterministic logic, which publishes results and diagnostics back to the spreadsheet.

6. Custom functions and interactive workbook tools

A separate group of users wants Python to behave less like an analysis cell and more like a reusable calculation or interactive layer for Excel.

They want:

• reusable worksheet functions;
• buttons or application controls;
• workbook object access;
• interactive notebooks;
• repeatable workflows;
• a way to package code for other workbook users.

This is where the current Python-in-Excel products diverge most sharply. Microsoft’s native Python centers Python calculation in worksheet cells. Browser add-ins such as Boardflare and xlwings Lite add different models for custom functions, notebook experiences, workbook interaction, and simplified interactive presentations. Local Python integrations can go further into desktop automation and unrestricted package environments.

The correct comparison is therefore not simply “does it run Python?” It is what kind of artifact does it let you deliver?

The strongest patterns by job function

AI is changing who writes the code

A second theme in the practitioner evidence is that the person specifying the automation is increasingly able to create the code even when they are not a professional developer.

The common workflow is still surprisingly concrete:

1. explain the business process to ChatGPT, Claude, Copilot, or a coding agent;
2. ask for Python or VBA;
3. run the generated code against test data;
4. paste errors or unexpected output back into the assistant;
5. refine the script;
6. retain the resulting code as a deterministic tool.

External chat tools appear more often than integrated Copilot in the detailed end-to-end automation stories we reviewed, although the sample is far too small and self-selected to infer market share.

The more important distinction is AI-generated software versus AI-generated answers. In accounting and finance especially, users value the ability to inspect and rerun the resulting script.

That is also how Boardflare positions notebook AI: the assistant helps create or revise the notebook; the durable artifact is ordinary notebook source that can be reviewed and tested.

For the code-sourcing evidence, practitioner examples, and review implications, see How AI Is Changing Python Development in Excel.

Python inside Excel versus Python around Excel

A practical way to choose is to start with the operational boundary.

These categories can coexist in the same business process. A robust finance workflow might use SQL or external Python for ingestion, Boardflare for the interactive planning notebook, and ordinary Excel formulas for transparent reconciliations.

What not to conclude from this research

This review does not show that a particular percentage of Excel users clean data with Python, that Python is replacing Excel, or that one execution model is universally better.

The source set is self-selecting and intentionally biased toward people discussing technical workflows. Product capabilities also changed during the research window.

What the evidence does show is a recurring division of labor:

Python handles transformations, models, automation, and reusable logic; Excel remains valuable for assumptions, review, communication, and distribution.

That is a more useful starting point than asking whether Python should “replace” Excel.

Methodology

The review uses a purposive set of public practitioner discussions plus official product documentation. Representative sources include Python as a middleman between Excel and Claude, Python around Excel for real-world use cases, accounting automation examples, a discussion spanning optimization, time series, preprocessing, and plotting, and Microsoft’s Python in Excel documentation.

This is directional qualitative evidence, not representative adoption research. Engagement metrics, issue counts, and user-reported outcomes measure attention and experience rather than successful deployment.

For the current product landscape, continue with Python in Excel Alternatives in 2026.

Start with the execution model

Python + Excel
│
├── Microsoft-managed cloud runtime
│   └── Microsoft Python in Excel
│
├── Browser / WebAssembly add-in runtime
│   ├── Boardflare Python for Excel
│   ├── xlwings Lite
│   └── Anaconda Code (Pyodide / WebR)
│
└── Local / external Python
    ├── xlwings desktop/server patterns
    ├── PyXLL
    └── pandas/openpyxl/COM/scripts

The execution model affects far more than performance. It determines the security boundary, package environment, access to local files and web APIs, workbook integration model, deployment requirements, and how much of the runtime the organization must manage. Microsoft’s Excel add-in platform overview and Office shared-runtime documentation explain the add-in side of that comparison.

At-a-glance comparison

The table intentionally omits pricing and fine-grained licensing. Those change too quickly to freeze into an article without frequent maintenance.

Microsoft Python in Excel

Microsoft’s native Python feature uses the PY function and executes Python in a secure Microsoft Cloud runtime. Microsoft provides a managed set of libraries and integrates Python results directly into the Excel calculation surface.

Official documentation:

• Introduction to Python in Excel
• PY function
• Data security and Python in Excel
• Python in Excel availability
• Use Power Query to import data for Python in Excel

Boardflare Python for Excel

Boardflare uses a stock marimo reactive notebook running through Pyodide in the Office add-in browser environment. Workbook data enters through explicit bf.inputs() declarations. The notebook can publish values/tables through BF.OUTPUT() and short callable Python functions through BF.FUNCTION().

Notebook source and startup preference are saved with the Excel workbook. The notebook is the primary authoring surface; optional Open as: App can present the same notebook more simply when an analysis becomes a repeatable tool.

Current product documentation: Python for Excel. For the detailed two-way Microsoft comparison, see Boardflare vs. Microsoft Python in Excel.

xlwings Lite

xlwings Lite has evolved substantially. Its current documentation covers custom functions, automation scripts, browser/Pyodide execution, .nb.py notebooks, package installation, web API access, testing, multiple workbook-stored source files, and an App Mode that can expose scripts to end users without showing the editor. Its August 2026 changelog also documents pinned dependency resolution for reproducible workbooks and continued notebook improvements.

Official documentation:

• xlwings Lite
• Notebooks
• Custom Functions
• App Mode
• Dependencies
• Changelog

Anaconda Code

Anaconda Code runs Python or R locally within Excel’s add-in environment using Pyodide or WebR. Current Anaconda documentation describes code cells, configurable package/runtime versions, worksheet references, linked or isolated execution, and user-defined functions. Anaconda Toolbox for Excel is a generally available product, while the Anaconda Code feature is still labeled beta in the current documentation.

Official documentation:

• Anaconda Code
• Anaconda Toolbox for Excel

What about external or local Python?

The four products above are not substitutes for every Python/Excel workflow.

If the job needs:

• broad or unattended local folder traversal beyond an add-in’s supported host bridge;
• PDF/email processing;
• scheduled jobs;
• database pipelines;
• desktop application automation;
• unsupported native packages;
• large multi-workbook batch processing;

then an external Python environment may be the right answer. The workbook can remain the user-facing artifact without containing the whole runtime.

This distinction is visible in practitioner discussions: many successful “Python + Excel” automations use pandas, openpyxl, xlwings, COM, or scripts around Excel rather than Python executing in the workbook itself. The relevant external-runtime options have their own documentation: xlwings, openpyxl, and PyXLL.

How to choose

Ask these questions in order:

Bottom line

A useful shorthand is:

• Microsoft Python in Excel: Python analysis integrated directly into the Excel grid.
• Boardflare: a reactive Python notebook connected to workbook inputs, outputs, and functions, with optional App mode for a simplified interactive presentation.
• xlwings Lite: browser-based xlwings automation, scripts, notebooks, and custom functions.
• Anaconda Code: Python/R code and UDFs in an Anaconda-managed Excel add-in environment.
• External Python: the right answer when the workflow is really system automation or a data pipeline that happens to produce or consume Excel files.

The category will keep moving. The August 2026 xlwings changes alone show why feature checklists age quickly. That is why this article records a reviewed snapshot rather than pretending to be permanent product documentation.

The complete picture

A useful way to understand the system is to start with the full topology rather than with one API call:

flowchart TB
    subgraph Excel[Excel]
        WB[Workbook cells / ranges / names]
        XML[Workbook Custom XML\nsaved notebook source]
        CF[BF.OUTPUT / BF.FUNCTION]
        Shared[Long-lived Office shared runtime]
    end

    subgraph Boardflare[Boardflare parent host]
        UI[Task pane / Notebook surface]
        Session[Notebook session + capabilities]
        Bridge[Spreadsheet Bridge]
        Registry[Live publication registry]
    end

    subgraph Notebook[Separate-origin notebook iframe]
        Marimo[Stock marimo]
        Pyodide[Pyodide / browser CPython]
        Inputs[bf.inputs Anywidget]
        Publish[bf.publish Anywidget]
    end

    WB <--> Bridge
    XML <--> Session
    CF <--> Shared
    Shared --> UI --> Session
    Session <-->|validated MessagePorts| Marimo
    Marimo --> Pyodide
    Pyodide --> Inputs
    Pyodide --> Publish
    Inputs <-->|workbook input capability| Session
    Publish <-->|output/function capability| Session
    Session <--> Bridge
    Session <--> Registry
    Registry <--> CF

There are three ideas behind this shape:

1. Excel remains useful. We do not require every assumption, input, or deliverable to move into the notebook.
2. The notebook owns the Python program. Multi-step transformations, models, controls, charts, and explanations can live in one reactive source file instead of being distributed across worksheet cells.
3. The boundary is explicit. Notebook Python gets workbook capabilities through a small public API rather than receiving unrestricted access to the add-in parent.

For a workbook user, the consequence is simpler than the diagram: no separate desktop Python installation is required; declared worksheet inputs can drive reactive notebook recalculation; selected notebook results can flow back to worksheet formulas; and the saved artifact is notebook source in the workbook rather than a serialized Python process. AI authoring is optional and is not part of the calculation path.

Why marimo fits spreadsheet work

Spreadsheet users already expect dependency-driven recalculation. Change an input and downstream work should update.

marimo is a reactive Python notebook. Its documentation describes dependent cells rerunning when referenced values change and notebooks being stored as Python source rather than an opaque notebook database. That maps naturally to a workbook-connected model.

Boardflare adds workbook dependencies explicitly:

import boardflare as bf

inputs = bf.inputs(
    sales=bf.ref("Sales!A1:D20", headers=True),
    scenario="Assumptions!B2",
)
inputs

Downstream cells read inputs["sales"] and inputs["scenario"] like ordinary Python values. When Excel changes one of those references, Boardflare refreshes the input model and marimo reruns dependent cells through its normal reactive graph.

The spreadsheet and notebook therefore do not need competing recalculation systems.

Why run Python in the browser?

A workbook is much easier to distribute when every recipient does not need to recreate the author’s desktop Python installation.

Marimo’s WebAssembly runtime uses Pyodide to run CPython in the browser. That provides a substantial Python environment without a separate local Python installation.

It also creates a clear compatibility boundary. Browser Python is not desktop/server Python. Pyodide documents limitations around local files and subprocesses, raw sockets, and browser networking such as CORS. Some native dependencies and desktop integrations therefore do not fit this environment.

That is a tradeoff, not something we try to hide: the browser runtime makes workbook distribution easier, while external Python remains a better fit for workloads that require unrestricted operating-system capabilities.

Keeping marimo stock

A major design decision was to put product-specific behavior around marimo rather than inside a private fork.

Marimo owns:

• notebook editing;
• source serialization;
• reactive dependency analysis;
• Python execution;
• notebook UI primitives.

Boardflare owns:

• Excel/shared-runtime startup;
• workbook source persistence;
• workbook input/output capabilities;
• worksheet functions;
• product presentation and App mode;
• AI provider/account policy;
• the parent/notebook security boundary.

That separation gives us a cleaner upgrade path and makes failures easier to classify. If an Excel formula cannot see a published result, for example, the question is usually about the live publication capability or startup lifecycle—not about a hidden modification to marimo internals.

Anywidget is the notebook-side capability surface

The public boardflare package returns Anywidget models for the connections that need a live browser counterpart. Anywidget’s front-end specification explicitly separates one-time model initialization from per-view rendering, which is the lifecycle distinction Boardflare relies on here.

inputs = bf.inputs(
    assumptions=bf.ref("Assumptions!A1:B8", headers=True),
)
inputs

and:

publication = bf.publish(
    outputs={"summary": summary},
    functions={"discount": discount},
)
publication

The displayed widget is not decorative. Its model owns the capability connection. That is why Boardflare documentation tells authors to keep bf.inputs() and bf.publish() displayed as cell results.

This model/view distinction matters. A widget model can render more than one visual view without multiplying workbook subscriptions, and destroying a view does not have to mean destroying the underlying capability.

The notebook does not get unrestricted access to the parent

The marimo runtime executes in a different-origin iframe. The parent establishes separate source, input, and outputs capabilities only after validating the connection.

sequenceDiagram
    participant Child as Notebook / Anywidget
    participant Parent as Boardflare parent
    participant Port as Dedicated MessagePort

    Child->>Parent: Connect request
    Parent->>Parent: Validate child window + exact origin
    Parent->>Parent: Validate protocol + session + nonce
    Parent->>Parent: Validate capability + generation
    Parent-->>Child: Transfer MessagePort
    Child<<->>Port: Ongoing capability traffic
    Port<<->>Parent: Active capability only

The goal is not to claim that arbitrary Python is safe. Notebook source is executable code. The goal is to avoid making “whatever can call postMessage” equivalent to the workbook API.

The maintained Security and Data Flow page documents the current validation checks and trust boundaries in more detail.

One notebook model, multiple spreadsheet hosts

Notebook code should not care whether the spreadsheet underneath it is production Excel or the browser spreadsheet used for demos.

The shared @boardflare/spreadsheet-bridge package puts host-specific spreadsheet operations behind a common interface:

flowchart TD
    Notebook[Boardflare notebook integration] --> Bridge[Spreadsheet Bridge]
    Bridge --> ExcelDriver[Excel driver]
    Bridge --> UniverDriver[Univer driver]
    ExcelDriver --> Office[Office.js / Excel]
    UniverDriver --> Univer[Univer browser workbook]

The two hosts are deliberately not described as identical. Excel has workbook Custom XML persistence and a shared custom-function runtime. The public demo has a browser page/session lifecycle. The bridge lets the notebook model share useful concepts without erasing those host differences.

Publishing selected results back to Excel

A notebook does not have to end at a chart in the task pane. It can expose a deliberately small worksheet-facing API.

For values and tables:

=BF.OUTPUT("summary")

For short callable Python functions:

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

Both are backed by a live registry owned by a displayed bf.publish() model.

sequenceDiagram
    participant Publish as bf.publish
    participant Host as Boardflare host
    participant Excel

    Publish->>Host: Prepare values for workbook date system
    Host-->>Publish: Prepared
    Publish->>Host: Claim complete output/function registry
    Host-->>Publish: Registry acknowledged
    Excel->>Host: BF.OUTPUT subscription / BF.FUNCTION invocation
    Host-->>Excel: Live value or Python result

The claim is atomic: a replacement publication does not tear down the prior successful registry until the replacement has validated and claimed successfully.

The publication widget can also show which worksheet formulas are actively consuming outputs/functions. The same information is available to Python through publication.consumers.

Why Excel’s shared runtime matters

Excel custom functions and a task pane can be configured to use the same long-lived JavaScript runtime. Microsoft’s shared-runtime documentation describes that arrangement; Boardflare uses the model so a worksheet formula can need Python even when the user has not visibly opened the Notebook tab first.

sequenceDiagram
    participant Excel
    participant Formula as BF.OUTPUT / BF.FUNCTION
    participant Shared as Boardflare shared runtime
    participant Notebook as marimo / Pyodide

    Excel->>Formula: Recalculate workbook
    Formula->>Shared: Subscribe / invoke
    Shared->>Notebook: Mount saved notebook runtime
    Notebook->>Shared: Subscribe workbook inputs
    Shared-->>Notebook: Initial workbook snapshot
    Notebook->>Notebook: Reactive graph calculates
    Notebook->>Shared: Claim publication registry
    Shared-->>Formula: Published value / function result
    Formula-->>Excel: Resolve streaming formula

While that startup is still healthy but incomplete, Excel can keep a streaming function in its normal #BUSY! state rather than showing a fake placeholder result.

Authentication is not part of calculation startup

Another important separation is between the calculation runtime and Notebook AI eligibility.

Boardflare lets the notebook calculation runtime mount while Office authentication is still resolving. BF.OUTPUT() and BF.FUNCTION() therefore do not depend on a user opening sign-in UI.

Office identity is used separately to decide whether the Marimo AI authoring controls are enabled. At launch, Notebook AI is restricted to eligible work or school Microsoft identities; personal or unresolved identities receive the same notebook calculation runtime with AI disabled.

That separation prevents an optional authoring capability from becoming a hidden dependency of workbook calculation.

Persistence is source, not a frozen Python process

Boardflare does not try to serialize a live interpreter, DataFrames, widgets, subscriptions, or Python function objects into the workbook.

It saves the notebook source and its preferred Edit/App opening presentation. Reopening reconstructs the runtime:

flowchart TD
    Saved[Saved notebook source + opening mode]
    Runtime[Start marimo / Pyodide]
    Inputs[Hydrate bf.inputs]
    Graph[Run reactive graph]
    Publish[Claim bf.publish registry]
    Excel[Resolve worksheet consumers]

    Saved --> Runtime --> Inputs --> Graph --> Publish --> Excel

This source-first contract is easier to reason about and makes the durable artifact compatible with ordinary source practices such as review, diffing, backup, and version control when the author chooses to surface the .py file externally.

Uploading source is intentionally staged

The add-in can open an existing Marimo .py file, but choosing a file is not a persistence operation.

stateDiagram-v2
    [*] --> Saved: saved workbook source or bundled starter
    Saved --> Staged: upload .py
    Staged --> Saved: Marimo Save + verified workbook write
    Staged --> Saved: startup failure + Restore saved notebook

The replacement source starts in a fresh Edit session. The previous workbook copy remains durable until the author explicitly saves the replacement and Boardflare verifies the workbook write. That gives a broken upload a recovery path without silently destroying the last saved notebook.

Download follows the same source-first philosophy: it exports source that Marimo has already submitted to Boardflare. It cannot magically serialize editor changes that were never saved.

AI stays on the authoring side

AI is useful here because it can accelerate writing and revising normal Python. It is not a required component of the calculation runtime.

An AI action can send the user’s prompt plus selected/supplied notebook context through Boardflare’s configured AI path. The response is authoring output. The durable artifact is still ordinary source that can be inspected and tested before a workbook is distributed.

That is an important distinction for analytical software: the workbook does not need a model to improvise the core business calculation every time it opens.

The legacy function path stays separate

Boardflare still supports workbooks created with the earlier standalone Functions Editor. Those functions use workbook settings, Excel Name Manager LAMBDAs, and BOARDFLARE.EXEC.

They do not execute through the notebook registry:

flowchart LR
    NotebookFormula[BF.OUTPUT / BF.FUNCTION] --> NotebookRuntime[Live notebook registry]
    LegacyFormula[Legacy Name Manager function] --> Exec[BOARDFLARE.EXEC] --> LegacyWorker[Legacy runpy worker]

Keeping that boundary explicit matters for compatibility. Notebook startup or bundle changes should not accidentally become prerequisites for established BOARDFLARE.EXEC workbooks.

The design principle

The individual libraries and runtime versions will change. The more durable architecture is the separation of responsibilities:

Excel remains the workbook data, review, and delivery surface. The reactive notebook is the coherent home for substantial Python work. Boardflare supplies explicit runtime, persistence, and worksheet bridges between them.

For current implementation details, limits, and security controls, use Architecture and Runtime and Security and Data Flow rather than treating this dated launch article as a specification.

Do not migrate the workbook line by line

Start with a map of the existing system:

Inputs
  │
  ├── worksheet assumptions
  ├── imported tables
  ├── files / APIs / databases
  └── manual adjustments
  │
  ▼
Business logic
  │
  ├── formulas
  ├── Power Query
  ├── VBA
  └── external scripts
  │
  ▼
Outputs
  │
  ├── calculations
  ├── reports
  ├── charts
  ├── reconciliations
  └── files / emails / system updates

Then classify each responsibility by what environment is best at it.

What should usually stay in Excel

Keep logic in Excel when its transparency is a feature.

Good examples include:

• simple formulas that business users can audit directly;
• visible assumptions and overrides;
• reconciliations and control totals;
• presentation tables stakeholders modify frequently;
• normal PivotTables or charts when native Excel editing matters;
• Power Query steps that are already clear and reliably maintained by the owning team.

Moving a transparent SUMIFS or a straightforward Power Query import into Python just because Python is available usually creates more code without creating more value.

What is a good candidate for Python

Python becomes more attractive when the existing workbook contains software-like logic that is difficult to express or maintain in spreadsheet primitives. This is an architectural recommendation, not a claim that Python is inherently better:

• repeated helper-sheet transformations;
• simulation or optimization;
• statistical models;
• numerical algorithms;
• complex text processing;
• reusable domain calculations;
• duplicated business logic;
• logic that would benefit from unit tests;
• interactive application behavior that is currently held together by macros and manual steps.

The migration target should be a clearer boundary, not “more Python.” Runtime constraints should be checked before any rewrite. Microsoft’s native option runs Python in a managed cloud container with workbook and Power Query inputs, while browser runtimes such as Pyodide have their own WebAssembly and browser-environment limitations. Those are different boundaries, but both are reasons to keep file- and system-heavy work outside an in-workbook runtime when the workflow depends on unrestricted operating-system access.

Worked example: migrate the model, keep the workbook contract

Consider a revenue-planning workbook that has evolved into a chain of copied formulas and helper sheets. Users still like entering assumptions in Excel and reviewing the final forecast there, but the model now includes scenario adjustments, uncertainty, simulation, and a reusable projection calculation.

The least useful migration would translate every helper-cell formula into one long Python script. A better migration changes the boundary.

flowchart LR
    A[Drivers sheet] --> B[Copied formulas]
    B --> C[Helper sheets]
    C --> D[Scenario macros]
    D --> E[Forecast sheet]
    E --> F[Management review]

flowchart LR
    A[Drivers sheet] --> B[bf.inputs]
    B --> C[Reactive Python model]
    C --> D[Scenario controls + validation]
    D --> E[bf.publish]
    E --> F[BF.OUTPUT forecast]
    E --> G[BF.FUNCTION project_arr]
    F --> H[Management review]
    G --> H

import boardflare as bf

inputs = bf.inputs(
    assumptions=bf.ref("Drivers!A4:B12", headers=True),
    historical=bf.ref("Drivers!A15:B27", headers=True),
)
inputs

def project_arr(months: int, growth_rate: float = 0.08):
    # Domain calculation omitted here; this function is independently testable.
    ...

publication = bf.publish(
    outputs={"kpis": kpis, "forecast": forecast},
    functions={"project_arr": project_arr},
)
publication

=BF.OUTPUT("forecast")
=BF.FUNCTION("project_arr", 12, C6)

What should remain external

Some work should not be pulled into the workbook runtime at all. Microsoft’s Python in Excel security documentation explicitly describes the native runtime’s restricted access to the user’s computer, network, and workbook features, so these boundaries should be checked before choosing an in-workbook design.

Keep external Python, services, or other automation for tasks such as:

• traversing local folders;
• processing hundreds of independent files;
• scheduled jobs;
• PDF/email/document ingestion;
• database pipelines;
• unrestricted API integrations;
• desktop automation;
• native packages that do not fit the workbook runtime.

A strong architecture can use external Python for ingestion and still use Excel as the interactive decision and review layer.

Migrating VBA

VBA is not one thing. A macro can contain calculation logic, workbook manipulation, event handlers, formatting, file-system work, Outlook automation, and UI code in the same procedure.

Classify it before translating it.

A line-by-line VBA-to-Python translation often preserves the worst part of the original design: hidden mutable state and procedural dependencies.

Instead, try to replace the macro with explicit inputs, a testable calculation, and explicit outputs.

Migrating formula-heavy models

Long formulas and helper sheets are good migration candidates only when they have become difficult to reason about.

Look for:

• the same formula logic copied across many places;
• nested formulas implementing a real domain algorithm;
• large helper-sheet chains used only as intermediate state;
• calculations that need simulation, optimization, or statistics;
• formulas that cannot be tested independently of the workbook.

Then migrate incrementally:

1. freeze a representative test workbook;
2. document the current inputs and outputs;
3. calculate the same result in Python;
4. reconcile both implementations over multiple scenarios;
5. move only the proven section;
6. retain visible control totals in Excel.

The result should be easier to understand than the original model, not merely shorter on the worksheet.

Migrating a Jupyter notebook

A migration does not need to turn every notebook into an application. First decide which responsibilities belong in Excel and which substantial logic belongs in the Python notebook. A reactive notebook such as marimo changes the execution model compared with a conventional Jupyter workflow, but it does not change the architectural question.

That boundary matters more than the notebook technology.

A migration should answer:

• Which values should remain workbook inputs or notebook controls?
• Which workbook ranges should be explicit notebook inputs?
• Which code cells are really reusable model functions?
• Which outputs belong in the notebook UI?
• Which results must return to worksheet formulas?
• How should invalid inputs be shown?
• What happens when a package or external service is unavailable?
• If someone else will use it, do they need the full Edit surface or a simpler App presentation?

With Boardflare, the target pattern is:

Workbook inputs
      │
      ▼
bf.inputs(...)
      │
      ▼
Reactive marimo model
      │
      ├── validation
      ├── calculations
      ├── controls
      └── visualizations
      │
      ▼
bf.publish(...)
      │
      ├── BF.OUTPUT(...)
      └── BF.FUNCTION(...)

The important migration is therefore spreadsheet logic → clear Excel/notebook responsibilities, not Jupyter syntax → marimo syntax. If the finished notebook later becomes a repeatable tool, Open as: App can provide a simplified presentation of that same source.

Migrating external Python into Excel

The right answer may be to move only part of the application.

For example:

External Python / SQL
        │
        ├── ingestion
        ├── file processing
        ├── scheduled jobs
        └── governed preparation
        │
        ▼
Excel workbook
        │
        ├── assumptions
        ├── review
        └── stakeholder interface
        │
        ▼
Interactive Python layer
        │
        ├── scenarios
        ├── model logic
        └── application UI

This keeps system automation in the environment designed for it while moving the interactive decision layer closer to users.

A practical migration sequence

When not to migrate

Do not move a workflow to Python because:

• Python is fashionable;
• AI can generate the code;
• a simple formula looks less impressive than a script;
• the current Power Query workflow is boring but reliable;
• the owning team cannot support the resulting runtime.

A successful migration reduces complexity at the system level.

Where Boardflare fits

Boardflare is designed for the slice of this problem where Excel should remain part of the workflow but substantial Python logic benefits from a coherent reactive notebook.

It is not intended to replace external Python for arbitrary system automation, and it should not replace transparent spreadsheet logic that is already the clearest solution.

See the Python for Excel documentation for the current product contract and the Python in Excel template library for runnable workbooks, interactive demos, and worked notebook patterns.

Category snapshot

The headline pattern is clear within this snapshot: broad Excel agents dominate the list, while finance and data/document-preparation tools are also strongly represented. The categories are my classification of the catalog rows, not Microsoft marketplace categories. Extraction-first tools are grouped with data preparation, Arborchat is treated as a finance/market-intelligence tool despite using custom functions, and Sunhat is treated as a sustainability/ESG specialist rather than a generic writing tool.

The source is the Microsoft AppSource Excel catalog, checked on May 16, 2026, plus the publisher documentation linked in the tables below. AppSource is dynamic; the individual listing links are the evidence for the product descriptions, while the counts are a dated manual classification of the catalog included in this article.

How to read the market

Key add-ins to know

The following add-ins are not presented as a definitive ranking. They are the most prominent or representative options from the supplied list, with emphasis on items that appear early in the store-ordered source table or clearly represent a major category. Category placement reflects the follow-up verification of key listings, so a few tools are filed by their primary end-user workflow rather than by their source-table type label.

Practical buying guide for end users

Suggested end-user shortlist by need

Appendix: complete add-in catalog from the supplied table

The appendices include every add-in row present in the supplied table, organized into end-user categories. The store-order rank preserves the original ordering from the source table. The “Listed type” column preserves the original type label from the source table, even when the end-user category has been adjusted after verification.

Editorial note for publication

This article is intended as an orientation guide, not a procurement recommendation. The category adjustments in this version reflect a public-listing check of the key add-ins, but the add-in market changes quickly, and individual listings may change pricing, capabilities, supported platforms, or data-handling terms. End users should validate current marketplace listings, privacy policies, admin requirements, and enterprise licensing before adoption.

Why people use it

Tool Builder is a good fit when:

• the data already lives in a workbook
• people repeat the same review or update process every week
• the raw sheet is harder to use than the underlying task
• you want something faster than a custom internal app project
• you want the finished tool to travel with the workbook

That last part is important. The guide documents that Tool Builder stores the app and its table-backed data in the workbook itself, so the file carries the interface with it. You are not deploying a separate server or database just to make a spreadsheet easier to work with; normal Excel add-in sign-in and workbook-sharing requirements still apply.

The workflow is simple

Tool Builder works best as a short loop:

1. Start with a workbook problem.
2. Click Copy Guide in Tool Builder.
3. Paste the guide into a fresh chat with ChatGPT, Claude, Copilot, or another AI assistant.
4. Ask for a single-file HTML and JavaScript app for your workflow.
5. Paste the generated code into Tool Builder and run it in Excel.
6. Test it against real rows, then refine the prompt or the code.

If you want to see the pattern before writing your own prompt, Tool Builder also lets you load an example tool first.

What makes a good first app

The best Tool Builder apps are small and specific. They feel more like focused work surfaces than general-purpose dashboards.

Strong starting points include:

• an expense or budget tracker
• a project tracker or Kanban-style board
• a guided data-entry form
• an inventory or reorder screen
• a review queue that surfaces exceptions first
• a KPI dashboard built from workbook tables

Some apps work on top of tables you already have. Others create their own workbook tables the first time they run. Both models are supported, which is why Tool Builder can work for both tracking workflows and reporting views.

If you want inspiration, the Tool Builder for Excel guide shows the product workflow, and the visualization catalog is a useful place to borrow dashboard and chart ideas.

Background of Regular Expressions

Regular expressions (often abbreviated as regex or regexp) represent a highly specialized and powerful language for defining complex search patterns within text data. They are indispensable tools across various domains for tasks such as data validation, parsing semi-structured information, cleaning messy text, and extracting specific data points. Their ability to identify, match, and manipulate text based on intricate, predefined patterns significantly enhances efficiency and precision in data processing workflows. From validating email addresses and phone numbers to parsing log files or extracting specific keywords from documents, regex provides a flexible and robust mechanism for text manipulation.

For many years, users of Microsoft Excel, a ubiquitous tool for data management, faced significant limitations in performing advanced text manipulation directly within their spreadsheets. Achieving regex-like capabilities often required cumbersome combinations of basic text functions like LEN, FIND, REPLACE, SUBSTITUTE, LEFT, RIGHT, and MID. For more complex scenarios, users typically had to resort to writing Visual Basic for Applications (VBA) macros, which necessitated enabling specific references like “Microsoft VBScript Regular Expressions 5.5,” or acquiring third-party add-ins. This presented a considerable barrier for many users seeking to perform sophisticated text processing directly within their familiar spreadsheet environment.

However, a pivotal shift has recently occurred with the introduction of three brand-new native regex functions in Excel: REGEXTEST, REGEXREPLACE, and REGEXEXTRACT. These functions fundamentally change the landscape by bringing powerful pattern matching directly into the Excel formula bar. This enhancement represents a strategic move by Microsoft to significantly bolster Excel’s core data processing capabilities. It is not merely an incremental update but a fundamental re-tooling that empowers Excel to handle complex text patterns natively, reducing the reliance on external workarounds and positioning Excel as a more self-sufficient data manipulation platform. The anticipation of future integration into XLOOKUP and XMATCH further underscores this deeper embedding of regex power into Excel’s lookup and matching functionalities.

In stark contrast to Excel’s recent adoption, Python’s re module has long been a cornerstone of text processing in the programming world. As a built-in library, it has provided a comprehensive and highly flexible interface for regular expressions for years. It is widely utilized in diverse applications such as data validation, web scraping, log analysis, and complex string manipulations, making Python a go-to language for advanced text processing and automation.

This report aims to provide a granular comparison between Excel’s new native regex functions and Python’s established re module. By dissecting their respective capabilities, underlying regex engines, supported syntax, and advanced features, this analysis will highlight key distinctions and areas of overlap. The objective is to empower advanced data professionals and developers to make informed decisions on which tool is best suited for specific text manipulation tasks, considering factors like complexity, scalability, and integration into existing workflows.

Excel’s New Native Regex Functions: Capabilities and Syntax

Excel’s recent foray into native regular expression support is encapsulated in three distinct functions: REGEXTEST, REGEXEXTRACT, and REGEXREPLACE. These functions are designed to simplify and enhance complex text operations directly within Excel worksheets, offering a flexible and versatile alternative to combining numerous traditional text functions or resorting to VBA code. Their introduction eliminates the need for external add-ins for many advanced text manipulation scenarios, streamlining workflows for Excel users.

Python’s re Module: Comprehensive Regex Powerhouse

Python’s re module stands as a cornerstone for text processing in the programming world, offering a comprehensive and highly flexible interface for working with regular expressions. As a built-in library, it is an essential tool for tasks ranging from data validation and web scraping to complex string manipulations and parsing large text files.

Direct Comparison: Feature Parity and Key Distinctions

While both Excel’s new native functions and Python’s re module provide powerful regex capabilities, their underlying design philosophies, exposed features, and optimal use cases present significant distinctions.

Practical Applications and Recommendations

Understanding the distinct capabilities and design philosophies of Excel’s new regex functions and Python’s re module is crucial for selecting the most appropriate tool for a given task. Neither tool is universally superior; rather, their strengths are complementary, aligning with different operational contexts and user profiles.

Excel’s new native regex functions are particularly well-suited for scenarios that prioritize interactivity, immediate results, and operations within the familiar spreadsheet environment:

• Ad-hoc Data Cleaning and Validation: For quick, one-off tasks like removing unwanted characters (e.g., =REGEXREPLACE(B5,"[^0-9]","") to clean phone numbers), reformatting strings, or checking for the presence of specific patterns (e.g., =REGEXTEST(A1,"[0-9]")) within a single column or a small range of data.
• Interactive Data Extraction: When there’s a need to pull out specific pieces of information (e.g., numbers, names, email parts) from semi-structured text directly in a cell, REGEXEXTRACT provides an immediate and visible solution. This is highly beneficial for data exploration.
• Collaborative Data Analysis: When working with colleagues who are comfortable with Excel but not programming, the formula-based approach allows for transparent, auditable text processing that can be easily reviewed and modified by non-programmers.
• Small-scale Transformations: For datasets that fit comfortably within Excel’s row limitations and where the complexity doesn’t exceed what can be reasonably managed in formula form.

Conversely, Python’s re module is the superior choice for scenarios requiring programmatic control, advanced features, or operations that exceed Excel’s practical limitations:

• Large-scale Data Processing: When working with massive datasets (millions of records), multiple files, or text files that exceed Excel’s capacity. Python can process entire directories of log files, web scraping results, or database exports efficiently using loops and batch operations.
• Complex Pattern Requirements: For advanced regex features not exposed in Excel’s function interface, such as named capturing groups ((?P<name>...)), lookbehind assertions of variable width, atomic grouping, or fine-grained control over matching behavior through multiple flags (re.DOTALL, re.VERBOSE, re.MULTILINE).
• Automated and Scheduled Tasks: When text processing needs to be part of automated pipelines, ETL processes, or scheduled scripts. Python excels at unattended operations, error handling, and integration with other systems (databases, APIs, file systems).
• Multi-step Text Processing Workflows: For complex text analysis requiring multiple regex operations, conditional logic, or integration with other Python libraries (pandas for data manipulation, requests for web scraping, json for API responses). Excel’s formula-based approach becomes unwieldy for multi-step transformations.
• Performance-critical Applications: When processing speed is crucial, Python’s re.compile() optimization for repeated pattern usage, combined with the ability to implement efficient algorithms and data structures, often outperforms Excel’s calculation engine for intensive regex operations.
• Integration with Machine Learning and NLP: When regex is part of a larger text preprocessing pipeline for natural language processing, sentiment analysis, or machine learning models. Python’s ecosystem (NLTK, spaCy, scikit-learn) seamlessly integrates with regex operations.
• Log File Analysis and System Monitoring: For parsing server logs, application logs, or system outputs where patterns may span multiple lines, require precise timing analysis, or need to be aggregated across thousands of files. Python’s file handling and string processing capabilities far exceed what’s practical in Excel.
• Web Scraping and API Data Processing: When extracting structured data from HTML, XML, JSON responses, or other semi-structured formats where regex is combined with HTTP requests, DOM parsing, or API authentication. Python’s requests library and regex integration provide a powerful combination.
• Cross-platform and Deployment Scenarios: When the text processing solution needs to run on servers, cloud environments, or non-Windows systems where Excel may not be available. Python scripts are highly portable and can be deployed virtually anywhere.
• Version Control and Collaboration on Logic: When the regex patterns and processing logic need to be version-controlled, peer-reviewed, or maintained as part of a larger codebase. Python scripts integrate naturally with Git workflows and software development practices.

The decision between Excel and Python should ultimately be driven by the scope, complexity, and operational context of the task. Excel excels in interactive, exploratory scenarios with moderate complexity, while Python dominates in automated, large-scale, and feature-rich applications.

References

1. Regular Expressions in Excel | Exceljet, accessed July 24, 2025, https://exceljet.net/articles/regular-expressions-in-excel
2. Excel RegEx examples: using regular expressions in formulas - Ablebits.com, accessed July 24, 2025, https://www.ablebits.com/office-addins-blog/excel-regex-formulas/
3. Excel(ent) Obfuscation: Regex Gone Rogue - Deep Instinct, accessed July 24, 2025, https://www.deepinstinct.com/blog/excellent-obfuscation-regex-gone-rogue
4. Mastering the Power of Regular Expressions with Python’s ‘re’ Module: A Comprehensive Guide with Examples | by Khaleel ur Rehman | Medium, accessed July 24, 2025, https://medium.com/@khaleel92/mastering-the-power-of-regular-expressions-with-pythons-re-module-a-comprehensive-guide-with-141b855ac403
5. Python Regular Expression (RegEX) - Simplilearn.com, accessed July 24, 2025, https://www.simplilearn.com/tutorials/python-tutorial/python-regular-expressions
6. Introducing the new REGEX function set in Excel, accessed July 24, 2025, https://globalexcelsummit.com/post/introducing-the-new-regex-function-set-in-excel
7. How to use Regular Expressions (Regex) in Microsoft Excel both in-cell and loops, accessed July 24, 2025, https://stackoverflow.com/questions/22542834/how-to-use-regular-expressions-regex-in-microsoft-excel-both-in-cell-and-loops
8. Excel gets Regular Expression functions - Office Watch, accessed July 24, 2025, https://office-watch.com/2025/huge-news-excel-gets-regular-expression-functions/
9. Regular Expression HOWTO — Python 3.13.5 documentation, accessed July 24, 2025, https://docs.python.org/3/howto/regex.html
10. REGEXTEST Function - Microsoft Support, accessed July 24, 2025, https://support.microsoft.com/en-us/office/regextest-function-7d38200b-5e5c-4196-b4e6-9bff73afbd31
11. REGEXEXTRACT Function - Microsoft Support, accessed July 24, 2025, https://support.microsoft.com/en-us/office/regexextract-function-4b96c140-9205-4b6e-9fbe-6aa9e783ff57
12. REGEXREPLACE Function - Microsoft Support, accessed July 24, 2025, https://support.microsoft.com/en-us/office/regexreplace-function-9c030bb2-5e47-4efc-bad5-4582d7100897
13. PCRE2 - Perl-Compatible Regular Expressions - GitHub Pages, accessed July 24, 2025, https://pcre2project.github.io/pcre2/
14. Perl Compatible Regular Expressions - Wikipedia, accessed July 24, 2025, https://en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions
15. 7.2. re — Regular expression operations — Jython v2.5.2 …, accessed July 24, 2025, https://www.jython.org/jython-old-sites/docs/library/re.html
16. Lookahead and Lookbehind Tutorial—Tips &Tricks - RexEgg, accessed July 24, 2025, https://www.rexegg.com/regex-lookarounds.php
17. Regex Tutorial - Lookahead and Lookbehind Zero-Length Assertions, accessed July 24, 2025, https://www.regular-expressions.info/lookaround.html
18. Text.Regex.Pcre2 - Hackage, accessed July 24, 2025, https://hackage.haskell.org/package/pcre2/docs/Text-Regex-Pcre2.html

Why Use Python Statistical Functions in Excel?

While Excel offers a range of built-in statistical functions, they are often limited in scope. Many distributions are missing, and even for supported distributions, Excel typically only provides basic PDF, CDF, or quantile calculations. In contrast, our Python functions offer:

• Full distribution support (PDF, CDF, inverse CDF, survival, inverse survival)
• Comprehensive statistics (mean, median, variance, standard deviation)
• Flexible parameterization (location and scale for all distributions)
• Access to distributions not available in Excel

Comparison Table: Python vs. Native Excel Functions

Legend: - PDF: Probability Density Function - CDF: Cumulative Distribution Function - Quantile: Inverse CDF - Survival: Survival Function (1 - CDF) - Stats: Mean, Median, Variance, Standard Deviation

Example: Using Python Functions in Excel

Suppose you want to compute the inverse CDF (quantile) for the Weibull distribution, which is not available in native Excel. With the new Python function, you can simply use:

=WEIBULL_MIN(0.95, 1.5, 0, 1, "icdf")

Similarly, for distributions not available in Excel at all (like Pareto or Cauchy), you can now perform advanced statistical analysis directly in your spreadsheet.

Getting Started

To use these functions, add them from the list of Example Functions in our Python for Excel add-in. Then, simply call the functions as you would any Excel formula.

You can see the full list of available functions in our Python Functions Repository.

Excel Statistical Functions

Why Use Python Functions in Excel?

While Excel is a powerful tool for calculations and data analysis, it has limitations when it comes to advanced analytics, automation, and integration. Python functions allow you to: - Perform advanced statistical analysis, optimization, and modeling using industry-standard libraries. - Connect to APIs, web data, and external sources with just a formula. - Analyze unstructured data, such as text, with natural language processing tools. - Build custom solutions that scale beyond what is possible with built-in Excel features.

Request a Function

If there is a function you’d like to see, please Contact us.

Core AI Capabilities in Spreadsheets

Modern AI spreadsheet functions bring several core capabilities directly to your data:

1. Natural Language Understanding & Generation: Interacting with your data using plain English, generating text, answering questions, and summarizing content (AI_ASK).
2. Data Extraction & Structuring: Pulling specific pieces of information from unstructured text and organizing it into tables (AI_EXTRACT, AI_TABLE).
3. Data Cleaning & Formatting: Standardizing inconsistent data formats (dates, addresses, names) automatically (AI_FORMAT).
4. Pattern Recognition & Completion: Identifying complex patterns in data and filling in missing values or extending series based on examples (AI_FILL).
5. Classification & Categorization: Assigning labels or categories to data based on criteria or examples (e.g., sentiment analysis, topic modeling) (AI_CHOICE).
6. List Generation: Create lists based on prompts or existing data (AI_LIST).

Available AI Text Functions

The following functions leverage AI to work with text data:

Let’s delve into practical applications of these capabilities.

Application Examples

Combining AI Functions for Complex Workflows

The true power emerges when combining these functions. Imagine analyzing product feedback:

1. Paste Raw Feedback: Place raw customer feedback text into Column A.
2. Extract Product Name (AI_EXTRACT): In Column B, use =AI_EXTRACT(A2, "the product name mentioned").
3. Analyze Sentiment (AI_CHOICE): In Column C, use =AI_CHOICE(A2, "Positive, Negative, Neutral").
4. Extract Key Topics (AI_LIST): In Column D, use =AI_LIST(A2, "List key topics or features mentioned").
5. Summarize Feedback (AI_ASK): In Column E, use =AI_ASK("Summarize the feedback in one sentence:", A2).

This creates a structured dashboard from unstructured text, ready for pivoting, filtering, and further analysis – all within the spreadsheet.

Tips for Effective Use

• Be Specific with Prompts: The clearer your instruction (for AI_ASK, AI_FORMAT, AI_EXTRACT, etc.), the better the result. Instead of “fix this”, try “Format as YYYY-MM-DD date”.
• Provide Good Examples: For functions like AI_FILL or AI_CHOICE (when used with examples), ensure your examples accurately represent the desired output and cover different scenarios.
• Start Small: Test AI functions on a subset of your data first to understand their behavior and refine your prompts.
• Review Results: AI is powerful but not infallible. Always review the generated results for accuracy, especially for critical data.
• Understand Limitations: Be aware of potential biases in the AI models and any usage limits or costs associated with the functions.
• Consult Documentation: For detailed usage, parameters, and more examples, see the linked documentation for each function in the table above.

Conclusion

Integrating AI into spreadsheets transforms them from passive calculators into active partners in data analysis and workflow automation. By leveraging natural language processing, pattern recognition, and data structuring capabilities, users can:

• Quickly extract insights from unstructured text.
• Automate tedious data cleaning and formatting tasks.
• Generate creative content and ideas efficiently.
• Build more sophisticated and automated workflows.

As AI technology continues to evolve, its applications within the familiar spreadsheet environment will only grow, further empowering users to unlock the value hidden within their data. This shift marks a significant evolution, making advanced data manipulation and insight generation accessible to a much broader audience.

Key Features

def hello(first, last):
    """ Returns a greeting. """
    greeting = f"Hello {first, last}!"
    return greeting
    
# Test cases for the function
test_cases = [["Nancy", "Morgan"], ["Ming", "Lee"]]

# Excel usage: =HELLO("Nancy", "Morgan")

How It Works

Creating a Python-powered LAMBDA function is now a two-step process:

1. Write your Python function in the editor
2. Click Save to create the LAMBDA

The Python code is stored in workbook settings and a corresponding LAMBDA function is automatically created in Excel’s name manager. For example, this Python function:

def inches_to_mm(inches):
    """ Converts inches to millimeters. """
    return inches * 25.4

Creates this LAMBDA in Excel:

=LAMBDA(inches, BOARDFLARE.EXEC("workbook-settings:inches_to_mm", inches))

Jupyter Notebook Integration

A particularly exciting feature is the ability to import functions from Jupyter notebooks. You can: - Import from our example notebooks - Load notebooks from GitHub Gists - Use the notebooks as templates for your own functions

This makes it easy to maintain a library of functions in notebooks and import them into Excel as needed.

Try It Out

To get started with the new code editor:

1. Install the Python for Excel add-in
2. Open the task pane and go to the Editor tab
3. Try writing a simple function or import one of our examples
4. Click Save to create your LAMBDA function

The code editor is available now in version 1.1.0 of the add-in. For more details, check out our updated documentation.

What’s Next?

We’re continuing to improve the editor experience. Coming soon: - Support for optional arguments - More example notebooks - Enhanced type conversion options

Let us know what features you’d like to see next!

NLTK Library

The Natural Language Toolkit (NLTK) is a powerful library for natural language processing. It provides various tools and algorithms for text processing, including tokenization, stemming, lemmatization, and distance metrics. We will focus on using NLTK to calculate similarity scores between strings for fuzzy matching.

An example of calculating the similarity of two strings using edit_distance is shown below:

from nltk.metrics.distance import edit_distance

string1 = "apple"
string2 = "apples"
distance = edit_distance(string1, string2)
print(distance)

In this example, the edit_distance function calculates the minimum number of single-character edits required to change one string into the other. The output will be 1, indicating that the strings ‘apple’ and ‘apples’ have an edit distance of 1.

NLTK supports various distance metrics for calculating similarity between strings, including:

• Jaccard Distance: Measures the similarity between two sets by comparing the intersection and union of the sets.
• Levenshtein Distance: Calculates the minimum number of single-character edits required to change one word into the other.
• Jaro Similarity: Measures the similarity between two strings by considering the number of matching characters and transpositions.

Python Function

We’ve created the nltk_distance function to handle the typical use-case in Excel of finding a match for a lookup_value in a lookup_array, similar to how the XMATCH function works. It normalizes the edit_distance results to a similarity score of 0-1 for easier comparison. The function is as follows:

import nltk
import pandas as pd
from nltk.metrics.distance import edit_distance, jaccard_distance, jaro_similarity
from nltk.util import ngrams

def nltk_distance(lookup_value, lookup_array_df, algorithm):
    """
    Calculate the similarity between a lookup_value and a lookup_array using various distance algorithms.

    Parameters:
    lookup_value (str or pd.DataFrame): The string or DataFrame to search for.
    lookup_array_df (pd.DataFrame): The DataFrame to search within.
    algorithm (str): The algorithm to use for calculating similarity. Options are 'levenshtein', 'jaccard', and 'jaro'. Default is 'jaccard'.

    Returns:
    list: A list of lists where each sublist contains the index (1-based) and the similarity score of the most similar item in the lookup_array.
    """
    # Define a dictionary to map algorithm names to functions
    algo_funcs = {
        'levenshtein': lambda x, y: 1 - edit_distance(x, y) / max(len(x), len(y)),
        'jaccard': lambda x, y: 1 - jaccard_distance(set(ngrams(x, 2)), set(ngrams(y, 2))),
        'jaro': jaro_similarity
    }
    
    # Get the algorithm function from the dictionary
    algo_func = algo_funcs.get(algorithm)
    if algo_func is None:
        raise ValueError(f"Unsupported algorithm: {algorithm}")
    
    # Flatten the DataFrame to a list
    lookup_array = lookup_array_df.values.flatten().tolist()
    
    # Check if lookup_value is a DataFrame
    if isinstance(lookup_value, pd.DataFrame):
        lookup_value_list = lookup_value.values.flatten().tolist()
    else:
        lookup_value_list = [lookup_value]
    
    results = [] 
    for lookup_value_item in lookup_value_list:
        # Calculate similarity scores and round to 2 decimal places
        scores = [(index + 1, round(algo_func(lookup_value_item, item), 2)) for index, item in enumerate(lookup_array)]
        
        # Sort based on scores in descending order
        scores.sort(key=lambda x: x[1], reverse=True)
        # Append the top index and score to results as a list
        results.append(list(scores[0]))

    # results is 2D list, e.g. [[1, 0.75], [2, 0.85]]
    return results

nltk_distance(arg1, arg2, arg3)

The nltk_distance function takes three arguments:

• lookup_value: The string or DataFrame to search for, e.g. “apple” or pd.DataFrame(["apple", "banana"]).
• lookup_array_df: The DataFrame to search within, e.g. pd.DataFrame(["apples", "bananas", "cherries"]).
• algorithm: The algorithm to use for calculating similarity. Options are 'levenshtein', 'jaccard', and 'jaro'.

The function returns a list of lists, where each sublist contains the index (1-based), similar to XMATCH, and the similarity score of the most similar item in the lookup_array. For example, [[1, 0.75], [2, 0.85]] indicates that the most similar item to the first lookup_value has an index of 1 and a similarity score of 0.75, and the most similar item to the second lookup_value has an index of 2 and a similarity score of 0.85. This matches the array output expected by Excel.

Use in Excel

=PY(
arg1 = xl("A6:A10") # lookup_value
arg2 = xl("B6:B27") # lookup_array_df
arg3 = xl("C6") # algorithm

def nltk_distance(lookup_value, lookup_array_df, algorithm):
# ... function code omitted for brevity ...
    return results

nltk_distance(arg1, arg2, arg3)
)

=BOARDFLARE.RUNPY(A1, A6:A10, B6:B27, C6)

=BOARDFLARE.RUNPY("text/fuzzy-match/nltk_distance.ipynb", A6:A10, B6:B27, C6)

=LAMBDA(lookup_value, lookup_array, [similarity_threshold], [algorithm],
    LET(
        threshold, IF(ISOMITTED(similarity_threshold), 0.7, similarity_threshold),
        algo, IF(ISOMITTED(algorithm), "jaccard", algorithm),
        result, BOARDFLARE.RUNPY("text/fuzzy-match/nltk_distance.ipynb", lookup_value, lookup_array, algo),
        index, INDEX(result, 1),
        score, INDEX(result, 2),
        IF(score >= threshold, index, "No match")
    )
)

Conclusion

Fuzzy matching is a powerful tool for handling approximate string matching in various applications. The nltk_distance Python function provides a flexible and easy-to-use interface for performing fuzzy matching using different algorithms. It can be run efficiently in Excel using either the Excel PY() or BOARDFLARE.RUNPY functions, enabling users to leverage the power of Python within their Excel workbooks.

Background

Azure Sentiment Analysis is a cloud-based service, part of Azure AI Language, that uses machine learning to analyze text for sentiment and opinions. It returns an array containing the sentiment analysis results with sentiment polarity at the document, sentence, and aspect levels. It also provides the opinions used at the aspect level. This is often referred to as aspect-based sentiment analysis.

For example, given the text “I love the food, but the service was terrible”, instead of just getting a single sentiment score, which in this case isn’t that useful, we can extract the sentiment for each aspect, such as food = positive and service = negative.

The table below is a contrived example where the aspects have purposely been made to relate to either a food or service type aspect. These aspects were not extracted by the Azure Sentiment Analysis service, but are used here to illustrate the concept of aspect-based sentiment analysis.

Notice how the words used to describe food and service related aspects are varied, so trying to group them by keyword isn’t practical as the following different words are used for food: pizza, pasta, cuisine, menu items, appetizers, ingredients, dishes, food quality, menu selection, entrees.

To properly summarize the results we need to group the aspects together using semantic similarity, typically into clusters of related words. This is beyond the scope of this article.

Python Function

To access the Azure Sentiment Analysis service from Excel, we’re going to create a Python function that calls the Azure API and returns the sentiment analysis results. We’ll use the azure-ai-textanalytics Python library which provides a simple interface to the Azure Text Analytics service. In our function we’ll pass in the array of text to analyze, the Azure key, and the Azure endpoint. We want the results in a tabular format, so we need to flatten the structure so that each row contains the sentiment analysis results for a single aspect, and thus there are multiple rows per review.

from azure.ai.textanalytics import TextAnalyticsClient
from azure.core.credentials import AzureKeyCredential

def azure_sentiment(documents, language_key, language_endpoint):
    # Check if documents is a string, list, or DataFrame
    if isinstance(documents, str):
        documents = [documents]
    elif isinstance(documents, pd.DataFrame):
        documents = documents.values.flatten().tolist()  # Convert df to list

    # Authenticate the client using your key and endpoint 
    ta_credential = AzureKeyCredential(language_key)
    client = TextAnalyticsClient(
            endpoint=language_endpoint, 
            credential=ta_credential)

    result = client.analyze_sentiment(documents, show_opinion_mining=True)
    doc_result = [doc for doc in result if not doc.is_error]

    data = []

    for idx, document in enumerate(doc_result):
        for sentence in document.sentences:
            for mined_opinion in sentence.mined_opinions:
                target = mined_opinion.target
                for assessment in mined_opinion.assessments:
                    data.append([
                        idx + 1,  # 1-based index
                        document.sentiment,
                        document.confidence_scores.positive,
                        document.confidence_scores.neutral,
                        document.confidence_scores.negative,
                        sentence.text,
                        sentence.sentiment,
                        sentence.confidence_scores.positive,
                        sentence.confidence_scores.neutral,
                        sentence.confidence_scores.negative,
                        target.text,
                        target.sentiment,
                        target.confidence_scores.positive,
                        target.confidence_scores.negative,
                        assessment.text,
                        assessment.sentiment,
                        assessment.confidence_scores.positive,
                        assessment.confidence_scores.negative
                    ])
    return data

azure_sentiment(arg1, arg2, arg3)

Output

The figure below illustrates an example of the results returned by the Azure Sentiment Analysis service for a single document that contains two sentences as follows: The food and service were unacceptable. The concierge was nice, however...

flowchart TD
    Doc["Document: 'The **food** and **service** were **unacceptable**. The **concierge** was **nice**, however.'<br>Sentiment: mixed<br>pos:0.3 neu:0.17 neg:0.52"]
    
    Doc --> S1[Sentence: 'The **food** and **service** were **unacceptable**.'<br>Sentiment: negative<br>pos:0.0 neu:0.0 neg:1.0]
    Doc --> S2[Sentence: 'The **concierge** was **nice**, however.'<br>Sentiment: positive<br>pos:0.61 neu:0.35 neg:0.05]
    
    S1 --> A1[Aspect: **food**<br>Sentiment: negative<br>pos:0.01 neg:0.99]
    S1 --> A2[Aspect: **service**<br>Sentiment: negative<br>pos:0.01 neg:0.99]
    S2 --> A3[Aspect: **concierge**<br>Sentiment: positive<br>pos:1.0 neg:0.0]
    
    A1 --> O1[Opinion: **unacceptable**<br>Sentiment: negative<br>pos:0.01 neg:0.99]
    A2 --> O2[Opinion: **unacceptable**<br>Sentiment: negative<br>pos:0.01 neg:0.99]
    A3 --> O3[Opinion: **nice**<br>Sentiment: positive<br>pos:1.0 neg:0.0]

The results are then flattened or denormalized into a tabular format where each row contains the sentiment analysis results for a single aspect and duplicates the parent sentence and document. The columns in the output include the document index, document sentiment, document confidence scores, sentence text, sentence sentiment, sentence confidence scores, aspect text, aspect sentiment, aspect confidence scores, opinion text, opinion sentiment, and opinion confidence scores.

Excel Integration

To run this function from Excel we need to use the BOARDFLARE.RUNPY function which is available in the Boardflare Python for Excel add-in. This function allows you to run Python code from Excel and return the results in a tabular format. The BOARDFLARE.RUNPY function takes a path to the Python code as the first argument, followed by the arguments to pass to the Python function.

=BOARDFLARE.RUNPY("text/sentiment-analysis/azure_sentiment.ipynb", A1:A10, "your-azure-key", "your-azure-endpoint")

Results

As shown in the workbook, running the table of reviews earlier through the Azure Sentiment Analysis generates the following high-level sentiment analysis results:

Most of the columns in the output were omitted for brevity.

Conclusion

In this article we have shown how to use the Azure Sentiment Analysis service from Excel to analyze sentiment and opinions in text. We have also shown how to flatten the results into a tabular format so that they can be easily analyzed in Excel. This is a powerful tool for analyzing sentiment in text data, and can be used in a variety of applications such as customer support, market research, finance, etc. We have left the task of summarizing the results into clusters of related aspects as an exercise for the reader.

🆕 BOARDFLARE.RUNPY function

To achieve compatibility with Python in Excel, we’ve introduced a new BOARDFLARE.RUNPY function that handles both scalar and array inputs and outputs, and therefore replaces the original BOARDFLARE.PY and BOARDFLARE.PY.ARRfunctions which are now deprecated. We chose the name RUNPY to reduce potential confusion with Excel’s PY feature and we are not that creative with names.

Like Python in Excel, BOARDFLARE.RUNPY now converts Excel arrays into pandas DataFrames. It also returns the value of the last expression in the Python code, instead of using pyout as the output variable. This approach not only aligns with Python in Excel, but also with Jupyter notebooks.

The net result is that the same function code will work in both, with the only difference being how data is passed as arguments as shown in the following examples:

```python {5} # Using BOARDFLARE.RUNPY def add(a, b): return a + b

add(arg1,arg2)

Assuming the code above is in cell `C2`, the arguments `arg1` and `arg2` are passed to the `BOARDFLARE.RUNPY` function as follows:

```excel
=BOARDFLARE.RUNPY(C2, A2, B2)

With Python in Excel, the same code would be written as follows:

```python {5} # Using Excel’s PY def add(a, b): return a + b

add(xl(“A2”),xl(“B2”))

Here the `xl` function is used to reference the Excel cells `A2` and `B2` inside the Python code.  The upside of Microsoft's approach is everything is all in one cell, so is easier to make changes when developing code interactively.  The downside is that it is not a function, and therefore can't be used in Excel formulas or LAMBDA functions the way `BOARDFLARE.RUNPY` can.

## Functions collection

We're just getting started on building out a collection of ready-to-use Python [functions](https://functions.boardflare.com/) that can also be used as a starting point for building more complex functions.

For example, we've built a [text_distance](https://functions.boardflare.com/) function for fuzzy matching that is similar to that used in our [Fuzzy Match](/apps/excel/fuzzy-match/) app, but supports many more algorithms and can be readily modified to your specific needs.  Here's the code:

```python
import textdistance
import pandas as pd

def text_distance(needle, haystack_df, algorithm='jaccard'):
    # Get the algorithm function from textdistance
    algo_func = getattr(textdistance, algorithm)
    # Flatten the DataFrame to a list
    haystack = haystack_df.values.flatten().tolist()

    # Check if needle is a DataFrame
    if isinstance(needle, pd.DataFrame):
        needle_list = needle.values.flatten().tolist()
    else:
        needle_list = [needle]

    results = []
    for needle_item in needle_list:
        # Calculate similarity scores with normalization and round to 2 decimal places
        # Adjust index to be 1-based
        scores = [(index + 1, round(algo_func.normalized_similarity(needle_item, item), 2)) for index, item in enumerate(haystack)]
        # Sort based on scores in descending order
        scores.sort(key=lambda x: x[1], reverse=True)
        # Append the top index and score to results as a list
        results.append(list(scores[0]))

    # results is 2D list, e.g. [[1, 0.75], [2, 0.85]]
    return results

text_distance(arg1, arg2, arg3)

LAMBDA functions using Python

One of the great features of BOARDFLARE.RUNPY is that it can be used to build LAMBDA functions that can be used in Excel formulas. For example, the text_distance function can be used to build a FUZZYMATCH.TD function that is similar to Excel’s XMATCH function, but with the added ability to set a similarity threshold. Here’s the code:

=LAMBDA(lookup_value, lookup_array, [similarity_threshold], [algorithm],
    LET(
        threshold, IF(ISOMITTED(similarity_threshold), 0.7, similarity_threshold),
        algo, IF(ISOMITTED(algorithm), "jaccard", algorithm),
        result, BOARDFLARE.RUNPY("text/fuzzy/text_distance.ipynb", lookup_value, lookup_array, algo),
        index, INDEX(result, 1),
        score, INDEX(result, 2),
        IF(score >= threshold, index, "No match")
    )
)

Strengths

• Directly reference cells: Users can reference cells in Excel directly from Python code using the python xl function, e.g. foo = xl(A1). This makes it super easy to use Excel data in Python code, similar to how you would with Excel formulas.

• Outputs Python object or Excel values: Users can select whether the value returned is a Python object or Excel values. This is useful for when you want to use the output in further Python code or in Excel formulas.

• Consistent Python runtime: An Anaconda Python runtime running in the Microsoft cloud which provides a consistent version of packages and performance for all users regardless of their local machine.

• Microsoft Copilot integration: This is currently in beta, but provides a great way for non-programmers to get started with Python code in Excel.

Potential Weaknesses

We realize all of these weaknesses could be considered strengths, depending on the needs of the target market, and we’re sure the Excel product team explicitly chose to do things this way for a reason. However, in some of the use-cases we’re familiar with, these could be considered weaknesses.

• No custom packages: The Python runtime is limited to the packages available in the Anaconda distribution, which is quite comprehensive, but may lack something specific you need.

• No internet access: Your Python does not have access to the internet, so you cannot do things like access OpenAI models, call APIs, etc. This basically limits you to analyzing the data in your workbook.

• PY is not an Excel function: While PY appears to be an Excel function, you can’t use it as a function in formula. For example, if you want to create a LAMBDA that embeds some Python code using PY, e.g. =LAMBDA(x, PY(x + 2)), this does not work.

• Code is stored in workbook: The Python code is embedded directly in the xlsx file, which is consistent with the Excel paradigm. However, this means that any code changes must be copied manually to each workbook containing it rather than being managed centrally with version control.

• Code does not run locally: Since the Python runtime is in the Microsoft cloud, the code cannot run locally, which can create security issues for some, lack of offline capability, and a dependence on Microsoft cloud for performance.

• Python cells share state: The Python cells are executed in the order they appear in the workbook, and they share state, similar to a Jupyter notebook. This is both a positive and a negative, and can make it difficult to debug and understand the code.

See also this great post by xlwings on these and some other potential weaknesses.

Alternatives

Conclusion

Python in Excel is a great addition to the Excel ecosystem, and we’re excited to see how it evolves. There are now several options available for running Python code in Excel, each with their own strengths and weaknesses. We hope this post has helped you understand the differences between them and choose the one that best fits your needs.

Functions

Alternatives

The TRANSLATE function is similar to the GOOGLETRANSLATE function in Google Sheets and the Translate for Excel function provided by BoardFlare.

The main advantages of Boardflare’s Translate for Excel are as follows: - no throttling or quotas on usage. - your data stays in Excel and is not shared.

GOOGLETRANSLATE

GOOGLETRANSLATE is a popular function in Google Sheets that allows users to translate text directly within their spreadsheets. It’s a powerful tool for working with multilingual data and has become an essential feature for many users. It translates text from one language to another with a simple function syntax of GOOGLETRANSLATE(text, [source_language], [target_language]).

Translate for Excel

Translate for Excel is a function similar to GOOGLETRANSLATE, but for Excel. It uses a machine learning model to translate text directly within your spreadsheet. This means your data never leaves your document, ensuring privacy and security. Since it runs on your CPU, there are no usage limits or api fees.

Key Features

Translate for Excel offers several key features:

• Translation of 20 languages to or from English: We plan to expand the languages supported and enable translation between any pair of languages.
• Unlimited free use: There are no usage limits or fees.
• Local operation: The function runs on your computer, so your data remains secure.

How to Use Translate for Excel

Using Translate for Excel is simple. The function requires only the text you want to translate and the language code of the input text. Here’s how you can use it:

=BOARDFLARE.TRANSLATE(text, source_language, target_language)

For example, to translate a cell A1 from Spanish to English, you would use:

=BOARDFLARE.TRANSLATE(A1, "es", "en"    )

Installation

You can install Translate for Excel from the Microsoft AppSource store or directly from Excel.

Conclusion

Translate for Excel fills a significant gap in Excel’s functionality, providing a powerful translation tool directly within your spreadsheet. While it’s not as fast as GOOGLETRANSLATE, it offers the advantage of privacy, security, and unlimited free use. We’re excited to see how this function will empower Excel users to work more effectively with multilingual data.

Background

In Google Sheets extensions, Google Apps Script is used to serve the HTML page for the sidebar in the UI. To do machine learning (or any other intensive processing) client-side, ideally you want to use a web worker so the UI can remain responsive (e.g. to report on progress, cancel the operation, etc.) and also to enable multi-threaded processing.

Problem

Google Apps Script doesn’t support serving a worker script directly from a file.

Solution

We’ll use the inline worker pattern. The first step is to put the worker code in an html file in the Google Apps Script project, e.g. worker.html, with no html tags as shown below.

self.onmessage = function(e) {
  console.log('Message received from main script');
  var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
  console.log('Posting message back to main script');
  self.postMessage(workerResult);
}

Next, we inline the worker code in the main HTML file using a Google Apps scriptlet to assign the text contents of the worker.html to a variable. Note the <?!= syntax with the exclamation mark to prevent escaping of the script. After that we create a blob and object URL, and then a new Worker using the object URL. In our case we use the type: 'module' option on the Worker constructor, which creates a module worker, which we need for the ESM-only library we are using in the worker.

<!DOCTYPE html>
<html>
  <head>
    <base target="_top">
  </head>
  <body>
    <script type="module">
    var workerScript = `<?!= HtmlService.createTemplateFromFile('worker').evaluate().getContent() ?>`
    var blob = new Blob([workerScript], {type: 'application/javascript'});
    var workerUrl = URL.createObjectURL(blob);
    var worker = new Worker(workerUrl, {type: 'module'});
    worker.onmessage = function(e) {
      console.log(e.data);
    };
    worker.postMessage('Start processing data');
    </script>
  </body>
</html>

One problem with this approach is that worker.html, without script tags, is not treated by a code editor as JavaScript, so no syntax highlighting, etc. You could add script tags in the worker.html file to fix this and then strip them back out again from the string in workerScript before passing it into the blob. In our case we’re developing the worker code in a plain web app first before copying it into the Google Apps Script project, so this isn’t an issue.