Go beyond standard components with configurable tables, boards, calendars, and more. Your team controls the experience. We maintain the component code.
Same org, same deals, same drag.
Read-only in Winter '27: users can't drag cards between stages.
The card moves, the stage is saved, both totals recount.
Configuration happens in the builders your admins already use. Code goes through your developers. The gap shows on every change after launch.

Configure Salesforce's own components in Flow Builder and Lightning App Builder, at no extra cost. Salesforce maintains them, and your team maintains the flows and pages built on them.

Configure tables, boards, calendars and more in the same builders, by hand or with your AI assistant. Your team maintains the configuration, and we maintain the component code.
Build exactly the screen you need as a Lightning web component, with Apex only when the data or logic calls for it. Your team reviews, tests, deploys and maintains every line, including what an AI assistant drafts.
What does the code path cost over five years? Open the calculator →
Sales managers review open opportunities inside a screen flow. Same org, same records, three ways to build it. We count steps, not hours: your timings depend on your team.
List open opportunities, let managers edit Amount and Next Step in place, save.
Managers also want to edit Close Date and Stage, see deals grouped by stage with subtotals, and export the list.
Same flow, same open deals, same columns.
First request: all three deliver. Second request: the standard table stops at documented limits; custom code and Avonni both deliver, in different ways.
Get Records, a Data Table and Update Records in Flow Builder. Amount and Next Step are editable field types.
An assistant drafts a Lightning web component, reading data through GraphQL or an Apex controller. A developer reviews it, adds tests and deploys it from a sandbox.
The Avonni Data Table on the screen, with the object, filters and columns picked in the Component Builder. No Get Records step. Edited rows come out of the component for an Update Records step.
Not in the component today. Date and Picklist aren't among its editable field types, and grouping, subtotals and export aren't offered. The request moves to code or to a component.
A code change: new editing cells, grouping, totals and an export. The assistant drafts it, a developer reviews it, tests run again, and it ships through your deployment process.
Settings: two more columns marked editable, Group by set to Stage with a sum on Amount, an Export action in the header. Save the flow as a new version.
An admin edits the flow and activates a new version.
It depends on the build. If the developer exposed the setting in the builder, an admin changes it. If not, it's a code change and a deploy.
An admin edits the component settings and activates a new version.
Test the flow in a sandbox and debug it in Flow Builder.
Jest tests for the component, recommended by Salesforce. If there is Apex, tests must cover at least 75% of it before it deploys to production. A review of AI-generated code, which Salesforce asks for before any deploy.
Test the flow in a sandbox, like any flow. Try each new Avonni version in a sandbox before you upgrade.
Salesforce maintains the component. You maintain the flow.
Your team maintains every line, through three Salesforce releases a year, including the code your assistant wrote.
We maintain the component code. You maintain the flow, the configuration and your licenses.
Sources, checked October 2026 (Winter '27): Flow Data Table · Kanban Board (Beta) · Apex code coverage · LWC data guidelines · Jest testing · Agentforce Vibes trust and verification
Four Salesforce surfaces, filmed in real orgs.
The Flow Data Table searches, sorts and edits text, number, currency and similar fields in place. It shows up to 1,500 records, lets users select up to 200, and isn't compatible with mobile devices.
The table runs its own query, no Get Records step. Grouped rows with subtotals, a filter panel, row actions, export, and in-place editing of dates and picklists are settings on the component.
The filter panel of the same table: two values ticked, the list narrows to 66 deals.
A matrix report builds this view in the Reports tab, and the Report Chart component brings its chart onto a page. Dynamic Related Lists add filtered, sorted record lists.
A pivot table on the page itself, fed by a query: regions by quarter, with row totals, column totals and a grand total, sorted in place.
Closed won revenue, sorted by region on a Lightning page.
Experience Builder ships components for records, lists and content, styled by your site's theme.
Orders, purchase orders and delivery status in one table, fed by a query and styled by the same site theme.

Northwind's partner hub, a real Experience site.
lightning-datatable renders the rows you pass it. Lightning Data Service or GraphQL can fetch them without Apex. Grouping, filters, search and export are code you write and test.
avonni-dd-datatable-group-by takes the query, the grouping, the filters and the search as attributes. No Apex class of yours behind it.

We build the editable table twice, with the Salesforce Data Table and the Avonni Data Table, then add real requirements one by one.
The same layer in Screen Flows, on Lightning pages and on Experience sites.
Colors and fonts live in the builder. Experience sites pass on their theme.
Custom Branding →Claude or any MCP client finds, reads and configures components. You can open the result in the builder.
Agent Skills →We considered building our own components or delving into our own LWCs, but Avonni's value proposition was unbeatable. A stellar user experience without writing a single line of code.
Admins work in builders they know. Flow Builder, Lightning App Builder and Experience Builder.
Developers keep code for the business logic. In their own components, the table is one tag and a query.
Users get screens that fit the work. Drag a deal to its next stage or sign off a job inside the flow.
Avonni isn't the answer to every screen. Here is how we would decide.
When the standard component covers today's screen and the next request you can see coming. No package, no extra license, supported by Salesforce.
When the interaction is specific to your business and no component offers it, when you have developers and a deployment process to own it, or when you want no third-party dependency at all.
When tables, boards, calendars or maps come back across many screens, when requests outgrow the standard components, and when admins need to change screens after launch without waiting on a developer.
Straight answers, taken from our security documentation.
Queries run as the viewing user, with your field-level security, object permissions and sharing rules. In Flow, a query can opt into system mode for reads, only if you turn it on.
Nothing goes to an Avonni service, and the package does not call home at runtime. One exception: the Leaflet map loads its tiles from OpenStreetMap, a site you add as trusted.
Updates are never pushed to your org. You choose the version and try it in a sandbox first.
You configure and style the components. The code inside them stays in the package, and we maintain it.
Uninstalling removes Avonni's component definitions, so export them first. Your records are not touched.
Avonni removes the component code, not the work. Your team still designs the screen, configures it, tests it in a sandbox, deploys the flow or page, manages licenses and chooses when to upgrade.
Install it in a sandbox: free, with unlimited users and no time limit. Or walk through your use case with our team.
In production, your first 10 user licenses are free, with no time limit.