What Is a Data Table in Salesforce? A Guide for SaaS Teams Showing Their Data on Record Pages

A data table in Salesforce is usually lightning-datatable, the base Lightning Web Component that shows rows and columns of data on a Lightning page. Salesforce also has a Data Table component for screen flows and the older Visualforce apex:dataTable. When a SaaS company wants its own product's data on a customer's account or opportunity page, the component is the easy part. The real decision is where the rows come from, because that choice sets your API load, your security review work and what breaks after install.

It usually comes up when an enterprise buyer asks to see your product's data next to their accounts, which is the native integration they asked for. You build the package, pass security review, publish the listing, and then the table runs in every customer org you sell to. Appnigma's marketplace apps offering is built for that ("Your product, inside Salesforce or HubSpot."). It covers a Salesforce managed package built around your product and customer workflows, plus security review preparation and responses. Admins who only need a selectable table inside a screen flow can skip to the Flow Data Table row below.

Updated October 2026. Checked against the Lightning Component Reference, the LWC Developer Guide, the Apex Developer Guide, the Named Credentials packaging guide and the Flow Data Table help page. The earlier version described the table as an admin feature, gave setup steps for a product screen that no longer exists, and named no limits. This update covers the four components Salesforce calls a data table, the limits that matter for a shipped product, and how to feed the table your own data from a managed package.

The four Salesforce components called a data table

Salesforce ships four components that render a data table, and only one belongs in a SaaS product's record page. The choice depends on who configures it and where it runs.

The two legacy rows point to the same place. The Aura datatable page says "For LWC development, use lightning-datatable," and the Visualforce to LWC mapping maps apex:dataTable to it too. If your package still ships a Visualforce table, the rebuild target is the LWC.

The Flow Data Table is the one vendors sometimes miss. From API version 65 it accepts Apex-defined data types as well as records, per its help page. That lets a packaged screen flow show rows your Apex built from your own API, which suits a guided step such as picking which of your projects to link to an opportunity. Namespaced fields need the namespace added to the source field name, the same page notes.

How lightning-datatable works

Three attributes set up the table, data, columns and key-field. The component reference is direct about the last one. "The key-field attribute is required for correct table behavior." It is also case-sensitive, so Id in the markup must match Id in every row.

<lightning-datatable
    key-field="Id"
    data={rows}
    columns={columns}
    onsave={handleSave}>
</lightning-datatable>

Two behaviors surprise teams coming from other table libraries. Sorting is your code, because the table only fires onsort. With paged data that means a new query, since sorting the loaded page sorts only what the user has scrolled past. Infinite loading with enable-infinite-loading and onloadmore fires 20px from the bottom by default, and the table needs a container with a set height to know where the bottom is.

Inline editing is per column with editable: true, and changes arrive in event.detail.draftValues. The reference states that "Inline editing is not supported for date and location fields." If you save edits through Apex, the inline editing guide says you must call notifyRecordUpdateAvailable(recordIds) so cached records and wires refresh.

The table doesn't care where rows come from. For Salesforce records the options are a cacheable Apex method, the GraphQL wire adapter or getListRecordsByName from lightning/uiListsApi. The older getListUi adapter is marked "for evaluation purposes only, not for production use" on its reference page. A wired Apex method needs @AuraEnabled(cacheable=true), and the wire guide says to call refreshApex() for fresh data "because Lightning Data Service doesn't manage data provisioned by Apex."

Limits to design around before customers install it

Salesforce documents several limits on lightning-datatable and the Flow Data Table. They matter more for a product installed in hundreds of orgs than for one internal page, because you can't tune each customer's data volume.

The size guidance exists because "Everything the lightning-datatable component displays loads in the browser on the user's computer," per the performance page. For a vendor, page size is a product decision, not a tuning step. Your smallest customer and your largest one see the same component, and the largest one decides whether it loads. Return the first 50 rows, fetch more on scroll, and cap the columns to what a rep reads on the record page. The rest belongs in your own app behind a link.

Does lightning-datatable work on mobile?

No. Salesforce states that lightning-datatable and lightning-tree-grid "aren't supported on mobile devices," per the datatable vs tree grid comparison. The Flow Data Table isn't compatible with mobile either, according to its help page.

The catch for a packaged component is that record pages support phone and desktop. The form factor configuration guide says that without <supportedFormFactors>, "the component supports the form factors that the page type supports." So a table with no declaration can appear on a phone record page where the component isn't supported. Declare Large only, or ship a phone layout and branch on @salesforce/client/formFactor, which returns Large, Medium or Small per the client form factor page.

Tree grid is the related choice for parent and child rows, such as an account with its subscriptions. The same comparison shows it lacks column sorting, inline editing and infinite scrolling. So pick it only when the hierarchy matters more than those three.

Stored rows or live API calls for your product's data

A table showing your product's data inside Salesforce can get its rows in three ways. Each moves the cost to a different place.

Live callouts have hard ceilings. The Apex callout limits page says a transaction can make up to 100 callouts, and "The default timeout is 10 seconds." The cumulative maximum is 120 seconds per transaction. For slow endpoints, a Continuation holds up to three callouts, its method can't do DML, and only one can be in progress on the client at a time.

Here is the arithmetic from those limits. A table that calls three of your endpoints one after another, each at the 10 second default, can keep a user waiting up to 30 seconds before it fails. That is well inside the 120 second cap, and still far too long for a record page. One endpoint shaped for the table, returning only the visible columns for one page of rows, is the design that holds up.

