Some institutions deal with real people every day, and every hour spent on administration takes time away from the people the work is really for. A good records system does more here than replace paper. It makes recording and retrieval faster, makes processes transparent, and gives time back to the professionals.
But there's a complex side to this that's easy to underestimate at first: the rules can change.
When the form is prescribed by law
We built a system for a network of public-service institutions that covers the administration of the entire case process: from receiving an application, through scheduling the casework and issuing the official document, to archiving. It handles more than twenty application types, and besides the institution's staff it's also used by external partners and the private individuals concerned, each according to their own permissions.
In a system like this, the format and content of the documents are largely defined by legislation. And when the legislation changes, so do the forms: a new field is added, another becomes required, the order changes.
The form should be data, not code
In the traditional approach, forms and document templates are part of the software's code. Every change means developer work, which can take weeks and cost a significant amount, while the institution has to use the new format from the day the legislation takes effect.
That's why we designed the system so that forms, questionnaires and document templates live as data rather than in the code. In a visual editor, the institution itself can change the fields, the validation rules and the conditional logic, such as which additional fields appear or become required depending on an answer. From the completed data, the system automatically generates the official, printable PDF document. The approach worked so well that it later became a standalone component that can be built into other systems.
Where flexible and fixed data meet
Dynamic forms weren't the big challenge. The real task was connecting the flexible data structures with the ones that have to stay fixed.
An application's lifecycle, the scheduling of casework, multi-level approval or a statistical report all rely on fixed data and processes. They need to know where to find a piece of data that is key to a decision, or which data is carried over automatically into the issued document, even if the form it was recorded on has changed in the meantime. So the line had to be drawn carefully between what can be shaped freely and what the processes depend on. Where the two meet, the connection has to stay stable even when one side changes.
It has to be the same years later
The public sector has one more requirement that rarely comes up: a document issued earlier must look exactly the same years later, even if the template has changed several times since.
That's why the system saves the previous state before every change, any earlier version can be retrieved and reproduced, and every event is logged with a timestamp and user ID. Together with encrypted data storage and role-based access, this is the foundation for handling sensitive data.
The system changes with the rules
In systems like these, whether public administration records or official administration, the sector's rules, processes and exceptions are decided in the data model. If the data model is well designed, the system can change along with the rules.
If forms and processes change regularly in your organization too, and you're tired of waiting for a developer for every change, let's talk. Let's look together at what could become data in your organization and what has to stay fixed, so your processes keep working reliably when the form changes.