# Permissions live in the database, not on the screen > Why an internal tool's permissions, validations and audit trail must be enforced in the database and not only in the interface. - URL: https://www.enter20.com/en/blog/permissions-live-in-the-database-not-the-screen/ - Español: https://www.enter20.com/blog/los-permisos-viven-en-la-base-de-datos-no-en-la-pantalla/ - Updated: 13 August 2026 - enter 2.0 — Practical AI, governed data, dashboards, automation and information systems for organisations that need to make better decisions. - Published: 2026-08-13 - Updated: 2026-08-13 - Topic: Internal tools and permissions - Tags: permissions, databases, internal tools, security, audit - For: IT managers, operations directors and those who commission internal tools - The enter 2.0 team ## Short answer An access rule that exists only in the interface is a suggestion. If someone calls the API directly, opens another screen or a bug lets a query through, the rule disappears. The rules that matter must be enforced in the database. The same applies to validations and auditing: ensuring that a person cannot be allocated at 120%, that an old clock-in record cannot be edited or that every change leaves a trace are guarantees best applied where the data lives. ## Key points - An access rule that exists only in the interface is a suggestion: a direct API call, another screen or a bug is enough to bypass it. - With row-level policies, the database filters every query by who is asking, and data that does not belong to a user is not hidden: it is simply not there. - Business rules must be validated in the data, because an import, a script or a new screen will bypass rules that only the form enforces. - A useful practice is for the application to write only through functions with narrowly scoped permissions, which record the change and the audit entry in the same transaction. - Closing, archiving or deactivating instead of deleting preserves the history, keeps reports consistent and makes it possible to explain decisions. ## Each department sees only its own data In a tool shared by several departments, or by several companies on the same platform, isolation is achieved with row-level policies: the database filters every query according to who is asking. Maintenance sees its own issues, management sees all of them, and nobody has to remember to add a filter on every screen. The practical effect shows when you switch user: whatever does not belong to that user ceases to exist for that session. It is not hidden; it is not there. That difference is what protects you when the interface has a bug. ## Write only through functions A useful practice is for the application not to write directly to the tables, but through functions with narrowly scoped permissions. Each function does one thing, checks what it needs to check and records, in the same transaction, the change, the audit entry and, where appropriate, an automatic comment. With a version number on every record, two people do not overwrite each other: if someone saves over an old version, the operation fails and they are shown the other person's change. This is simpler than locking records and avoids silent data loss. ## Validate in the data, not in the form Making sure a person does not exceed 100% allocation in overlapping periods, that a PIN is locked after five attempts or that an old clock-in record cannot be modified: these are business rules. If only the form enforces them, an import, a script or a new screen will bypass them without meaning to. The same goes for what must not leave the system: the cost price in a catalogue must be removed in the public API, not just hidden on screen, and an internal questionnaire score should never be sent to the client's browser. ## Never delete: close or deactivate Deleting destroys the history and, with it, the ability to explain a decision. Closing, archiving or deactivating preserves what happened and keeps reports consistent. Closing an issue can require writing down what was learned: it costs little and leaves a record behind. These decisions do not require a large platform. A well-configured relational database, functions with narrowly scoped permissions and a mandatory backup before every migration are enough for a small tool to remain reliable for years. ## Frequently asked questions ### Is hiding data in the interface enough to ensure each department sees only its own information? No. An access rule that exists only on screen disappears if someone calls the API directly, opens another screen or a bug lets a query through. Isolation is achieved with row-level policies in the database, which filter every query according to who is asking. That way, data that does not belong to a user is not hidden: it does not exist for their session. ### How do I stop two people overwriting each other's changes in an internal tool? With a version number on every record. If someone saves over an old version, the operation fails and they are shown the other person's change. This is simpler than locking records and avoids silent data loss. ### Should business validations be enforced in the form or in the database? In the database. Rules such as a person not exceeding 100% allocation in overlapping periods, a PIN locking after five attempts or an old clock-in record not being editable are bypassed unintentionally if only the form enforces them: an import, a script or a new screen is enough. The same applies to data that must not leave the system, such as a catalogue's cost price in a public API. ### Do I need a large platform for an internal tool to be reliable? No. Validating in the data, applying row-level permissions or closing records instead of deleting them does not require a large platform. A well-configured relational database, functions with narrowly scoped permissions and a mandatory backup before every migration are enough for a small tool to remain reliable for years. ## Connected services and cases - [Bespoke operational tools](https://www.enter20.com/en/services/bespoke-operational-tools/) - [IT governance, continuity and operations](https://www.enter20.com/en/services/it-governance-continuity/) - [Fractional IT Director](https://www.enter20.com/en/services/fractional-it-director/) - [Modular operations platform for a foundation](https://www.enter20.com/en/work/foundation-operations-platform/)