Salesforce Connect has its own trade. The Salesforce Connect Apex guide notes that "By default, external objects are read only," and Apex triggers and Apex managed sharing aren't available on them per the external object considerations. Synced objects suit data that customers report on or automate against. Live callouts suit data that changes by the minute, such as usage or ticket status. Appnigma's guide to data integration vs virtual integration covers the same choice at the pattern level.

Packaging a data table in a managed package

A packaged lightning-datatable component reaches customer record pages only if its config file sets isExposed to true and lists targets such as lightning__RecordPage, per the configuration file reference. Developers expose it, and admins then drag it onto pages in Lightning App Builder. A targetConfig can limit it to the objects your product supports.

Choose the exposed targets and design properties for the first release with care. The packaging guide says that once the component is in a published managed package, "the package developer can't remove configuration targets or a public (@api) property." Every target and design property becomes a long-term commitment to every installed org.

The Apex class that feeds a packaged data table needs four things handled before security review.

• Imports. The package's own component imports its Apex without a namespace prefix, per Import Apex Methods.
• Access. A public Apex controller in a managed package needs a permission set in the subscriber org, according to the Apex packaging considerations. Ship one with the package.
• Field security. "WITH SECURITY_ENFORCED isn't allowed in AppExchange packages," per Salesforce's CRUD and FLS guidance. Query with WITH USER_MODE instead.
• Credentials. "Named credentials aren't automatically added to packages," per Package Named Credentials. The external credential's principal is filled in after install through the Connect API, per the packaging guide.

A minimal controller for a synced object looks like this. The object and fields are placeholders for your own.

public with sharing class UsageTableController {
  @AuraEnabled(cacheable=true)
  public static List<Usage__c> getUsage(Id accountId) {
    return [SELECT Id, Name, Seats__c, Last_Active__c
      FROM Usage__c WHERE Account__c = :accountId
      WITH USER_MODE LIMIT 50];
  }
}

with sharing alone isn't enough. Salesforce's Secure Apex Classes page says the sharing keywords "don't enforce object-level and field-level security." For calling your API from packaged Apex, see Appnigma's guide to third-party APIs in an AppExchange app and the post on named and external credentials.

Mistakes that show up after customers install the table

Most data table problems in a managed package appear in customer orgs, not in your scratch org, because real orgs have more rows, more profiles and phones.

• Lowercase `id` in the rows. key-field="Id" with rows that carry id breaks selection and editing, because the match is case-sensitive.
• Returning every row. A table loaded with a customer's full history runs into the 1,000 row guidance on the first big account. Page it.
• Editable date columns. Date and location columns can't be edited inline, so plan a row action or a separate edit form.
• Stale rows after a save. Saving through Apex without notifyRecordUpdateAvailable or refreshApex leaves old values on screen.
• A missing principal. The callout fails in every org where no one filled in the external credential principal after install. Put that step in your install guide.
• Copying old samples. Some older Salesforce examples still use getListUi or WITH SECURITY_ENFORCED. Use the current replacements in packaged code.

Frequently Asked Questions

What is the difference between lightning-datatable and the Flow Data Table?

lightning-datatable is a developer component placed on Lightning pages. The Flow Data Table is configured by an admin inside a screen flow, shows up to 1,500 records and lets users select up to 200.

How many rows can lightning-datatable show?

No hard cap is documented. Salesforce's testing shows performance is best at up to 1,000 rows and 5 columns, so page the data.

Can a lightning-datatable show data from an external API?

Yes. An @AuraEnabled Apex method calls your API through a packaged Named Credential and returns rows, within 100 callouts and 120 seconds per transaction.

Can Appnigma build a Salesforce app that shows our product's data on record pages?

Yes. Appnigma's marketplace apps offering delivers a Salesforce managed package built around your product and customer workflows, with security review preparation and responses. Built by ex-Salesforce engineers.

Related Articles

• Integrating third-party APIs with your Salesforce AppExchange app
• Salesforce named credentials and external credentials
• Types of integration in Salesforce
• LWC licensing in managed packages
• Building a native Salesforce app
• Security review for a Salesforce managed package

Sources

1. Salesforce Developers, Component Reference, Datatable (lightning-datatable)
2. Salesforce Developers, Component Reference, Datatable (lightning:datatable)
3. Salesforce Developers, Standard Visualforce Components and Base Lightning Web Components Side by Side
4. Salesforce Help, Data Table Screen Input Component
5. Salesforce Developers, LWC Developer Guide, Display Data in a Table with Inline Editing
6. Salesforce Developers, LWC Developer Guide, getListUi (Deprecated)
7. Salesforce Developers, LWC Developer Guide, Wire Apex Methods to Lightning Web Components
8. Salesforce Developers, LWC Developer Guide, Improve Datatable Performance
9. Salesforce Developers, LWC Developer Guide, Compare lightning-datatable and lightning-tree-grid
10. Salesforce Developers, Apex Developer Guide, Callout Limits and Limitations
11. Salesforce Developers, LWC Developer Guide, Continuation Limits
12. Salesforce Developers, Apex Developer Guide, Salesforce Connect
13. Salesforce Developers, Apex Developer Guide, Apex Considerations for Salesforce Connect External Objects
14. Salesforce Developers, LWC Developer Guide, XML Configuration File Elements
15. Salesforce Developers, LWC Developer Guide, Add Components to Managed Packages
16. Salesforce Developers, LWC Developer Guide, Import Apex Methods
17. Salesforce Developers, Aura Developer Guide, Apex Class Considerations for Packages
18. Salesforce Developers, Secure Coding Guide, Protect Your Application from CRUD/FLS Vulnerabilities
19. Salesforce Developers, Named Credentials, Package Named Credentials
20. Salesforce Developers, Named Credentials Packaging Guide
21. Salesforce Developers, LWC Developer Guide, Secure Apex Classes