Why Avonni

Build the Salesforce screens you need. Keep improving them without custom code.

Go beyond standard components with configurable tables, boards, calendars, and more. Your team controls the experience. We maintain the component code.

85+
components
4
Salesforce surfaces
50+
interactions

Same org, same deals, same drag.

Salesforce · Kanban Board (Beta)

Read-only in Winter '27: users can't drag cards between stages.

Avonni · Kanban

The card moves, the stage is saved, both totals recount.

Three ways to build a screen

Three ways to build. Different responsibilities.

Configuration happens in the builders your admins already use. Code goes through your developers. The gap shows on every change after launch.

The standard Salesforce Flow Data Table showing open deals: plain columns, a search bar and row checkboxes
Standard components

Configuration, supported by Salesforce.

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.

Where Avonni fits
The Avonni Data Table on the same open deals: colored lead source badges, probability bars, search, export and row actions
Avonni components

Configuration that goes further.

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.

Custom code

Code. Anything goes, and you own it.

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 →

One use case, start to finish

A deal review screen, from the first request to the next one.

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.

First request

List open opportunities, let managers edit Amount and Next Step in place, save.

After launch

Managers also want to edit Close Date and Stage, see deals grouped by stage with subtotals, and export the list.

The standard Salesforce Flow Data Table on the same open deals, in the same screen flow: plain columns, a search bar and row checkboxes

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.

The next request, in the Avonni builder.

The same Data Table, reopened in the Component Builder. Four settings, then a new flow version.

1

Make Close Date and Stage editable. Turn on Editable for both columns. Stage edits as a picklist, with the Combobox type.

2

Group by Stage. Set Group By to Stage. Every stage becomes a group with its row count.

3

Sum the Amount column. On Amount, set Summarize By to Sum. Each group shows its subtotal.

4

Add an Export action. A header action of type Export To, with CSV and Excel as file formats.

✓

Save as a new version. In the flow, managers edit dates and stages in place, collapse groups to read subtotals, and export the list.

Recorded in a Salesforce org with Avonni Flow Screen Components.

Try the same change on your own deals.

Step
Standard components
Custom code, AI-assisted
Avonni, by hand or with AI
First build
Standard components

Get Records, a Data Table and Update Records in Flow Builder. Amount and Next Step are editable field types.

Custom code, AI-assisted

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.

Avonni, by hand or with AI

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.

The next request
Standard components

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.

Custom code, AI-assisted

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.

Avonni, by hand or with AI

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.

Small changes
Standard components

An admin edits the flow and activates a new version.

Custom code, AI-assisted

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.

Avonni, by hand or with AI

An admin edits the component settings and activates a new version.

Testing
Standard components

Test the flow in a sandbox and debug it in Flow Builder.

Custom code, AI-assisted

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.

Avonni, by hand or with AI

Test the flow in a sandbox, like any flow. Try each new Avonni version in a sandbox before you upgrade.

Who maintains it
Standard components

Salesforce maintains the component. You maintain the flow.

Custom code, AI-assisted

Your team maintains every line, through three Salesforce releases a year, including the code your assistant wrote.

Avonni, by hand or with AI

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

Compare both tables line by line →

Side by side

Same need. Standard, then Avonni.

Four Salesforce surfaces, filmed in real orgs.

In a screen flow

A table your users can work in

Standard

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.

With Avonni

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.

Compare both tables line by line →

The filter panel of the same table: two values ticked, the list narrows to 66 deals.

On a Lightning page

Revenue by region and quarter, on the page

Standard

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.

With Avonni

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.

Explore the Pivot Table →

Closed won revenue, sorted by region on a Lightning page.

On an Experience site

A partner portal that does real work

Standard

Experience Builder ships components for records, lists and content, styled by your site's theme.

With Avonni

Orders, purchase orders and delivery status in one table, fed by a query and styled by the same site theme.

See client portals →
Northwind partner portal on Salesforce Experience Cloud: an Avonni Data Table of orders with purchase order PDFs, delivery progress rings and status badges

Northwind's partner hub, a real Experience site.

In your own code

One tag instead of a component and a class

Standard

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.

With Avonni

avonni-dd-datatable-group-by takes the query, the grouping, the filters and the search as attributes. No Apex class of yours behind it.

Compare with building it yourself →
expenseApprovals.html
<template>
<avonni-dd-datatable-group-by
header-title="Expense approvals"
query={expenses}
columns={columns}
group-by-attributes={groupBy}
filters={filters}
search-fields={searchFields}
header-actions={headerActions}
onheaderactionclick={handleApprove}>
</avonni-dd-datatable-group-by>
</template>
Native vs Avonni Data Table comparison video
▶
Play here
6:55
See the test

Same flow, same data, two tables: watch the comparison

We build the editable table twice, with the Salesforce Data Table and the Avonni Data Table, then add real requirements one by one.

On top of every component

What comes with every Avonni component.

The same layer in Screen Flows, on Lightning pages and on Experience sites.

Data without Apex

Pick an object, fields and conditions. It runs as the viewing user.

Data Sources →

Actions without code

50+ interactions, wired to clicks, drops and row actions.

Interactions →

Your brand, set once

Colors and fonts live in the builder. Experience sites pass on their theme.

Custom Branding →
list_components
get_component_docs
list_interactions
get_interaction_docs

Built with your AI assistant

Claude or any MCP client finds, reads and configures components. You can open the result in the builder.

Agent Skills →
For your team

What changes for the people who build and use it.

“
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.
Tyler Teachman · Hitachi High Tech America
Admins

Admins work in builders they know. Flow Builder, Lightning App Builder and Experience Builder.

Developers

Developers keep code for the business logic. In their own components, the table is one tag and a query.

Your users

Users get screens that fit the work. Drag a deal to its next stage or sign off a job inside the flow.

Choosing honestly

When standard or custom is the better call.

Avonni isn't the answer to every screen. Here is how we would decide.

Stay with standard

When the standard component covers today's screen and the next request you can see coming. No package, no extra license, supported by Salesforce.

Write custom code

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.

Use Avonni

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.

Before you install

The questions your architect will ask.

Straight answers, taken from our security documentation.

Runs inside your org

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.

Your data stays in Salesforce

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.

Upgrades on your schedule

Updates are never pushed to your org. You choose the version and try it in a sandbox first.

A managed package

You configure and style the components. The code inside them stays in the package, and we maintain it.

Leaving is clean

Uninstalling removes Avonni's component definitions, so export them first. Your records are not touched.

You still own the build

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.

Read the security details →

Try it on a screen you need this month.

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.