lightningDataTableFSC: The Numbered-Attribute Hack That Fixed Salesforce Flow

How a "flat" metadata workaround bridged the gap between elite code and admin-friendly automation during the Aura era.

• View on GitHub • More from hwong103

A large stone bridge connecting two cliffs, held together by oversized, numbered bolts.
Bridging the gap between complex code and visual automation blocks.

Key Takeaways

The Era of the Blind Automation

Before the advent of modern Lightning Web Components, Salesforce administrators faced a frustrating paradox. The Flow Builder was a powerful automation engine capable of processing thousands of records behind the scenes. Yet, when it came to interacting with users, it was remarkably blind. If an admin wanted to present a user with a simple table of records to select from, the native tools offered no elegant solution.

Developers had to intervene, writing custom code for every specific use case. This defeated the purpose of a "low-code" platform. The ecosystem needed a bridge—a reusable component that could translate the rigid requirements of a data table into the limited, string-based inputs that Flow could understand.

The "Flat" Workaround

The brilliance of lightningDataTableFSC lies in its embrace of an "ugly" but necessary hack. The Flow Builder UI of the time could not easily pass complex JSON arrays representing column definitions into a component. To solve this, the author flattened the configuration.

Instead of expecting a single, structured columns object, the component's .design file hardcoded dozens of individual, numbered attributes: colLabel01, colAPI01, colType01, and so on, all the way up to column 10. It was a brute-force approach to metadata that perfectly bypassed the limitations of the declarative UI.

How flat, numbered Flow inputs are transformed into a structured array.

A Salesforce Lightning Web Component that can be used as a Flow Screen Component to display a data table.

hwong103, Creator and Maintainer · hwong103/lightningDataTableFSC

The Controller as an Assembly Line

If the metadata design is a flat list, the JavaScript controller is the assembly line that puts it all together. When the component initializes, the controller harvests these 40+ separate string variables. It checks which ones are populated and methodically constructs the exact JSON structure required by the underlying lightning:datatable base component.

A mechanical sorter funneling many small, flat envelopes into a single bound book.
The JavaScript logic acts as an un-flattening engine for component metadata.

This assembly process is entirely hidden from the admin. To the person building the Flow, they simply type "Account Name" into a box labeled "Column 1 Label." The component handles the heavy lifting of dynamic SOQL generation and state management, providing outputs like selectedRowIds back to the Flow for further processing.

A Community-Driven Standard

This component did not exist in a vacuum. It was heavily influenced by early efforts in the Salesforce community to standardize Flow extensions, most notably the work surrounding "UnofficialSF." These community-built tools empowered a new persona: the "Adminel," an administrator who could orchestrate developer-level complexity without writing Apex.

FeaturelightningDataTableFSCNative Flow TableUnofficialSF Datatable
Configuration StyleNumbered Attributes (Flat)Declarative UIDeep LWC Properties
Complexity LevelModerateLowHigh
FrameworkAura / LWC WrapperStandard ComponentModular LWC

Eventually, the sheer popularity of these community hacks forced Salesforce's hand, leading to native data table support in Flow years later. But the numbered-attribute pattern remains a fascinating artifact of how developers bend rigid systems to their will, prioritizing user experience over architectural purity.