Python in Excel: cloud calculations and a maintainable workflow

Python in Excel can shorten the path from a table to an analysis, provided you understand where the spreadsheet ends and the computational environment begins. When I see code beside ordinary formulas, I ask where the inputs come from, how the result will be refreshed and who will maintain the workbook. Adding Python does not answer those questions automatically.

Here I explain how I would approach a first use case, separate responsibilities and prepare a file for another person. Availability information is checked as of 28 October 2026. The original Polish video dates from the feature’s early days; the description below uses current Microsoft documentation rather than treating that announcement as today’s specification.

Where the code actually runs

According to Microsoft’s introduction, you enter Python in a cell, but calculations run in Microsoft’s cloud. Results return to the worksheet. An internet connection is required; a local Python installation is not. Customizing Python on your laptop does not customize the environment used by these workbook calculations.

That distinction affects how I plan a report. The cell is an input and presentation surface, while calculation depends on a service. If someone needs a report for a meeting, I consider connectivity and recalculation. Having an image of yesterday’s chart and being able to rebuild the chart from today’s data are different requirements, even when the workbook initially looks identical.

I start by drawing a simple flow: source records, preparation, calculation and output. Beside each connection, I write who owns a change and how a failure would become visible. If I cannot explain this without opening the code, the workbook needs a clearer design before I choose a library. Extra technology rarely makes an unclear responsibility easier to understand.

Imagine two teams receiving the same orders table. One needs totals by city. The other wants to inspect the distribution of handling times and compare analytical approaches. For the first, I start by considering a PivotTable. For the second, Python may offer useful tools. The choice follows the question and the people using the result, rather than the appeal of adding a programming language.

Check availability on the account you will use

Python in Excel availability depends on subscription, platform and update channel. Microsoft documents Windows, web and Mac support under different conditions for business, education, Personal and Family users. A product called Excel therefore does not guarantee the same Python experience for every person opening your file.

Before starting a project, check the signed-in account, application version and presence of Formulas > Insert Python. If the command is missing, compare that setup with the availability page first. Installing more local packages is an unhelpful response to a feature that may not be available for the account or update channel in question. Diagnose the actual boundary before changing the setup.

The optional add-on can expand compute and calculation-mode options. I check the current Microsoft comparison before making a purchasing decision, rather than copying a price or allowance remembered from the launch. What matters to a project is the capability available to its actual authors and readers. A specification for an ideal account is of little help when the receiving team uses something else.

For a small team, begin with two people: the author and the intended recipient. Open the same workbook under the conditions in which each person normally works. Decide whether the recipient must only read an existing result or also change an input and recalculate. Discovering that distinction early is much easier than explaining a blocked workflow during a presentation or an unexpected absence.

Separate data collection from analysis

The data security documentation describes an isolated container with no network access or access to the user’s computer. Python reads referenced data through xl(). Instructions from a local script that assume a filesystem path or download data directly from a website therefore cannot simply be carried over unchanged.

I separate three questions in the design: where records originate, how they are prepared and what the analysis calculates. For repeatable preparation, consider Power Query. Anyone reviewing the result should be able to identify the input period and transformation rules. A finished chart alone cannot tell them whether the source file changed or a filter removed part of the population.

Where the working conditions and data-retention rules allow it, I keep source material distinguishable from the prepared table. I describe what one row represents, its units and the meaning of missing values. That gives later comparisons a common reference. Without it, people can argue about analytical techniques while actually comparing different sets of records, different time windows or different definitions of the same column.

Consider four synthetic support tickets. Each has an identifier, team and handling time in minutes: 2, 4, 6 and 8. All four are completed and each appears once. That short description provides more useful context than a column called value. If the next export includes open tickets, the measure needs a clear rule for those records before we discuss their effect on the average.

Begin with one small Python cell

Microsoft’s getting-started guide describes enabling Python through the ribbon or =PY. Inside a cell in Python mode, xl("A1") + xl("B1") reads two cells. With 2 in A1 and 4 in B1, the expected result is 6. This is a small example whose arithmetic can be followed directly.

That is enough for a first exercise. Establish that you understand the connection between an input cell, the expression and the output before introducing a table or a more involved operation. A long script is unnecessary at this stage. A short expression makes it easier to identify which assumption stopped matching the workbook and what information you need before going further.

Do not enter that expression into an ordinary cell as if it were a standard Excel formula. Enable Python mode first. Explain that distinction when handing instructions to a colleague: the editing surface may look familiar, but the language and execution environment differ. A useful instruction points to a specific cell and a specific action, rather than merely saying that the person should paste some code.

Return to the four synthetic tickets. Their combined handling time is 20 minutes and their average is 5 minutes. Those figures provide a reference that a reader can establish without software. If a later calculation produces something different, begin by examining the number and meaning of the input records. Adding a more sophisticated statistical method will not explain an unresolved mismatch in this basic population.

