Security and audit trail
A grid can show and change a great deal of data quickly, so it should never see more than the person using it. Rowhouse reads and writes as the user, re-checks everything on the server, sends nothing out of the org, and can keep a log of every change it makes.
Why it matters
A grid is a fast way to change a lot of records, which makes it a fast way to make a lot of mistakes or to see what you should not. Rowhouse is built so that the grid is never the weak link: the access decision is Salesforce’s, made on the server, every time.
How a change is checked
In order: the Rowhouse permission set, object access, field-level security, sharing, the grid’s own configuration read on the server — which columns are editable, whether import or delete is allowed — and then your org’s own validation rules, triggers and flows.
Reading the log
Grid Edit Logs is a tab in the Rowhouse app, with a list view of every entry: when, who, what kind of change, the record, the field, the old and new value, and the Save Id. Reports are enabled on the object, so the log can feed any report or dashboard you already use.
See it as your users will
An audit trail in the same transaction
Edits, an Update field and an import each write their entries to the Grid Edit Log alongside the change itself. One save’s entries share a Save Id, so they read as one.
Four conditions for an editable cell
The grid’s configuration, the column, your object and field permissions, and the field itself all have to allow it. The server checks again on every save.
A save from the grid is an ordinary save
Batches of 200, each its own transaction, through your validation rules, triggers and flows — and through Salesforce’s own object, field and sharing security, as you.
In detail
Everything runs as the user
Every Rowhouse read and write runs in user mode, through Salesforce’s own object, field and sharing security, and every Apex class runs with sharing. A save from the grid is an ordinary save: your validation rules, triggers and flows run as usual.
The browser is never trusted
The browser sends a grid’s name, never a list of fields or an object; the server decides what is read and written. Every field in a save must be an editable column of that grid, every record Id must belong to the grid’s object, and search terms and filter values are bound into queries, never pasted in. A new record’s parent, in a child table or on a record page, is set by the server, never the browser.
Hidden stays hidden
A column the user cannot read is not shown, exported or sent to the browser, and display rules and formulas that read it are dropped for that user. A related record’s field is read only if the user can read every lookup on the way, and written only if they can edit that record and field, with its sharing applied.
Encrypted fields, handled
A field encrypted with Shield Platform Encryption is shown and edited as usual. Salesforce cannot sort, filter, group, search or total it, so the grid does not offer those on its column, and an admin filter on one stops the grid with the reason rather than show records the filter was meant to hide. The audit trail records its changes without their values.
Nothing leaves the org
No callouts, no outside services, no third-party code. Files leave only as CSVs a user downloads in their own browser, with values a spreadsheet would run as a formula made safe.
Checked by the build
No global Apex, no callouts, no system mode, no access check outside the one class that makes them, no third-party JavaScript: each of these fails the build if it is broken, and the source is there for anyone to read.
An audit trail of grid edits
Turn on logging per grid and every change it makes is written to a Grid Edit Log: one entry per field changed with its old and new value, and entries for records created (by import or New), deleted, restored and acted on. A related record’s field is logged against that record. Entries saved together share a Save Id; who and when are set by Salesforce, not by the grid.
All or nothing
If a log entry cannot be written, the change is not made either, and the user is told why. A grid that logs never changes something silently.
Retention, set once
Keep entries forever, or for 90 days, 1, 2 or 7 years. A nightly clean-up removes older entries, so storage stays in check without anyone remembering to purge.
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 →
- Log entries per transaction5,000
- Actions run with their own access. Rowhouse checks the object, the records and the action’s Required Permission, but not access to the flow or Apex class, and a flow left in its default mode runs in system context.
- Formulas can read
$User,$Organizationand$Setup, which no field check covers. - Filters narrow a grid; they are not security. Sharing decides who sees a record.
- Not yet tested in a Shield org. Encrypted fields are detected from Salesforce’s description of each field; no Kugamon test org has Shield turned on.
- Not logged: screen flows, changes made outside the grid, and what an action or your own automation changed afterwards.
- A logging grid stops edits when its log cannot be written — a full data store, or a missing permission. That is the price of a log with no gaps, accepted on purpose.
Against the paid grids
Security and audit trail: questions
Can a grid show a user records they could not otherwise see?
No. Rowhouse reads in user mode with sharing, so a user sees the records and fields their profile, permission sets and sharing allow, and no Rowhouse permission set grants access to your org’s own records.
Does Rowhouse work with Shield Platform Encryption?
Encrypted fields are shown and edited, but not sorted, filtered, grouped, searched or totalled, because Salesforce cannot do those on an encrypted field. It has not yet been tested in an org with Shield turned on.
Who can read the audit trail?
The Grid Edit Log is private: users read their own entries and can never edit or delete one, and others read an entry only as your sharing allows. To let an auditor read every entry, give them View All on Grid Edit Log in a permission set of your own — Rowhouse ships none, so reading the whole log is always a deliberate grant.
Does Rowhouse call any outside service?
No. There are no callouts, no outside services and no third-party code, and the build fails if any are added.
How do I report a security problem?
Privately, through GitHub’s Report a vulnerability, or by email to support@kugamon.com with a subject starting [SECURITY].
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.