ERRA for IT
Isolation enforced by the database, an audit trail the app role cannot edit, and an export path so your data is never locked in.
What you're evaluating
Whether tenant isolation is a property of the architecture or a promise the application code has to keep. Whether an audit trail can actually be edited by someone with database access. Whether the org can get its data back out if it ever needs to leave.
What ERRA gives you
- PostgreSQL Row-Level Security enforcing tenant isolation at the database level, not filtered in application code; cross-org access exists only through an explicit, scoped grant enforced by the same policy.
- An append-only audit trail: the application's database role has no permission to update or delete an audit row, so the database itself refuses the edit, not just the UI.
- Server-side role-based permissions on every mutation, with elevated actions (like a release-gate override) requiring a distinct permission, never granted by a general admin role.
- Approved formula versions locked by database trigger, not application logic alone.
- Self-serve export of your organization's records as a capped JSON bundle, with a truncation manifest if you exceed the cap, plus CSV exports of key records, at any time. A complete copy including files is available as an assisted export.
On the roadmap
On the roadmap: SSO and SCIM provisioning, public API keys and webhooks, an active-sessions viewer and in-app support chat. Tell us which matter for your review.
CSV imports include a mapping review. NAT egress is deployed, and error reporting is configured to strip request bodies, headers, cookies and user fields before sending to Sentry. Account closure preserves the audit trail and signed compliance records; owners can export their organization records.
Keep reading
It starts with a record that can be checked.
Recorded and shared through ERRA.