Flex Toolkit for Lightning Platform
The Flex Toolkit for Lightning Platform, originally released as the Force.com Toolkit for Adobe AIR and Flex, was a developer library for building Adobe Flex and Adobe AIR applications that read an…
Definition
The Flex Toolkit for Lightning Platform, originally released as the Force.com Toolkit for Adobe AIR and Flex, was a developer library for building Adobe Flex and Adobe AIR applications that read and wrote Salesforce data. It shipped a set of ActionScript classes that handled login, queries, and record changes by calling the Salesforce SOAP API, so a Flex front end could talk to a Salesforce org without a custom middle tier.
This toolkit is retired. Salesforce stopped maintaining it after Adobe wound down Flex and AIR as web platforms, and Adobe Flash Player itself reached end of life on December 31, 2020. Nothing new should be built on it. The definition is kept here so teams can recognize old Flex code and understand the path off it. The supported replacements today are the Salesforce Mobile SDK for native and hybrid apps, plain JavaScript on top of the REST API for web clients, and Lightning Web Components for user interfaces that live inside Salesforce.
How Flex apps talked to Salesforce, and why that approach ended
What the toolkit actually was
The toolkit was a downloadable ActionScript library, not a feature inside the Salesforce org. A developer added it to an Adobe Flex or Adobe AIR project in Flash Builder, then wrote ActionScript that used the library classes to authenticate and move data. Under the hood it wrapped the Salesforce SOAP API, the same Enterprise and Partner WSDL based interface that Java and .NET clients used at the time. Flex was Adobe's framework for Rich Internet Applications, the term for browser apps that felt more like desktop software than the form heavy web pages of that era. Adobe AIR extended the same code to run as an installed desktop application, with the option to cache data and keep working offline. The package included a developer guide and ASDoc generated reference, and Salesforce shipped an enhanced Adobe Flash Builder for Force.com that added templates and login helpers. The promise was speed. A small team could put a polished, data bound interface on top of a Salesforce org without standing up servers, hosting, or a security layer of their own.
The connection and data flow
A Flex or AIR application using the toolkit followed a predictable sequence. First it logged in, passing a username, a password, and a security token to the SOAP login call. The response handed back a session id and the specific server URL the org lived on, and the toolkit stored both for later calls. From there the app issued asynchronous requests. It ran SOQL through a query call, created and changed records with create and update, and removed them with delete, each one mapped to a SOAP operation against generic SObject structures. Because Flex was event driven, results arrived through result and fault handlers rather than blocking the interface, which kept the UI responsive while a call was in flight. AIR builds could layer a local store on top of this, holding records on the device and pushing changes back when a connection returned. None of this logic lived in Salesforce. The org simply saw ordinary API traffic, so the same governor limits, field level security, and sharing rules that applied to any integration applied here too.
Why it was retired
The toolkit did not fail on its own. Its foundation disappeared underneath it. Adobe stopped investing in Flex as a web platform and later handed the framework to the Apache Software Foundation, and the broader industry moved to HTML5, CSS, and JavaScript for rich browser interfaces. The decisive blow was Adobe ending support for Flash Player on December 31, 2020, with all major browsers blocking Flash content after that date. A Flex application in a browser had nothing left to run inside. AIR continued under a different owner for desktop use, but Salesforce had already shifted its developer story to mobile and JavaScript. Salesforce never published a single dramatic retirement notice for this toolkit the way it does for an API version. It simply stopped maintaining and promoting it, dropped it from the recommended tool set, and pointed developers at the Mobile SDK and JavaScript options instead. The result is the same as a formal end of life. There is no current download path, no support, and no reason to start a project with it.
What replaced it
Salesforce did not leave a gap. For phone and tablet apps, the Salesforce Mobile SDK is the supported path. It covers native iOS and Android, an HTML5 option, a hybrid model that wraps web code in a native shell, and React Native for JavaScript developers who still want a native feel. The SDK bundles OAuth login, REST API helpers, the SmartStore offline cache, and Mobile Sync for two way offline synchronization, which together cover the offline desktop scenarios people once reached for AIR to solve. For web clients, the pattern is now plain JavaScript calling the Salesforce REST API directly, often from a single page application. For interfaces that belong inside Salesforce itself, Lightning Web Components is the modern framework. LWC builds custom UI from standard HTML and JavaScript using native browser web standards, and it replaces both the old Flex embedding tricks and much of what Visualforce did. The throughline is that every replacement uses open web standards or native mobile languages, none of which depend on a browser plugin.
Migrating a legacy Flex application
If an old Flex or AIR app is still in service, treat it as a rebuild rather than a patch. The data contract is the easy part to carry over, because the SOAP operations the toolkit used map cleanly onto the modern REST API and onto SOQL that has barely changed. The work is the front end. Inventory what the Flex app does, separating genuine business logic from interface code, then pick a target by where the app needs to run. A staff facing screen that lives inside Salesforce points to a Lightning Web Component. A public or standalone web app points to a JavaScript single page app talking to REST. A field tool that needs to work without signal points to the Mobile SDK with SmartStore and Mobile Sync. Move authentication off the old username, password, and security token login and onto OAuth 2.0, which is the supported flow for every modern client. Rebuilding also retires a real security and staffing risk. Flash is dead, ActionScript talent is scarce, and an unsupported library can hide problems that never get a fix.
Where it sits in Salesforce history
This toolkit belongs to a specific window, roughly 2007 through the early 2010s, when Adobe Flex and AIR were a leading way to deliver rich, interactive applications and Salesforce was courting that developer community. It sat alongside a family of platform toolkits from the same period, including kits for .NET, PHP, and a JavaScript REST option, all meant to let outside developers reach Salesforce data from their language of choice. Reading about it is useful for two reasons. It explains stray ActionScript, SWF files, or AIR installers an admin might still find attached to an old internal tool, and it shows how Salesforce has steadily narrowed its supported toolset toward open standards. The same instinct that retired this toolkit also retired the Ant Migration Tool and steered everyone toward the Salesforce CLI and Salesforce Extensions for VS Code. For a present day developer, the practical takeaway is short. Recognize the name, understand that it called the SOAP API from a now dead client platform, and reach for the Mobile SDK, REST with JavaScript, or LWC for anything real.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Flex Toolkit for Lightning Platform.
Hands-on resources to go deeper on Flex Toolkit for Lightning Platform.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. The Flex Toolkit for Lightning Platform let developers build client apps in which now-retired stack?
Q2. Why is the Flex Toolkit no longer a viable choice for any net-new Salesforce integration work?
Q3. A legacy Flex Toolkit app needs rebuilding. Which modern stack is the appropriate replacement target?
Discussion
Loading discussion…