LightningFlowComponents: unofficial Salesforce Flow extensions

Components an admin can install without touching code

LightningFlowComponents is a collection of installable extensions for Salesforce Flow, and the first thing the README emphasises is the installation experience. You do not need to write code, read code, or use the developer console to install these into your Flow Builder. You can install many of the components as packages from the UnofficialSF site.

That framing sets the project apart from the usual Salesforce open source. Most Apex and Lightning projects on GitHub are deployment scripts and metadata that a developer pushes with the Salesforce CLI. This one is packaged so that a Flow builder, who may never open a terminal, can add a component to a flow and use it.

The collection covers the two extension points that Flow offers. The flow_screen_components directory holds Lightning components, a mix of Aura and LWC, optimised to be insertable into Lightning Flow screens. The flow_action_components directory holds Apex classes and Lightning components optimised to be added to Lightning Flows as standalone actions. There is also a flow_apps directory for utilities and tools that do not fall neatly into either category, plus lightning_page_components and flow_process_components directories visible in the repository listing.

The technical substrate is Apex, which is Salesforce's own language for server-side logic, and the components are Lightning, the web component framework that Salesforce uses for its user interface. The homepage is unofficialsf.com, and the project is hosted under the UnofficialSF organisation.

Two facts frame everything that follows. The repository is not archived and the last push was on 2026-05-15, so the collection is still being worked on. And it has no GitHub releases at all, so there is no version history to cite and no release notes to read, which is a real constraint for anyone who wants to know what changed.

Flow Screen Components and the Flow Screen interface

The screen components are described as lightning components, a mix of Aura and LWC, that have been optimised to be insertable into Lightning Flow screens. The optimisation is not cosmetic, it is about two specific requirements.

The first is that they implement the Flow Screen interface. That is what causes them to appear in the palette of the Screen Builder in Flow Builder, where they can be dragged into Screen Nodes. Without that interface a Lightning component is invisible to the flow designer, so the component exists but cannot be used. A component in this repository is not a general purpose Lightning component that happens to be useful in a flow; it is a flow screen component first.

The second requirement is that they explicitly specify which component attributes will be visible as inputs or outputs in Flow. In a screen flow, a screen element can pass values into the flow and receive values back out of it. Declaring those attributes explicitly is what lets the flow designer wire a component into a decision, and it is the part of the work that a hand-rolled component usually leaves to the builder to guess.

The README makes a point about the visual focus of these components. They generally have a visual focus, although they do not absolutely have to. That is a useful distinction, because it tells you the design centre of gravity is presentation, with the input and output plumbing as the enabler rather than the goal.

The mix of Aura and LWC is worth flagging as an engineering reality rather than a preference. Aura is the older Lightning component model, LWC the newer web component standard, and a collection that supports both is one that spans what sales organisations actually have in their orgs, some of them built years ago on Aura and unable to move quickly. The cost of that breadth is that the components are not all modern, and a component written in Aura will not benefit from the improvements that have landed in LWC.

Invocable Actions in Apex and Local Actions in Lightning

The actions directory splits into two kinds, and the distinction is the most technical part of the project to understand.

The Apex classes are Invocable Actions. They are non-visual and execute entirely in the Salesforce cloud. In other words, a flow element that runs on the platform, with no user interface and no browser involved. The documentation link in the README goes to a page on developing flow actions, and the mental model is straightforward: a piece of server logic that a flow admin can drop onto the canvas as a node.

The Lightning components are Local Actions. The README is careful about what that means. A Local Action implements the flowruntime:availableForLocalInvocableActions interface, which is what makes it show up in the tools palette of Flow Builder as a Local Action that can be dragged onto the canvas and added to flows as discrete nodes. It also provides an invoke method, which allows the Flow engine to call it at the appropriate point during flow execution, and makes a callback to the Flow engine when it is done.

The callback is the detail that matters for anyone building a flow on top of this. The component does not return a value the way a synchronous function would. The flow engine calls invoke, the component does its work, and the component calls back when it has finished, and that callback is how the flow continues. Anyone extending a local action has to honour that contract.

There is a constraint on Local Actions that is easy to miss. They generally do not have a visual focus, and they have to run inside of Screen Flows to ensure the presence of a client-side javascript runtime. In other words, a Local Action needs a screen flow context even when it does not display anything, because the browser-side JavaScript runtime has to exist for the component to run.

That requirement is the cost of the model. A cloud-side Invocable Action has no such constraint, so choosing which kind to use is a real design decision rather than a preference.

The org setup your Salesforce administrator has to do first

Before any component can be added to a flow, the org itself has to be configured, and the README sets out the requirements plainly.

Your org must be enabled for Lightning components. That means two things. You must have My Domain enabled and deployed, and you must have the Enable Lightning Runtime for Flows checkbox enabled in Setup, under Process Automation Settings.

The first of those is familiar to any Salesforce administrator, since My Domain underpins most of the platform's modern features. The second is the one that catches people out, because a flow that uses screen components behaves differently from a flow that does not, and the setting is off by default in many orgs.

The README also states that you do not need to be using the Lightning Experience to use these flow extensions. That is worth noting, because plenty of assumptions about Lightning components are tied to the Lightning interface, and this project is explicitly about flows rather than about the console.

For a team rolling this out, the practical sequence is therefore: enable My Domain and deploy it, turn on Enable Lightning Runtime for Flows, install the package from the UnofficialSF site, and then use the components in the Flow Builder palette. The first two steps are org administration, and they are not something a component can work around.

