Administration
Build the grids your users see on one tab in Salesforce, without code and without the Setup round trip of one record at a time. Every grid is Custom Metadata, so it follows the same release path as the rest of your org.
Why it matters
Most grids are configured in the vendor’s own screens, stored in the vendor’s own records, and moved between orgs with the vendor’s own tools. Rowhouse’s configuration is Salesforce metadata, authored in Setup or on a tab in Salesforce, which deploys through the release pipeline you already have: built and tested in a sandbox, reviewed, deployed, kept in source control.
Three permission sets
The user permission set is required for everyone who uses a grid, admins included. The admin permission set adds the Grid Admin tab and the gear, for whoever builds grids. The diagnostics permission set is for whoever is investigating a problem: assign it, then remove it. None of them grants access to your org’s own records — what a user sees and changes is what their profile, permission sets and sharing already allow.
See it as your users will
Every grid in the org, on one page
The Grids page lists every grid with its object and columns, with counts by object, the grids that log every change and the grids with child tables.
How a grid is put together
One component on a Lightning page, one grid configuration it names, and the records that configure it — all Salesforce metadata, all read as the person using the grid.
The records behind a grid
A grid is one Grid Configuration and the records that point to it: columns, display rules, filters, actions and child tables. A seventh type holds the settings for Rowhouse as a whole.
How the records link
Every record points at its grid by name, which is why a grid moves between orgs in one change set: take the configuration and everything that points to it, together.
When a setting cannot work
A setting that cannot work is skipped and the grid still opens. Admins with the diagnostics permission set see a line under the grid’s title that opens into every skipped setting and why.
In detail
The Grid Admin tab
Every grid in the org on one page, with counts by object, the grids that log every change and the grids with child tables. Search by title or API name; Edit, Clone or Archive from each row’s menu. Use By object to find every grid built on Opportunity before you change a picklist.
One editor, six tabs, checked as you type
Grid, Columns, Display rules, Filters, Actions and Child tables. A moment after each change the server checks the draft with the same code the grid itself uses: errors keep Save grey, and warnings list what the grid would leave out. A column’s Field list holds the object’s fields and its lookups: choose Account > and the account’s fields open under it, up to five lookups deep. The matching page of the Grid Guide sits beside each tab.
What users may do, grid by grid
Each grid has its own switches for inline editing, Create records with New, import, export, delete and logging. New is ticked on a new grid; users still need create permission on the object, and only the grid’s editable columns are written to a new record.
The gear: change a grid where it is
Grid admins open a grid’s settings from a gear beside its Refresh button, in the same editor, and the grid reloads with the change — raise a display rule’s threshold while looking at the data it colors.
New grid, Clone, Archive and Restore
Clone copies a working grid with its columns, rules, filters, actions and child tables. Archive takes a grid out of use without deleting anything; Restore brings it back. Deleting happens in Setup, and the Grid Admin tab lists the records in the order to delete them.
Configuration as metadata
Seven Custom Metadata types hold every setting. Build in a sandbox, add the records to a change set or a deployment, keep them in source control. Every admin-editable setting belongs to your org, so an upgrade cannot overwrite your configuration. Admins can also build in Setup, one record at a time, and every field has help text.
A typo costs one color, not the grid
A setting that cannot work is skipped with a warning, and the grid still opens for everyone. Filters are the exception: a filter that cannot work stops the grid rather than guess, because a guess could show records it should not.
Diagnostics, with no data leaving the org
Holders of the Diagnostics permission set see every skipped setting above the grid, and timings and row counts in the browser console — never record data. Nothing is sent anywhere; a support engineer asks for the lines.
The Grid Guide, inside Salesforce
The documentation is a tab in the org: a user guide, five tutorials, the configuration reference, limits and FAQ. It opens from the ? on every grid and always matches the version you installed.
Where it stops
Each limit is there for a reason you can see: how much a browser draws smoothly, or how much Salesforce lets one transaction do. Every limit, and the benchmark →
- Frozen columns0 to 5
- Formulas per grid (columns and rules together)10
- Child total columns per grid5
- Saving a grid needs Customize Application as well as the Rowhouse admin permission set. Rowhouse cannot grant it; Salesforce admins have it.
- Rowhouse cannot delete a grid. Only Setup can delete Custom Metadata records, and deleted records cannot be restored.
- Before the package can be uninstalled, its Custom Metadata records — your grids — must be deleted, as with any package whose configuration lives in Custom Metadata.
Against the paid grids
Administration: questions
Do I need a developer to build a grid?
No. Grids are built on the Grid Admin tab or in Setup, with no code. The Grid Guide walks you through an Account Directory in about ten minutes.
How do I move a grid from a sandbox to production?
Add the grid’s Custom Metadata records — the configuration and every record that points to it — to an outbound change set or a deployment, together. A child table also needs its child grid in the target org. The Lightning page deploys like any other.
Who can build grids?
Holders of the Rowhouse admin permission set, assigned with the user permission set, who also have Salesforce’s Customize Application permission. Without Customize Application the Grid Admin tab still lists and opens grids, and Save stays grey with the reason.
Can an upgrade overwrite my grids?
No. Rowhouse ships no configuration records, and every setting an admin edits belongs to your org, so an upgrade has nothing of yours to replace.
Three things you can verify without asking us
Free. Not freemium, not a trial, not a tier.
Install it, assign the permission sets, build your first grid on the Grid Admin tab. Everything else is in the Grid Guide inside the app.