Switching grids, without a cut-over
Rowhouse installs beside the grid you have. Nothing is removed and nobody loses a grid while you rebuild — so the switch happens one grid at a time, on your schedule, and the old license lapses at renewal.
Why the switch is gentle
Two grids can run in the same org: they are separate packages with separate configuration, and both edit the same records through the same Salesforce security. So there is no cut-over date. Rebuild the grid a team uses most, put it beside the old one, and let the people who use it decide when it has earned the switch.
Why the rebuild is worth doing once
Every Rowhouse grid is Custom Metadata. Rebuild it once in a sandbox, deploy it to production in a change set, keep it in source control. For most teams that is the first time their grid configuration has followed the same release path as the rest of the org.
How concepts map
| In most paid grids | In Rowhouse |
|---|---|
| A view or grid definition | A Grid Configuration and its Grid Columns |
| Conditional formatting | Display rules, with a Display Key |
| An admin filter | A Grid Filter, locked for users |
| A button or custom action | A Grid Action: screen flow, autolaunched flow, invocable Apex or quick action |
| A sub-grid or related list | A child table under each row |
| A summary row | A subtotal, a Total row, or a child total column |
See it as your users will
Where your rebuilt grids live
Every grid in the org on one page of the Grid Admin tab, 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.
Configuration you can deploy
Each grid is a set of Custom Metadata records that point at it by name: build in a sandbox, then move them together in one change set.
Six playbooks, one per paid grid
Each starts with when to stay, then where that product keeps your configuration — which decides how much you rebuild.
Conga Grid
Configuration lives as records in its own packaged objects.
Read the playbook →Switching fromGridBuddy
Configuration lives in the vendor’s cloud.
Read the playbook →Switching fromGrid Mate
Configuration lives as records in its own packaged objects.
Read the playbook →Switching fromMashmatrix Sheet
Configuration lives as records in its own packaged objects.
Read the playbook →Switching fromRavenApps Grids
Configuration lives as records in its own packaged objects.
Read the playbook →Switching fromAGrid
Configuration lives as records in its own packaged objects.
Read the playbook →Switching grids, without a cut-over: questions
Can I import my existing grid configuration?
No. Every paid grid keeps its configuration in its own format — records in its own objects, JSON in page properties, or an account on the vendor’s platform — and none of it imports. Each grid is rebuilt on Rowhouse’s Grid Admin tab, which checks every setting as you type.
Does any record data have to move?
No. Every grid edits the same Salesforce records. Only the grid configuration is rebuilt.
When should I not switch?
When you rely on something Rowhouse does not do: one flat grid across unrelated objects, Flow screen components or Experience Cloud sites. Each playbook lists the reasons specific to that product first.
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.