Choose a library after choosing a question

Microsoft’s library list includes pandas, NumPy, Matplotlib, seaborn and statsmodels. The integration provides a managed environment. Do not assume every package from an arbitrary tutorial, or every customization of a local installation, is available in the workbook in the same form. Check the relevant environment before planning around a dependency.

I choose a library after writing the analytical question. Do I need a distribution, a table transformation or a particular model? Then I define the smallest useful output. If a table with a few measures answers the question, I do not immediately build a panel of charts. Evaluating one clear result is easier than separating useful evidence from an attractive collection of visualizations.

For the example handling times, the average describes the centre but does not answer every question. I might also need the shortest and longest handling time, a ticket count or the number of records with no duration. Each measure requires a definition. A library cannot decide whether a missing time means an open ticket, an import failure or a legitimate exception in the business process.

I also leave a simple reconciliation beside the analysis: perhaps the input and output record counts plus a few named identifiers. That check should help the next person making a change. If the report stops matching expectations, they can inspect a stage with a clear purpose. They should not need to reconstruct the entire history of the workbook or guess which experiment eventually became the published calculation.

Decide what the next step needs from the output

Microsoft distinguishes a Python object from Excel values in its output instructions. An object retains information useful for subsequent Python work. Returning Excel values allows ordinary spreadsheet features to consume the result. Choose an output that suits the next operation or reader, rather than treating the two options as interchangeable presentation settings.

If the report ends with a table for an operations team, use clear headings and units. Agree whether recipients will filter the results, compare periods or move data to another file. Sending an image does not automatically supply the records needed for their own analysis. I settle that requirement before spending time on colours, chart sizing or an elaborate arrangement of visual elements.

On the result sheet, include the input period and a short definition of each important measure. A number such as 5 without a unit can mean minutes, hours or tickets. Those interpretations imply very different actions. Even a technical practice workbook is a useful place to develop the habit of naming outputs so that they make sense without the author sitting beside the reader.

When handing over a report, ask the recipient to explain one measure in their own words. If they cannot identify what was counted and from which records, improve the description. This is a practical communication exercise, without requiring the recipient to know Python. It can reveal that two teams have been using the same label for different concepts even though both believe the report is obvious.

Make dependencies and refresh responsibilities visible

Python calculations follow row-major order, including worksheet order, so definitions must precede the calculations using them. The getting-started guide explains that ordering. The physical arrangement of Python steps therefore deserves attention when designing a workbook. Moving a step for a tidier appearance can affect assumptions about where variables are available.

I separate inputs, calculation steps and the final view. Sheet names describe their role, and important steps receive a short statement of the business assumption, such as including only completed tickets. A changed reporting rule then has a visible place. The maintainer should not have to search through abandoned experiments to discover the filter that determines the published population.

Agree how the person refreshing the report will recognize completion. They need to know that the final view reflects the current inputs. If part of the result was copied manually, label it clearly. Mixing live calculations and old snapshots without a visible distinction makes the whole workbook harder to assess, even when every individual number appears plausible and no obvious error message is present.

Before handing over the file, ask what changes next period, who will make that change and what a failed update would look like. Put those answers close to the report. The instruction should work during an ordinary working day, including a day when the original author is away and cannot explain a forgotten detail over a message or a call.

Review the calculation as well as the environment

The isolation described by Microsoft limits what code can access; it does not establish that a conclusion is correct. I can still reference the wrong range, exclude relevant tickets or give an output a misleading label. In a review, I discuss the conditions for using the service separately from the meaning of the calculation. Both questions need a clear answer before the report becomes dependable.

Use your organization’s existing rules for working with data. Do not change application protections simply to make a tutorial work. If the dataset or service use needs clarification, resolve that before introducing real records. The synthetic tickets in this article are enough to learn the editing interface, understand a reference and discuss a simple result without borrowing a production dataset for the exercise.

For a technical maintainer, I describe references and assumptions. For a report reader, I describe the meaning of the measures. These explanations can be short, but they serve different needs. The first supports a future change to the calculation. The second supports a decision based on its result. A note saying only that the figures were calculated in Python provides neither kind of understanding.

Give the first project a clear finish

Choose a small report that you already understand. Write down its question, inputs and expected answer for a handful of records. Only then decide whether Python makes a particular step easier. If you need to organize the underlying spreadsheet skills first, review Excel lookup functions before adding another computational layer to the file.

Treat the exercise as complete when another person can use the workbook with a short instruction. They should know what to change, what to refresh and how to recognize the expected result. Achieving that on a small dataset gives you a useful foundation. Choose the next addition according to the remaining problem in the report, rather than adding features merely because the environment makes them available.