Switching from GridBuddy
Install Rowhouse in your org, rebuild the grids people use most from your GridBuddy Connect account, run both, and keep GridBuddy seats for the few who need one grid across orgs or systems.
- One grid genuinely spans several Salesforce orgs, or Salesforce and Dynamics 365, Zendesk or SAP. That is what GridBuddy Connect is built for. Rowhouse reads and writes the org it is installed in, and makes no callouts.
- Your team has built GridBuddy JavaScript or CSS extensions and custom actions, and has people who maintain them. They do not port.
- You need grids on an Experience Cloud site today. GridBuddy carries the Community Builder badge; Rowhouse does not run on Experience Cloud sites.
- GridBuddy is a small line in a multi-year Validity agreement that covers several products, and unpicking it before that agreement ends is not worth the time.
Where GridBuddy keeps your grids
In your GridBuddy Connect account, on Validity’s own platform, not in your Salesforce org: grids, tabbed workspaces, actions, extensions, grid users and groups are all defined and stored there. It is not Salesforce metadata, so there is nothing to deploy or carry across, and each grid is rebuilt.
GridBuddy’s concepts, in Rowhouse
| In GridBuddy | In Rowhouse |
|---|---|
| A grid built in the Grid Wizard | A Grid Configuration and its Grid Columns, built on the Grid Admin tab |
| Admin filters set in the Grid Wizard | Grid Filters, shown to users as locked chips |
| Conditional formatting | Display rules — sixteen looks, explained in a Display Key |
| Grouping with subtotals, and summary formulas | Grouping up to three levels, with subtotals and a Total row |
| Record-level and batch actions | Grid Actions on a row or a selection: a screen flow, an autolaunched flow, invocable Apex or a quick action |
| Related-object sections in a multi-object grid | Child tables under each row, up to three levels, where a lookup or master-detail field links the objects |
| An embedded grid: the Embeddable URL pasted into the GridBuddy Connect component | The Rowhouse grid component, naming one grid’s API name, on an App, Record or Home page |
What you rebuild
- Every grid, tabbed workspace and action in the GridBuddy Connect account, by hand. None of it exists as deployable metadata.
- Each user’s own grids and filters. User-defined grids multiply the work, so list who has built their own before you start.
- Custom JavaScript and CSS extensions and custom actions. They do not port: rebuild the actions that still matter as Grid Actions, and drop the rest.
- Every embedded grid on every record page and Lightning tab, found and replaced by hand.
What you lose, for now
- Experience CloudComing soon
- Rowhouse grids are metadata, so you can rebuild once in a sandbox and deploy to production in a change set.
- If you still run the original GridBuddy package, Validity’s own path to GridBuddy Connect is a rebuild too: export, import, then replace every component by hand. That is the moment to compare.
- Keep GridBuddy Connect seats for the few people who need a grid across systems, and move everyone else.
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 GridBuddy, 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 GridBuddy when its license comes up, not before.
Take the inventory from the GridBuddy Connect account
Your grids are not in the org, so Setup cannot list them. Sign in to the GridBuddy Connect account and write down every grid, tabbed workspace and user-defined grid, who opens it and which page it is embedded on. On the Salesforce side, look for the GridBuddy Connect component on record pages and Lightning tabs: each one holds an Embeddable URL that names its grid. Rebuild the grids people open every day, put each beside its GridBuddy version, and leave the cross-system grids where they are.
GridBuddy facts checked 2026-10-07, from its vendor’s own published documentation.
Switching from GridBuddy: questions
Can I export my GridBuddy grids into Rowhouse?
No. GridBuddy Connect keeps grids in its own account, in its own format, and Rowhouse has no importer. Each grid is rebuilt on Rowhouse’s Grid Admin tab, which checks every setting as you type.
Can GridBuddy Connect and Rowhouse run in the same org?
Yes. They are separate packages with separate configuration, and installing Rowhouse removes nothing. Keep GridBuddy Connect for the people who need a grid across orgs or systems, and move everyone else.
What happens to records edited in GridBuddy?
Nothing. GridBuddy and Rowhouse edit the same Salesforce records. Rowhouse does it inside the org, as each user, through Salesforce’s object, field and sharing security. 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.