One more piece of context comes from the repository listing rather than the README. There is an install.md file, a packaging/ directory, a force-app/ directory and an sfdx-project.json, which is the Salesforce CLI project file, plus a .swift-sfdc.json and a .forceignore. So the repository does contain the packaging and CLI structure needed to build and distribute the packages, even though the end user never touches it.

How the repository is organised and how people contribute

The directory names map exactly onto the concepts in the README, which makes the repository easy to navigate once you know the vocabulary.

flow_screen_components/ is the screen palette, flow_action_components/ is the action palette, flow_apps/ is the everything-else bucket, and the repository listing also shows flow_process_components/ and lightning_page_components/. The last of those is interesting because it extends the idea past flows to Lightning pages, which is the same component model applied to a different host.

The build and distribution machinery is visible too, with a force-app/ directory that is the standard Salesforce DX source format, an sfdx-project.json describing the project, a packaging/ directory, install.md, and sfdxintro.md. The .forceignore file controls what is excluded from the package, which is how a repository with a lot of source keeps the installed artefact small.

The contribution model is open. The README says that if you have built a useful or interesting Flow Component, you are encouraged to make a pull request and add it to the repository, and that you can also enhance or fix any existing component. General conversation happens in the Issues section and in two communities, the UnofficialSF Trailblazer Community and the Salesforce Automation Trailblazer Community on the Trailhead and Success sites.

Pointing at two named communities rather than a Slack or a Discord is a deliberate choice for this audience. Trailhead and Success are where Salesforce administrators and consultants already are, so the discussion sits where the people who would use these components already talk.

The top-level listing also contains an issues file and a _config.yml, the latter usually indicating a GitHub Pages site for the project, plus a .github/ directory for the workflows. Combined with the absence of releases, the picture is of a community-maintained collection that grows by pull request rather than by a release train.

Where LightningFlowComponents is the wrong tool

The first limitation is the obvious one, and the project is honest about it in its own name and description. These are unofficial components, and Salesforce does not support them. Nothing in the repository provides a compatibility statement between component versions and Salesforce API versions, so a component that works in your org today may behave differently after a seasonal platform update.

The second is the Aura and LWC mix. Supporting both widens the range of orgs the collection can serve, and it also means a meaningful share of the components are built on the older model. If your org is new and you are only going to use LWC, you are carrying a compatibility burden for components that predate the model you will build on.

The third is the packaging dependency. The installation path is a package from a third-party site rather than a package from the Salesforce AppExchange, and the setup requires the org administrator to enable specific platform settings. In an organisation with change control and a strict software approval process, that is a procurement conversation, and this collection will not pass it on the strength of a GitHub repository.

The fourth is that Local Actions constrain the flows you can build. A Local Action has to run inside a Screen Flow, so a flow that is entirely headless, an autolaunched flow or a subflow invoked from a trigger, cannot use one. If your architecture is built on background flows, that part of the collection is simply unavailable to you.

The fifth is testing. Nothing in the README describes unit tests for the components or a test strategy, and the repository listing shows no test directory. For components that other people will drop into production flows, that is the gap I would want closed first, and it is something a consuming team can partly close by testing the components they install in their own org.

Licence, releases and who carries the risk

The licence is the first thing to resolve, because it is the one piece of information the project does not state plainly. The repository record says the licence is one GitHub cannot classify, and points at a LICENSE file in the root. This article does not interpret that file. For a collection of components that will run inside your org and call your data, the terms matter more than they would for a sample project, and a file you have to open to find out what they are is a reasonable thing to raise with whoever owns the decision.

The release situation is the second. There are no GitHub releases, so there is no tag to pin, no changelog between versions, and no indication of which components changed when. For a collection installed as a package, that is the gap that matters most in practice, because a package upgrade brings changes to components you may not even be using, with nothing to read about them.

The maintenance signal is more encouraging than the release signal. The repository is not archived and the last push was on 2026-05-15, so somebody is still committing to it, and the README actively invites pull requests for new components and for fixes to existing ones. The project is alive in the way that matters, which is the code moving, rather than in the way that a version number would suggest.

The last thing to weigh is who carries the risk. Unofficial means the community carries it, not Salesforce. A Flow builder who installs these components is taking on the job of testing them in their own org, keeping an eye on what changed, and replacing them when a platform update breaks something. That is a reasonable trade for an admin who wants a screen component today and does not want to write Aura, and a poor trade for a critical production flow with a change advisory board.

For that reason the sensible adoption path is narrow. Install a component, exercise it in a sandbox org, keep it out of the flows that carry revenue until you trust it, and prefer the Invocable Actions over the Local Actions where the flow shape allows it, since they run entirely in the Salesforce cloud and have no client-side runtime requirement.

Editorial conclusion

Adopt LightningFlowComponents if you build screen flows in Salesforce and want ready-made screen components and actions that a flow admin can install as a package instead of writing Apex and Lightning yourself. Do not adopt it where the deployment requires vendor support, a tested upgrade path, or a guarantee that a component keeps working across Salesforce releases, because nothing in the repository provides those. Verify first that the components you want are packaged for your org, that the Flow runtime requirements in your setup are already met, and that the licence terms are acceptable, since the licence is one GitHub cannot classify, the repository has no GitHub releases, and the last push was on 2026-05-15.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. UnofficialSF/LightningFlowComponents on GitHub