Administration
The Administration workspace is where a system administrator looks at the data as it really is and, when something must be corrected, corrects it — without asking a developer to open a database console.
It is deliberately plain. The business applications are designed around how you work (a document looks like a document, a ticket like a conversation, a leave request like a calendar). The Administration workspace is designed around how the data is stored: one entry per record type, one table with every column, one form with every field. Nothing is hidden and nothing is dressed up.
Where you find it: open /services/web/admin/ on your instance. It is a separate workspace, next to the main application shell and the personal "My" workspace. Only administrators can open it — for anyone else the address simply does not answer.
What you can do
The left sidebar lists every application installed on your instance; picking one shows all of its record types — including the ones the business screens never show you on their own, such as the individual messages inside a ticket, the line items of a document, status and category lists, and stored document snapshots.
For the selected record type you get:
- A table with every column, including the technical ones the business screens hide: the internal id, the document number, the created/changed timestamps and who made the change. Records are paged, with the total count in the header.
- A record editor: click any row to open it. Every field is editable except the ones the system owns — internal ids, calculated values, generated numbers and the audit columns are shown, but greyed out, so you can read them without being able to break them.
- New and Delete for the record types where that makes sense.
Links to other records (a ticket's customer, an invoice's currency) are shown as drop-downs listing the real records, and the table shows both the name and the id — for example Customer (1) — because when you are correcting data you usually need the id as well as the name. Creating a new customer from here is intentionally not offered: master data is created in the application that owns it.
What still applies when you edit here
This is the important part, and the reason this workspace exists instead of a database console: a correction made here goes through exactly the same rules as a change made in the application.
- Document numbers are still assigned by the system.
- "Who changed this and when" is still recorded — under your name.
- Validation still runs: an invalid e-mail, IBAN or amount is refused, and the reason is shown.
- Records that are locked by design stay locked. A posted document or a stored snapshot cannot be altered here either; the attempt is refused with an explanation rather than silently accepted.
- Anything the application does automatically when a record changes (recalculating totals, updating balances, starting an approval) still happens.
In other words: this workspace gives you a plain view of everything, not permission to bypass anything. If a record refuses to change, that is the business rule protecting it — the fix is in the application (or a correcting document), not here.
When to use it
- Checking what a record actually contains, field by field, when a screen or a report looks wrong.
- Looking at the low-level records that have no screen of their own — snapshots, message threads, status lists.
- Fixing a typo or a wrong link in a record whose own screen does not offer that field.
- Confirming that an automatic action really happened (a number was assigned, a total recalculated).
When not to use it
- Day-to-day work — the applications are faster and safer for it.
- Bulk changes, imports, or anything touching the database structure. Those are separate tools.
- Working around a rule that is refusing your change. A refusal is information: find out why.