Everyone sees only their own work
Separate databases, per-action permissions, company scope and an audit trail; checked on the server on every request, not on the screen.
Role permissions: authorisation objects and actions
From sign-in to the audit trail
The tools of system administrators and auditors.
Authorisation objects: objects by module and their actions
Permissions by object and action
A role defines which actions it may take on each authorisation object; checked on the server on every request.
Company scope
A role can be limited to specific companies; in accounting, purchasing and reports, data of an unauthorised company is rejected by the server.
Segregation of duties
The requester can’t approve their own document; the rule applies in every approval policy.
Sessions the browser can’t read
Session tokens live only in httpOnly cookies that page JavaScript can’t read; access tokens last 15 minutes and refresh tokens are single-use.
Separate database
Each customer runs in its own PostgreSQL database; database passwords and e-invoice integrator credentials are encrypted with AES-256-GCM.
Audit log screen: user, module, action, record and time
Audit trail
Who did what, in which module, on which record and when; reading it requires its own permission. Salary amounts are deliberately kept out of the audit log.
Five gates every request passes
Each request is checked in order before it reaches data.
Sign-in
With a password or a one-time code sent by email.
- Passwords and codes hashed with bcrypt
- Codes valid for 5 minutes, 3 attempts
- Per-IP rate limit on sign-in endpoints
Sign-in screen: password and email code options
Customer
The request is routed only to its own database.
- The address determines the customer
- Membership checked on every request
- A removed user drops out within seconds
Members: users and membership status
Permission
Role, object and action are checked.
- Permission checks on the server, on every endpoint
- Managing roles needs its own permission; nobody can grant themselves rights
- Company scope on the role assignment
User roles: role and company scope
Transaction
Business rules are applied.
- Segregation of duties: no approving your own request
- No posting into a closed period
- No goods receipt against an unapproved order
Fiscal periods: open and closed periods
Trail
The work is recorded.
- User, module, action, record and time
- Reading the audit trail needs its own permission
- Salary amounts are not written to the audit log
Audit log: action history of a record
How security shows in the modules
The same record in every module; no interim transfers.
- HR & PayrollSalary data only with HR permission; employees see their own record.
- Finance & AccountingNo posting into closed periods; records follow company scope.
- Procurement & InventoryNo goods receipt against an unapproved order; the requester can’t approve their own order.
- Sales & DistributionE-invoice integrator credentials are encrypted and never shown on screen.
About security
The most common questions before going live.
Each customer runs in a separate PostgreSQL database and every request is routed only to that customer’s database. Database passwords are stored encrypted with AES-256-GCM.
A role defines which actions it may take on each authorisation object, and checks run on the server on every request. Roles can be limited per company; managing roles needs its own permission, so nobody can grant themselves rights.
Session tokens are kept only in httpOnly cookies that page JavaScript can’t reach. Access tokens last 15 minutes and refresh tokens are single-use; changing a password ends all sessions, and a deactivated user can’t refresh.
Yes. The audit trail records user, module, action, record and time; reading it needs its own permission. Salary amounts are deliberately kept out of the audit log.
The test role is read-only, with no access to HR, role management, the audit trail or free-form queries. A test user can’t reach any data before accepting the confidentiality and data-protection texts.
The integrator password and API key are encrypted with AES-256-GCM and never returned in any response. If the encryption key isn’t configured, the save is rejected; nothing is written in plain text.
See Hadron with
your own data
In a 30-minute demo, we set up your processes on Hadron together.