Switching from AGrid
Install Rowhouse beside AGrid, rebuild the configurations people use most, run both, and keep AGrid for the views that reach records no lookup connects.
- You depend on Intelligent Related Lists: grandchild, sibling or wholly unrelated records, linked by conditions rather than a lookup. A Rowhouse child table needs a lookup or master-detail field, and cannot follow a virtual relationship.
- Two people often edit the same record at once, and you rely on AGrid’s Record Collision Action to review before saving. In Rowhouse the last save wins; records are not locked.
- You use Kanban, chart, card or split views on the same configuration. Rowhouse is a grid and nothing else, on purpose.
- You prepaid a multi-year AGrid term for its discount. Switch at the end of it, not in the middle.
Where AGrid keeps your grids
As records in sixteen packaged custom objects: configurations, configuration groups, formula columns, conditional rendering, saved views and each user’s personalizations. AGrid moves configurations between orgs as a JSON file through AGrid itself, which Rowhouse does not import. Users’ saved views and personal settings do not come across to Rowhouse either, so each grid is rebuilt.
AGrid’s concepts, in Rowhouse
| In AGrid | In Rowhouse |
|---|---|
| An AGrid Configuration, built in the wizard | A Grid Configuration and its Grid Columns, built on the Grid Admin tab |
| Related List mode (a Parent Field Name) | A grid with a Record Page Field: an editable related list on the record page |
| Admin filters | Grid Filters, shown to users as locked chips |
| Group By, three levels, with summaries | Grouping up to three levels, with subtotals and a Total row |
| Conditional Rendering: highlighting rows and columns | Display rules on a cell or a whole row — sixteen looks, explained in a Display Key |
| AGrid Formula columns, up to five | Formula columns in Salesforce’s own formula syntax, up to ten per grid, counting formula display rules |
| Row and list actions: a Flow, LWC or Aura component | Grid Actions: a screen flow, an autolaunched flow, invocable Apex or a quick action |
What you rebuild
- Every configuration: its columns and their flags, admin filters, three-level grouping and its summaries, conditional rendering, and its row and list actions.
- AGrid Formula columns, rewritten in Salesforce formula syntax as Rowhouse formula columns. Check each result against AGrid’s, since AGrid works out its formulas itself.
- Actions that launch a Lightning Web Component or an Aura component. A Rowhouse action runs a screen flow, an autolaunched flow, invocable Apex or a quick action, so each needs one of those.
- Every user’s saved views and personalizations: sharing, column widths, text wrap, grouping, charts and their own highlighting rules. These do not come across.
What you lose, for now
- Flow screen component (AGrid offers part of it)Coming soon
- Experience CloudComing soon
- AGrid’s configuration export writes your configurations to one JSON file. Rowhouse cannot read it, but it is a checklist of what to rebuild.
- Rowhouse formula columns live in the grid’s own configuration, so replacing AGrid Formula columns needs no new fields on the object.
- Rowhouse grids are metadata, so you can rebuild once in a sandbox and deploy to production in a change set.
The Grid Admin tab
Every grid in the org, on one page
Rebuilt grids appear here with their object and columns, counted by object, ready to edit, clone or archive.
One editor for each grid
Columns, display rules, filters, actions and child tables on six tabs, checked as you type with the same code the grid uses.
Seven steps, and nothing removed until step seven
Inventory
List every grid built in AGrid, who uses it and which page it sits on.
Install alongside
Rowhouse installs next to the grid you have. Nothing is removed, and nobody loses a grid while you work.
Rebuild each grid
On the Grid Admin tab, one grid at a time, mapping each concept as the table above shows.
Test, then deploy
Build in a sandbox and move the grids to production in a change set, because they are metadata.
Run both
Put the Rowhouse grid beside the old one until the people who use it are sure.
Re-point pages
Swap the old component for the Rowhouse grid on each Lightning page.
Remove at renewal
Uninstall AGrid when its license comes up, not before.
Sort the configurations before you rebuild
Run AGrid’s configuration export and use the file as your inventory. Then split it in two. Configurations that use an Intelligent Related List with no lookup behind it stay on AGrid. Everything else is a candidate: rebuild the configurations people open every day, put each beside its AGrid version on the same page, and tell users their saved views will need setting up again. Whatever nobody misses after a month does not need rebuilding at all.
AGrid facts checked 2026-10-07, from its vendor’s own published documentation.
Switching from AGrid: questions
Can I import AGrid’s export file into Rowhouse?
No. AGrid’s JSON file moves configurations between orgs that run AGrid, and Rowhouse has no importer. Use the file as a list of what to rebuild on Rowhouse’s Grid Admin tab, which checks every setting as you type.
Do my AGrid Formula columns need new fields on the object?
No. A Rowhouse formula column lives in the grid’s configuration and is written in Salesforce’s formula syntax, up to ten per grid. Rewrite each one, then check its result against AGrid’s.
What happens to records edited in AGrid?
Nothing. Both grids edit the same Salesforce records in your org. Your data does not move; the grid configuration is what you rebuild.
Three things you can verify without asking us
Install it alongside. Nothing to remove until you are sure.
Rebuild one grid, run both, and switch when the new one has earned it.