Running R Scripts in Power BI - When It Still Makes Sense in 2026

R inside Power BI is one of those features that's been quietly sitting in the product for years. Most report builders ignore it. Most data scientists who use R don't realise it's there. The ones who do use it tend to use it in very specific places, where R is the right tool and nothing else will do. I want to walk through what's still worth using R for in 2026, and where you should probably stop and reach for something else.

This is opinionated. There are people who'll argue for R in places I'd argue against it, and that's fair. The takeaway I want you to leave with is: use R where it earns its keep, not because you happen to know R and want a reason.

What R in Power BI actually does

Power BI gives you two places to use R. The first is in Power Query, where you can drop an R script as a transformation step. The script takes the current table as input, returns a transformed table, and the rest of the query keeps going. The second is in the report canvas, where you can drop an R script visual that takes data from your model and returns a plotted image.

Both run R against a local installation. You need R installed on your machine, with the right packages, and the path configured under File > Options > R scripting. When you publish to the service, you also need the on-premises data gateway with R installed, and the service has its own constraints around which packages are supported.

That last point is worth pausing on. Not every R package works in the service. The service only supports a subset. If your local report uses a package that isn't on the list, your report works on your machine and breaks the moment it's published. We've been bitten by this. The fix is to check the supported packages list against your script before you start.

Where R still earns its keep

A few cases where I'll happily reach for R inside Power BI.

Statistical visuals that DAX can't do. Box plots, violin plots, correlograms, kernel density plots. DAX is excellent at aggregation and ratios but it doesn't do statistics. Power BI's built-in visual library has a few of these but the customisation is shallow. If you want a properly styled violin plot with a custom colour ramp and a fitted distribution overlay, R with ggplot2 is the path of least resistance. Build it once, drop it in the report, done.

Forecasting and time series modelling. The built-in forecast feature is fine for showing a confidence cone on a line chart. The moment you need ARIMA, prophet-style trend decomposition, or any kind of model with seasonality components you can actually inspect, you're in R territory. The forecast and fpp3 packages in R are still some of the best tooling available for this kind of work, even if Python's catching up.

Bespoke geographic plots. The built-in map visuals in Power BI are perfectly fine for "show me sales by state". The moment you want a choropleth at SA2 level with proper Australian Bureau of Statistics shape files, a custom colour scheme, and annotations on specific regions, R is the easier path. ggplot2 with sf gives you full control over the geography in a way the built-in maps don't.

Quick exploratory analysis embedded in the report. Sometimes the analyst team wants a working space in the report itself, where they can run a script against the current data slice and see the output. R visuals are good for this in a way that the standard visuals aren't.

We use this kind of statistical layer in a few of our machine learning engagements, particularly where the client has an existing R codebase they don't want to throw away.

Where I'd avoid R inside Power BI

Honest about the limits.

Anything that needs to run quickly. R visuals are slow. They re-render on every interaction. If you put an R visual on a page with a slicer and a couple of other interactive elements, the R visual is going to lag behind everything else. Users will think the report is broken. For anything that needs to feel responsive, build it in native Power BI or use a custom visual.

Heavy data transformation. Using R scripts as Power Query steps to do "real" data shaping work is a path to sadness. The script runs locally on refresh, the data has to be marshalled into and out of R, and the result is harder to debug than the equivalent Power Query M code. If you can do the transformation in M or DAX, do it there. Only use R in Power Query when you genuinely need a statistical operation that M doesn't support.

Visuals that need to be interactive. R produces static images. Once it's on the page, the user can't hover over a point and see a tooltip, can't click to drill through, can't sync with a cross-filter. For most business report use cases, this kills R as an option. If your stakeholder is going to ask "what's that data point", and you can't answer with an interactive tooltip, the visual fails the basic report test.

Publishing to environments without the gateway. If your client doesn't have an on-premises data gateway, or they're on a Fabric capacity without the right configuration, R scripts won't work in the service. The report works on your machine and silently breaks when published. We've seen consultants ship reports with R visuals to clients who didn't have the gateway. The reports looked great in the demo. They were broken by the next morning.

A few practical patterns

If you decide R is the right tool for a piece of the work, here are a few patterns we've found that hold up.

Keep the R code tight. The script inside a Power BI R visual should do one thing. Aggregate, plot, return. Long scripts with multiple data manipulation steps are hard to debug because the errors come back from the Power BI engine wrapped in a generic "script failed" message. Short scripts fail more obviously.

Test in RStudio first. Develop the script in RStudio against a sample of the data, then paste it into Power BI once it's working. The Power BI script editor is a single tiny text box. It's not where you want to be doing trial and error.

Use ggplot2 by default. The other plotting libraries in R have their fans, but for embedded visuals in Power BI you want something that produces consistent, well-styled output without much fiddling. ggplot2 wins here. Apply a theme at the bottom of every script so the visual style stays consistent across your report.

Use the htmlwidgets export trick when you need interactivity. R can produce HTML widgets via libraries like plotly or leaflet, and these can be embedded in Power BI using the HTML visual. This is fiddly but gives you proper interactive R-driven visuals when you need them. We've used this for a few specialised dashboards where the standard Power BI visuals weren't enough.

Cache the script output where you can. If the R script is expensive and the inputs don't change often, consider running the R logic upstream in a notebook or a scheduled R script, and writing the result into a table that Power BI just reads. The report becomes faster, the R logic becomes easier to version, and the visual is just rendering a precomputed result. This is the pattern we use most often these days.

What about Python?

Honest comparison: for most of the work I described above, Python is now a more practical choice than R inside Power BI. The Python integration is feature-equivalent. The package ecosystem is broader. The matplotlib and seaborn output looks fine. The pandas data manipulation is easier to write than the dplyr equivalent if you don't already know dplyr.

The only places I'd still pick R over Python are: when the client has an R codebase already, when the analyst is more comfortable in R than in Python, or when the specific R package (often a statistics or forecasting one) genuinely outperforms the Python equivalent. Outside those cases, Python is the way I'd lean.

This is a shift from where I was five years ago. R was the better choice then. The gap has closed.

When R isn't the answer at all

Worth saying out loud. If your statistical or forecasting need is large enough to matter, the better answer might be to build the model outside Power BI entirely. Use Azure Machine Learning or Fabric notebooks to train and serve the model. Have Power BI consume the predictions from a table or an API. The Power BI report becomes a presentation layer. The model lives somewhere it can be properly versioned, tested, and monitored.

This is the pattern we recommend for any model that's going to be relied on for business decisions. R inside Power BI is fine for a one-off chart in an exploratory report. It's not the right home for a model the business is going to act on every week. The pipeline matters. The model lineage matters. The ability to retrain matters. None of that is well-supported when the model lives inside a Power BI visual.

If you're trying to work out whether your analytics work belongs in Power BI, in a separate ML pipeline, or in a custom application, we spend a fair bit of time on this kind of architecture call in our AI strategy work with Australian businesses.

The short version

Use R in Power BI for statistical visuals, forecasting, and bespoke geographic plots. Don't use it for fast interactive visuals or heavy data shaping. Test in RStudio. Watch the supported package list when you publish. Consider Python first unless you have a reason to prefer R. And if the model matters to the business, lift it out of Power BI and put it where it can be properly maintained.

It's still a useful feature in 2026. Just not for everything.

If you'd like a hand working out which parts of your analytics stack should live where, we can chat. The Microsoft reference for the feature itself is here: Run R scripts in Power BI Desktop.