On most platforms, the two things auditors and security teams actually ask for — a complete change history and fine-grained access control — live on the plan above the one you’re on. You start on a tier that logs little and governs coarsely, and the moment compliance gets real, you’re quoted an upgrade.
dForge treats both as the floor, not the ceiling. A full audit trail and row-, column-, and operation-level access control are part of how the platform works on every plan, applied on every request. Here’s what that actually means, because “enterprise-grade security” is a phrase everyone uses and few specify.
Every change, captured — with before and after
When a record changes in dForge, the change is recorded in a dedicated audit schema, separate from your business tables. Two things get written:
- A change log entry — what happened (insert, update, or delete), who did it, when, and in which folder and module.
- The field-level detail — for each column that changed, the old value and the new value, plus human-readable display versions, not just raw codes.
So you don’t get a vague “record was modified” line. You get “on this date, this person changed status from Pending to Approved and amount from 1,000 to 1,200.” That’s the difference between a log that satisfies an auditor and one that starts an investigation.
A few details that matter in practice:
- Audit level is per entity. You choose how much history each entity keeps —
basic, field-level, or full — so high-stakes records get full before/after detail without every lookup table paying the same cost. - There’s a safety net. Changes are captured at the application layer, and a database trigger records them too, tagged by source. Even a write that bypasses the app gets logged — the history doesn’t depend on everyone going through the front door.
- The log is yours. It lives in the same PostgreSQL database you own, so you can query it directly, retain it on your terms, and feed it to whatever monitoring you already run.
Access control in three layers, on every request
Permissions in dForge aren’t a single on/off switch. They’re three independent layers that compose, and all three are enforced on every request — not bolted on in the UI, where they can be bypassed.
- Row-level — which records. Folders carry filters that resolve to a SQL
WHEREclause. Granting someone a folder grants them exactly the slice of data that folder defines — this warehouse, this division, this status — and nothing else. - Column-level — which fields. Entity views control which fields are visible and which are editable, so two roles can see the same record with different columns exposed.
- Operation-level — what they can do. Roles carry per-entity rights — Select, Insert, Update, Delete, Clone — plus Execute for actions, reports, and folders.
Two properties make this practical rather than painful:
- Permissions are additive. Rights from multiple roles are merged as a union; access is granted, never silently revoked by a second role. What a user can do is the sum of what their roles allow.
- Roles are folder-scoped. The same role can carry different effective rights in different folders, so you model “manager here, read-only there” without inventing a new role for every combination.
For the full model — folder row filters, entity-view field flags, and the per-entity rights matrix — see the security model reference, or the security overview for the shorter version.
Why “built in, not a tier” actually matters
Security that lives on a higher pricing tier is security you don’t have until you pay for it — which usually means you don’t have it when you need it. When audit and access control are the default:
- Compliance gets cheaper. The change history an auditor wants already exists, on every entity you chose to track, without a migration or an upsell.
- Least-privilege is the starting point. Row, column, and operation limits are how you model access from day one, not a hardening project you schedule for later.
- There’s no “we’ll add logging” gap. The trail is on from the start, so the period before someone remembered to enable it doesn’t exist.
And because the audit log and the permission model both live in the PostgreSQL database you own, none of this is trapped in a vendor’s runtime. We covered what that ownership means — and its limits — in Only You Own Your Data.
Where the line is
dForge governs access to the data inside it and logs the changes made to it. It is not a SIEM or a log-aggregation platform, and it is not a replacement for your identity provider. Its job is to make sure every read and write is authorised by the three layers and that every change is recorded with before/after detail — then to let you take that audit data out via its API, or query it directly, and feed it to whatever security tooling you already run.
If you need enterprise log analytics or centralised identity, those integrate alongside. If you need a platform where access control and a complete change history are simply on, that’s the idea.
Frequently asked questions
Does dForge keep a full audit trail of changes? Yes. Inserts, updates, and deletes are recorded in a dedicated audit schema with who changed what and when, and — depending on the per-entity audit level — the old and new value of each changed field.
Is the audit log a paid add-on or a higher tier? No. The audit trail and the access-control model are built into the platform and applied on every request, not features unlocked at a higher pricing tier.
Can it capture changes even if something writes to the database directly? Yes. Changes are recorded at the application layer and by a database trigger as a safety net, tagged by source — so writes are logged even outside the normal app path.
What kinds of access control are supported? Three composable layers: row-level (folder filters resolving to a SQL WHERE clause), column-level (entity views controlling field visibility and editability), and operation-level (per-entity Select/Insert/Update/Delete/Clone rights, plus Execute for actions and reports).
How do permissions combine across multiple roles? They’re additive — rights from a user’s roles are merged as a union, and roles can be folder-scoped, so the same role grants different effective rights in different folders.
Can I get the audit data out for compliance or monitoring? Yes. The audit log lives in the PostgreSQL database you own, so you can query it directly or export it via the API and feed it to your existing monitoring or SIEM. See Only You Own Your Data.
Audit trails and access control shouldn’t be the upsell that arrives after the incident. In dForge they’re the floor you build on — see how the whole platform is built.
