ERRA for IT

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.
• Full organization data export as an audited JSON bundle, plus CSV exports of key records, at any time.

What we tell you we have not built yet

Not built yet, do not sell against these: SSO and SCIM provisioning, API keys and webhooks, an active-sessions viewer, an in-app support channel, and org hard delete (permanent purge on offboarding).

Partial today: CSV bulk import's async path for large files needs a deploy step not yet live, so it is synchronous only until then; error/runtime monitoring is instrumented in the application but egress from the deployed environment is not yet enabled, so it is not yet reaching us in production. Some capabilities ship partial on purpose and say so on the record: a historical bulk import that predates a control is flagged rather than silently backdated, and a feature still behind a flag is described as gated, not shipped. See Security for the deployment facts that still require your own environment evidence.

Keep reading