Switching from RavenApps Grids
Install Rowhouse beside RavenApps Grids, rebuild the grids people use most from their Grid records, run both, and time the change to your renewal date, because RavenApps seats cannot be reduced mid-term.
- Your grids join unrelated objects, passing field values from the page’s record into a related grid. Rowhouse shows one object per grid, with fields of related records and child tables where a lookup or master-detail field links them, and not otherwise.
- You need grids on Experience Cloud pages for portal users today. Rowhouse does not run on Experience Cloud sites.
- Users edit rich text in the cell. Rowhouse shows rich text but does not edit it.
Where RavenApps Grids keeps your grids
Each grid is a record on a RavenApps custom object holding a SOQL query plus JSON for its columns, filters, sorts and summaries, written with RavenApps’ own column types such as ra_picklist2 and ra_relatedList. There is no export to a neutral format, and each grid is placed on a page by its Grid id, so every page that carries one is edited too.
RavenApps Grids’ concepts, in Rowhouse
| In RavenApps Grids | In Rowhouse |
|---|---|
| A Grid record: a SOQL query plus JSON columns | A Grid Configuration and its Grid Columns, chosen from lists on the Grid Admin tab |
| Filters in the query, and quick filters | Grid Filters for the admin’s conditions, shown as locked chips, plus each user’s column filters |
| Conditional formatting: a formula field returning SLDS classes | Display rules: a test and a look, with no new field on the object |
| Summaries above the grid | A Subtotal on a column, a Total row, and grouping up to three levels |
| Editable parent fields | A related record’s field as a column, such as Account.Name, edited in place |
| Related Grids: grids within a grid | Child tables under each row, up to three levels, linked by a lookup or master-detail field |
| Invoke Flow on a row, the header or a selection | Grid Actions on a row or a selection: a screen flow, an autolaunched flow, invocable Apex or a quick action |
| The Grids component, placed by Grid id | The Rowhouse grid component, naming one grid’s API name |
What you rebuild
- Every Grid record: its query’s object, fields, conditions and sort, and its JSON columns, filters and summaries, rebuilt as a Grid Configuration with its columns, filters and subtotals.
- Every page that carries a grid. Each Grids component, placed by its Grid id, is swapped for the Rowhouse grid component.
- Users’ own Grid Views, which are stored as more Grid records. Rowhouse keeps each user’s layout, but has no named, shared views.
- Each conditional-formatting formula field. Rebuild it as a display rule, then delete the field, or it stays in the org after RavenApps Grids is uninstalled.
What you lose, for now
- Experience CloudComing soon
- AI features (RavenApps Grids offers part of it)Coming soon
- Grids renews automatically unless cancelled 30 days before the renewal date, and seats cannot be reduced mid-term. Rebuild before then, and give notice in time.
- Rowhouse is a separate package, so it runs beside Grids Pro. RavenApps’ rule that its Free and Pro editions cannot share an org does not apply to it.
- Each Grid record’s SOQL query is a precise brief: the object, fields, conditions and sort are all written down to rebuild from.
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 RavenApps Grids, 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 RavenApps Grids when its license comes up, not before.
Rebuild from the Grid records
List every Grid record, including the Grid Views users have saved, and note which page each Grid id is placed on. The query in each record is the brief for its rebuild: the object becomes the grid’s object, the selected fields its columns, the conditions its Grid Filters, and the order its default sort. A parent field read through a lookup becomes a column of its own, such as Account.Name, up to five lookups away, and it can be edited. Rebuild the grids people open every day, put each beside its RavenApps version, and keep the cross-object and Experience Cloud grids where they are.
RavenApps Grids facts checked 2026-10-07, from its vendor’s own published documentation; documentary only, since RavenApps’ terms bar competitor access and benchmarking.
Switching from RavenApps Grids: questions
Can I paste my RavenApps SOQL and JSON into Rowhouse?
No. Rowhouse is not configured with SOQL or JSON, and it has no importer. Each grid is rebuilt on the Grid Admin tab by choosing its object, columns, filters and rules, and the tab checks every setting as you type.
Why does this page not compare speed with RavenApps Grids?
Because RavenApps’ terms bar competitors from accessing the product or benchmarking it. Everything here comes from RavenApps’ published user guide, release notes and terms, and nothing was installed or tested.
What happens to records edited in RavenApps Grids?
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.