Microsoft Power Fx: the spreadsheet-formula language you can embed in C#

What Power Fx solves, and who the repository is actually for

The problem is business logic that non-programmers need to read and edit. Power Fx is described in the README as "a low-code general purpose programming language based on spreadsheet-like formulas", strongly typed, declarative and functional, with imperative logic and state management available when needed. That combination is what separates it from a general scripting language: a formula such as a filtered table expression is the unit of composition, not a statement list.

The audience for this GitHub repository is narrower than the audience for Power Apps. The README states that Power Fx "started with Power Apps canvas apps and that is where you can experience it now", and that the team is "in the process of extracting the language from that product". So the repository is for C# developers building a host that needs a formula language, and for people tracking how the language is being generalized. If you want to write Power Fx today as an end user, the README points at Power Apps, not at these packages.

How the language is packaged and how evaluation flows

The repository ships several NuGet packages rather than a single binary. The README's package table lists Microsoft.PowerFx.Core, Microsoft.PowerFx.Connectors, Microsoft.PowerFx.Json, Microsoft.PowerFx.Core.Tests, Microsoft.PowerFx.Interpreter, Microsoft.PowerFx.LanguageServerProtocol and Microsoft.PowerFx.Transport.Attributes. The split tells you the intended layering: Core holds the language itself, Interpreter is the evaluation path, Connectors and Json deal with external data shapes, and LanguageServerProtocol is there for editor integration.

A host supplies values and functions, then asks the library to evaluate an expression. The samples repository linked from the README, microsoft/power-fx-host-samples, is where that wiring is demonstrated, and the README also points at the unit tests under src/tests for usage examples. That is a deliberate choice: the tests are the de facto API documentation, which is common for a language implementation but means you should expect to read test code to learn the public surface.

The docs folder holds a language documentation start, and the README is candid that it is "being extracted from the Power Apps documentation and generalized and that too is going to take some time". Treat docs/overview.md as a starting point, not a complete reference.

Installing Power Fx and running a first evaluation

There is no installer and no CLI in the README. Consumption is through NuGet packages, so the first step is adding the package that contains the evaluation path. The README lists Microsoft.PowerFx.Interpreter as a released package.

If you want the newest builds rather than the released ones, the README documents a daily feed on Azure Artifacts. The package source URL given in the README is:

https://pkgs.dev.azure.com/Power-Fx/7dd30b4a-31be-4ac9-a649-e6addd4d5b0a/_packaging/PowerFx/nuget/v3/index.json

Add that as a NuGet source and the daily packages become available; dailyBuilds.md carries the detailed instructions the README refers to. Note that the README's package table links to NuGet pages whose URLs do not all match the package names in the table, so confirm the exact package ID on nuget.org before you add it.

For a first real use, the README does not give a code sample, so the honest path is the host samples repository. Clone it and read how a host registers functions and evaluates an expression, then compare with the tests under src/tests. What you should see is a host object that owns the symbol table and the evaluation call, with the formula text passed in as a string.

The extraction caveat and where Power Fx is the wrong tool

The largest limitation is stated by the project itself. Power Fx is being extracted from Power Apps, and both the implementation and the documentation are described as in-progress extractions. That means the repository's language surface and the Power Apps documentation you find online are not guaranteed to line up. If your team already writes Power Fx in canvas apps, do not assume the NuGet packages behave identically in every corner.

A second constraint is the host burden. Nothing in the README describes a standalone runtime that reads a file and executes it. You embed the language in a C# application and you provide the data and functions. Teams looking for a drop-in scripting engine for a non-.NET service, or for a sandbox that runs untrusted user formulas without additional work, will not find that here.

Finally, the release cadence deserves a look before you plan around it. The most recent release listed is 1.2.0 from 2023-12-22, preceded by 1.1.0 on 2023-10-10 and 0.2.6-preview on 2023-06-01. The repository's last push was on 2026-09-04, so work continues, but the tagged releases are older than that activity. Pin a version and read the releasenotes folder rather than assuming the latest commit is a supported drop.

Power Fx compared with embedding a general scripting language

The obvious alternative for a .NET host is a general-purpose embeddable scripting language, or simply a small expression parser you write yourself. The difference in approach is the type system and the formula model. Power Fx is strongly typed and declarative, so a table filter or a column projection is a first-class expression that the engine can type-check before evaluation. A general scripting language gives you statements, loops and mutable state as the default, and you would build the safe evaluation subset on top.

That matters for who authors the formulas. If the people writing expressions are business users who think in spreadsheet terms, the Power Fx surface is closer to what they already know, and the README's framing of spreadsheet-like formulas is the whole point. If the people writing expressions are developers who want full control flow and a large standard library, a general scripting language is less friction, because you are not fighting a declarative model or waiting on an extraction to finish.

There is also the ecosystem question. Power Fx connects to Microsoft Power Platform products by design, and Connectors is one of the shipped packages. A host outside that ecosystem gets the language but not the surrounding service integrations, which you would supply yourself.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and its last push was on 2026-09-04, so it is being worked on. That said, the release history is uneven: 1.2.0 landed on 2023-12-22, and the daily Azure Artifacts feed exists precisely because released packages lag the main branch. If you depend on released NuGet versions, budget for the gap between what the repository does and what the tagged package does.

Upgrade cost is dominated by the extraction work. Because the language is still being generalized out of Power Apps, a version bump can change behaviour that was previously inherited from the product. The releasenotes folder is the place to read before upgrading, and ApiCompatBaseline.txt plus ApiCompat.Files.xml at the repository root indicate the project tracks API compatibility, which is a signal that breaking changes are at least being measured rather than ignored.

The licence is MIT, which is permissive and places few obligations on how you redistribute the packages. The README's trademark section is separate from the licence and restricts use of Microsoft trademarks and logos, including in modified versions. That is a branding constraint, not a code constraint, and it is worth reading the linked guidelines if you plan to ship a product that mentions Power Fx by name. This is not legal advice; check with your own counsel for your distribution.

Editorial conclusion

Adopt Power Fx if you are a .NET team that wants a strongly typed formula language in your own host and can live with an extract-in-progress surface; the host samples repository is the fastest way to judge that fit. Do not adopt it as a standalone runtime for non-.NET services, and do not expect the docs folder to match the Power Apps documentation you may already know. Before committing, verify which NuGet package actually contains the evaluation path you need (Microsoft.PowerFx.Interpreter versus Microsoft.PowerFx.Core), and check the releasenotes folder against the 1.2.0 release from 2023-12-22, because the README's package table links to NuGet pages whose package IDs do not all match the names in the table.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/Power-Fx on GitHub
4. README
5. Releases