Custom GEMMA integration for municipal systems
Appfront builds the integration between your line-of-business application and the municipal standards. We retrieve case types and statuses from the catalogue, write cases and documents back via the standard APIs, translate to older message formats where needed and query personal and address data at the source. Every message gets an entry in the log, with the content sent and the response. So nobody has to retype data from yesterday's export again.
What is a GEMMA integration for municipal systems?
A GEMMA integration connects your line-of-business application or portal to the systems a municipality already uses, following the agreements in the municipal reference architecture. The integration retrieves the configuration from the case type catalogue, creates cases and updates statuses, places documents with the correct metadata in the document register and queries personal and address data at the source instead of in a copy of your own.
Without an integration, you end up with a second set of records. An application comes in through a forms package, a member of staff copies the data into the case management system and saves the attachment separately on a network drive. When an objection is lodged, the file turns out to be incomplete: the status in the case management system does not match the letter the resident received, and nobody can trace who changed what.
We build custom because no two municipalities have the same setup. Your case type catalogue, your status model, your mandates and your retention periods determine how the integration behaves, and older message-based integrations often still run alongside the newer API standards. A generic package does not know your case types, your roles or your agreements with chain partners, and so cannot determine which message belongs where. See also our integrations.
Cases and statuses
The integration creates cases based on your case type catalogue, sets statuses and results and links the people involved, so the file in your case management system stays complete.
Documents and metadata
Attachments, letters and decisions go to the document register with the correct metadata and are attached to the case, including document type, confidentiality and the retention period set by your selection list.
Data at the source
Personal, address and company data is queried at the moment it is needed, so you no longer have to maintain outdated copies and a change of address is visible immediately.
How we build your GEMMA integration for municipal systems
We start with your case type catalogue and a real application that is still being copied by hand today.
For each process, we check which system supplies what, what the receiving system expects and which steps are currently manual. This produces an overview of messages and directions.
We define case types, statuses, results, roles and document types, and determine for each field where the value comes from and how it is translated to the target system.
We build the processing of incoming and outgoing messages, with a queue, retries after a failure and a screen where administrators can see which message got stuck.
We test on your acceptance environment with real case types, take the integration live in phases and set up monitoring, so a deviation is noticed before your staff notice it.
What a GEMMA integration for municipal systems actually does
The components below appear in almost every GEMMA integration. Which ones you need depends on the standards your systems support and on the processes you want to open up.
Case messages
The integration creates cases, updates statuses and closes them, following the case types and results in your catalogue.
Document flow
Documents go to the register with metadata, document type, confidentiality and retention period, and stay linked to the correct case and case handler.
Field mapping
For each field, you define which value goes to which target field, including code lists and fixed values for fields the source system does not populate.
Queue and retry
Messages that fail to arrive stay in the queue and are offered again after a set interval, without creating duplicate cases.
Log per message
For every message you store the content, the response and the timestamp, so you can show afterwards what was exchanged.
Access per integration
Each integration gets its own key with its own permissions, so you can shut down one system without affecting the other flows.
Who we build GEMMA integrations for municipal systems for
The software is intended for government organisations and their suppliers where data is currently retyped between systems or exchanged via files.
Municipalities
Here, older message-based integrations often run alongside newer APIs. The key is the translation between the two, so processes can be migrated step by step.
Joint arrangements
Working for multiple municipalities, each with its own set-up. The key is keeping case types and keys separate per participant.
Environmental and enforcement agencies
Files cross organisational boundaries. The key is writing documents and decisions to the file of the commissioning municipality.
Suppliers of line-of-business applications
Every customer asks for its own integration. The key is a single interface that is configured differently per municipality without the application changing.
Technology and integrations
This page is about building an integration between your application and the municipal standards for cases, documents and data sources. Alongside this, we build integrations, web applications and portals and custom software for the processes around them. You can read about our way of working on building software.
Why Appfront for your GEMMA integration for municipal systems?
An integration is only as good as the file that comes out of it. That is what we build on: every message can be traced and every failure is visible.
No second set of records
Data lives in one place and is queried where it belongs. That not only saves work, it also prevents two systems from showing different statuses.
Failures are visible
A message that fails to arrive stays in the queue and is reported. Administrators can see which message is affected and can resubmit it once the cause has been fixed.
You can explain it later
In the event of an objection or an access request, the log shows what was exchanged and when. That turns accountability into a matter of looking it up.
Security and privacy for GEMMA integrations for municipal systems
Personal data, citizen service numbers (BSN), case files and decisions all move through the integration. Access is arranged per role: an administrator sees messages and errors, a case handler only the cases of their department. Every action is logged. Retention periods follow your selection list and the requirements of the GDPR, so message content is not kept longer than necessary.
The software runs in a European data centre, with encrypted storage and daily backups. Integrations with case management systems, document registers and national services work with their own keys, which can be revoked per integration.
Frequently asked questions about GEMMA integrations for municipal systems
Questions that municipalities and their suppliers ask before getting started.
The integration connects your application to the municipality's systems in line with the agreements in the municipal reference architecture. It retrieves case types and statuses, creates cases, places documents with metadata in the register and queries personal and address data at the source. Every message is logged, so you can check afterwards what was exchanged.
Yes. In many municipalities, older message integrations run alongside the newer API standards. We build the translation between the two, so processes can move across step by step without you having to replace everything at once. For each message, we record which way the traffic flows and which fields are converted in the interface overview.
The integration reads your catalogue and uses the case types, statuses, results and roles defined in it. For each process, you choose which case type belongs to which kind of request. If you later change a case type, you adjust it in the catalogue and the integration itself does not need to be rebuilt.
The message stays in the queue and is offered again after a set interval. Because every message has its own identifier, no duplicate cases are created when a retry eventually succeeds. Administrators can see on a screen which messages are stuck and receive a notification if a flow has been stalled for longer than agreed.
Yes. Each participant gets its own configuration and its own keys, so case types, permissions and logs stay separate. For partnerships and suppliers, this is usually the starting point: a single interface configured differently for each municipality, without the application noticing and without one participant's data becoming visible to another.
That is up to you. We can manage it, or your own administrators can do so with us supporting them behind the scenes. In both cases, you get insight into the queue, the error messages and the log, and we record who manages which key and how an integration is revoked.
Check that first. If your supplier supports the standards you need and the flow you want is already included, that is almost always the shortest route. Custom development makes sense when you want to connect your own line-of-business applications or portals, when translation between old and new messages is needed, or when several organisations need to use the same interface.
Want to see how your cases and documents arrive without retyping?
Tell us which systems you want to integrate, which case types are involved and what your staff currently copy over by hand. We will show you what the interface overview, the queue with error messages and the per-message log look like.