Custom TMLO integration between case system and e-depot
Appfront builds the integration that connects your case management system, DMS or line-of-business application to your archive service's e-depot. We map your fields to the TMLO elements, check per information object that the mandatory metadata is present, build the aggregations from archive down to file, and prepare a SIP in ToPX XML. So nobody has to keep topping up metadata file by file in export lists and loose spreadsheets.
What is a TMLO integration between a case management system and an e-depot?
A TMLO integration translates the data in your case management system, DMS or line-of-business application into the Metadata Application Profile for Local Government (TMLO). For each information object, the integration retrieves the fields, maps them to the correct TMLO elements, determines the aggregation level of archive, file, record and document, and delivers everything to the e-depot as ToPX XML together with the files. Objects that don't comply stay behind, with the reason attached.
Without such an integration, every transfer starts from scratch. A municipality exports cases from its case management system, records the mapping in a spreadsheet and discovers during ingest that fields such as place, public access or the link to the selection list are missing or named differently from what the archive expects. The batch is rejected and someone fills in hundreds of rows by hand. At the next transfer, the same team is back at it.
We build this as custom software because your mapping depends on your own setup: your case types, your document types, your selection list and the agreements in your archive service's transfer protocol. We build those rules into the integration, including the step to MDTO. A generic export package doesn't know your case type catalogue and so delivers metadata that still fails at ingest. Nor does it know your agreements on access restrictions.
Mapping to the TMLO elements
For each source field, you define which TMLO element it lands in, with fixed values, derivations and default values where your source leaves a field empty. The mapping can be configured per archive creator.
Checks before you submit
The integration tests every object for mandatory and conditionally mandatory metadata, for file format and for consistent relationships between the aggregation levels. You see in advance what will go wrong.
SIP and feedback
Approved objects are sent to the e-depot as ToPX-XML with files in a SIP. For each batch, the integration records what was submitted, what was accepted and which notifications came back.
How we build your TMLO integration between case management system and e-depot
We start from a real export from your case management system and the transfer protocol of your archive service, so we test on existing data rather than a sample file.
We go through your case management system, DMS and file shares, identify which fields are actually populated, and compare this with what your archive service requires at transfer under its transfer protocol.
We build the field mapping, the fixed values and the structure of archive, file, record and document. Case types, document types and selection list categories are linked to the right TMLO elements.
Your archive officer gets a work queue: assembling batches, resolving notifications, completing missing metadata and re-validating. Who changed what and when remains visible for each object.
We connect to the e-depot's ingest, run a trial transfer with your archive service, and then take over management of the integration, including adjustments if the profile or setup changes.
What a TMLO integration between case management system and e-depot actually does
The components below feature in almost every TMLO integration. Which ones you need depends on your source systems and on the requirements your archive service sets in its transfer protocol.
Field mapping per source
A table that maps each field from the case management system, DMS or file share to a TMLO element, with fixed values and derivations per records creator.
Check on mandatory metadata
Every submission is checked for mandatory and conditionally mandatory elements, so rejected objects don't only surface at ingest.
Building aggregations
The integration builds the structure of archive, file, record and document and ensures that relationships between the levels are correct and nothing is left orphaned.
ToPX-XML and SIP
Metadata and files are bundled into a submission package in the XML format your e-depot expects, with a checksum per file and the recorded file format.
Ingest and feedback
The batch is sent to the e-depot automatically, and any notifications that come back land as a task with the employee who submitted the batch.
Selection list and retention period
Case types and document types receive their category from the selection list, so that retention period, destruction date and public access status are correct in the submitted metadata.
Who we build TMLO integrations between case management systems and e-depots for
The software is intended for public sector organisations where information comes from multiple systems and has to be transferred to an archive service periodically.
Municipalities
Here, the case type catalogue and the selection list determine the mapping. The key is that case data from the case management system and documents from the DMS are submitted as a single whole.
Regional archive services
They receive transfers from dozens of records creators. The key is a mapping per submitting organisation, with the same upfront check, so that batches don't fail at ingest.
Environmental agencies and safety regions
Files here pass through multiple line-of-business applications. The key is retrieving metadata from several sources and merging it into a coherent aggregation.
Water authorities and provinces
Permits, decisions and project files are often partly stored on file shares. The key is enriching files that lack metadata before they go into the transfer.
Technology and integrations
This page is about linking your source systems to the e-depot according to TMLO and, where your archive service is ready for it, according to MDTO. You'll find related topics under integrations, web development and software development. You can read about our approach at building software.
Why choose Appfront for your TMLO integration between case management system and e-depot?
A transfer is only as good as the metadata underneath it. That is what we build on: validate first, deliver afterwards.
Rejection should happen up front
A batch that fails at ingest costs more work than validating ten times beforehand. That is why we put the check in your own environment, before anything leaves the building.
The mapping is a document, not a one-off job
Case types change and profiles get superseded. By version-controlling the mapping in the integration, you know for every batch which rules it was built under.
Your records manager stays in control
Not every missing field can be derived. That is why the records manager gets a work queue in which exceptions can be completed by hand and validated again.
Security and privacy in a TMLO integration between case management system and e-depot
The integration contains files and documents of citizens and businesses, including data on disclosure restrictions. We manage access per role: who may map, who may supplement and who may submit. Every change to metadata is logged with the user and timestamp, and we record the retention periods from the selection list in the integration itself.
The software runs in a European data centre, with encrypted storage and daily backups. Integrations with your case management system, DMS and the e-depot ingest use their own keys, which can be revoked per integration.
Frequently asked questions about TMLO integration between case management system and e-depot
Questions that information managers and records officers ask before they get started.
The integration retrieves information objects and metadata from your source systems, converts your own fields to the elements of the Toepassingsprofiel Metadatering Lokale Overheden (TMLO), builds the aggregations from archive down to file, and delivers the result as ToPX XML with files to the e-depot. Anything that does not comply stays in a work queue.
MDTO was adopted in 2021 as the successor to TMLO, and the National Archives is no longer developing TMLO. In practice, archive services still work with both. We set up the mapping so that the same source fields can go to TMLO or to MDTO, so you can switch when your archive service asks you to.
Yes. Your existing mapping table is the best starting point, because it contains the choices your organisation has already made. We carry those rules over into the integration, fill the gaps based on a real export and show you the differences before we fix anything in place.
Then we decide per element what happens: derive it from another field, use a fixed value per records creator, or send it to the work queue so that an employee can complete it. What was derived and what was entered by hand remains visible and accountable per object.
Yes. Older project and building files in particular are often held outside the case management system. The integration reads folders and files, derives whatever can be derived from the folder structure and file names, and leaves the rest to be completed. File format and checksum are recorded per file before the package is sent.
For each batch, the integration keeps track of what was submitted, when, by whom and which messages the e-depot returned. Rejected objects return to the work queue and can be resubmitted after correction. That gives you an overview of every transfer that you can show to your archivist.
Check that first. Some case management systems produce an export that your archive service accepts, in which case there is no reason to build anything. It breaks down once several sources are involved, mandatory fields are missing or your archive service sets its own requirements. In that case, a custom integration with validation up front is cheaper than manual work.
Want a transfer that is no longer rejected at ingest?
Tell us which systems your records come from, which archive service you deliver to and which batch is currently stuck. We will show you what the field mapping, the check for mandatory metadata and the transfer package look like, in line with our way of working.