Case study · Public sector
A city that has to answer its residents — and can prove it did.
A web portal and a mobile application for a municipal administration: residents report problems with public infrastructure, staff assign and track them, crews close them with a photographed work report — and the resident who reported the problem signs it off. In production since 2020, closing the average request in five days. Built by Far Rainbow on CUBA Platform, the framework that became Jmix, years before the rename.
- In production since
- 2020
- Residents served
- ~80,000
- Average time to close
- 5 days
- What we built
- portal + app one core, two clients
- States in the workflow
- 10
- Who closes a request
- the resident
Why there is no client logo on this page
We cannot name the administration or say where the system runs. That is the agreement, and we are not going to be the supplier who breaks it for a marketing page. What we can do is show the system itself — the workflow, the screens, the architecture and the decisions behind them. If you need the reference, ask us in a meeting and we will tell you what we are allowed to tell you.
What problem does a comune actually have?
Not a shortage of reports. A broken street lamp reaches a town hall as a phone call to the switchboard, a visit to the counter, a comment on the Facebook page and an email to an address one clerk reads. Four channels, four private lists, no clock running on any of them.
The consequences are the same everywhere. Nobody can say how many problems are open today, which are past their deadline, or which crew was sent where. The same pothole gets reported eleven times and dispatched twice. And when the work is done, no one tells the person who reported it — so they report it again, or they complain publicly that nothing ever happens.
The administration is not lazy. It is working without a shared list and without a closing signal.
How a request moves
Ten states, one clock, nothing that can quietly disappear.
Most request systems have three states and an inbox. This one has ten, because the interesting cases are the ones a three-state model has no word for: a report that is rejected at moderation, a job the crew says is finished and the resident says is not, and a request that nobody answers. Each state is one of three kinds — hidden from the public feed, set by the system rather than a person, or public.
- 01Moderation — a moderator reads the report before anyone is dispatchedhidden
- 02Rejected — with a written reason, shown to the author and to nobody elsehidden
- 03In progress — accepted, routed by category, published to the feed. The clock starts herepublic
- 04Supplier assigned — the job goes to the crew or contractor responsible for that categorypublic
- 05In progress by supplier — the work is accepted and under waypublic
- 06Completed by supplier — closed only with a photographed work report attachedpublic
- 07Waiting for approval — the resident who reported it has seven calendar days to answerpublic
- 08Confirmed by citizen — the resident accepts the work. This is the only clean closepublic
- 09Completed on timeout — seven days, no answer; the system closes it and says sosystem
- 10Disproved — the resident rejects the work; a new request opens, linked to this one, and runs the whole cycle againpublic
State 10 is the one that costs money to get wrong and the one most systems skip. A rejected work report does not reopen the old request and quietly reset its age — it opens a new one that carries the link back, so the original job keeps its real history and the second attempt gets its own clock.
The public side
The whole loop fits in one card
This is the public feed of the portal. One card carries the report, the photograph the resident took, the crew’s reply with its own photograph, the date the problem was resolved, and the green line that matters — confirmed by citizen, with the date they confirmed it. No login needed to read it.
The product
This is what “built on Jmix” can look like
Three screens from the shipped application: the resident’s home, a request waiting for the resident’s approval, and the same request agreed and closed. Photo-led cards, a visible chain of states, one tap to the emergency channel.
Reporting a problem is four steps, and one of them is unusual
Category, subcategory, address, description — then up to five photographs. The map pin the phone has already placed is checked against the address, and a photograph whose geotag sits somewhere else is flagged rather than silently accepted.
The unusual step is the first item in the list. Criminal sits above the twelve ordinary categories and behaves differently: a criminal report can be filed anonymously and is never published to the public feed. It goes to the officers who are supposed to receive it and to nobody else. The same screen carries the emergency channel — SOS and a direct call to 112.
Resident
- Four-step report
- Up to 5 photos
- Geotag check
- Follow several comuni
- SOS and 112
- Anonymous crime report
Request
- 12 categories
- Subcategories
- Full Italian address
- 10 states
- Photographed work report
- Linked re-opens
Administration
- Routing rules by category
- Deadline alarms
- Contractor e-mails
- Report templates
- Push and e-mail broadcast
- 7 roles
Public
- Map of open requests
- Status-coloured pins
- Statistics
- Recently resolved
- Subscriptions
- No login to read
Who uses it
A town hall is not one desk — so the system has seven roles
The quickest way to make a municipal system unusable is to model the administration as “admin” and “user”. Seven roles, each with its own screens and its own slice of the data, is what it took for the people who actually handle a report to see only their own work.
- Administrator
- Runs the installation: comuni, categories, subcategories, routing rules, the people who hold every other role.
- Comune moderator
- Reads incoming reports for one administration and decides whether each one is published or rejected with a reason.
- Global moderator
- The same job across every comune on the installation — the safety net when a local moderator is on holiday.
- Comune operator
- The desk that actually runs the queue: assigns the work, watches the deadline alarms, publishes the report that closes the job.
- Subcontractor
- The crew or external firm that does the work and files the photographed report. Receives jobs by e-mail; sees the job, not the resident.
- Civil-protection officer
- Receives the emergency categories, where the point is speed and a report is not a ticket in a queue.
- Law-enforcement officer
- The only role that can see the anonymous criminal reports. They never reach the public feed, the moderators or the operators.
The privacy rule that is easy to miss
When a job is e-mailed to an external contractor, the resident’s personal data is stripped out of it. The contractor gets the location, the category and the photographs; they do not get the name, the phone number or the account behind the report. That is not a feature anyone asked for in a demo — it is the difference between a workflow a comune can run under the GDPR and one its DPO stops.
How long have you worked with Jmix?
Longer than the name has existed. Smart Comune was built on CUBA Platform, the framework Haulmont later renamed and rebuilt as Jmix. The domain model, the security layer, the role system and the data-driven screens in this case are the direct ancestors of what a Jmix project uses today.
That matters commercially in one specific place. The most common request we get is not “build me something new on Jmix” — it is “we have a CUBA system in production, the team that wrote it has moved on, and we need to decide whether to migrate.” We answer that from our own code, not from a vendor deck.
Far Rainbow is also the seller of record for Jmix licences in Italy. The company that advises you on the platform is the company that stands behind it commercially.
Why residents use it more than once
Reporting a problem takes four taps: category, the map pin the phone has already placed, a photo, a sentence. That part is easy to build and easy to copy.
The part that brings people back is the other end. The person who reported the problem gets the crew’s work report and has seven calendar days to accept it or dispute it. On screen the acceptance is one green line — Agreed! — sitting on top of the whole history: under consideration, in progress, waiting for approval. Nothing disappears quietly, and nobody has to phone the office to ask.
Disputing it is the interesting half. The resident says the lamp is still dark, and the system opens a fresh request linked to the old one instead of quietly reviving it. The administration keeps an honest record of the first attempt, and the second attempt starts its own clock. If the resident says nothing for seven days, the request closes on a timeout that is labelled as a timeout — not as a confirmation.
A resident can follow more than one comune, which matters more than it sounds: people work in one town and live in another, the app detects which comune you are standing in, and the system was multi-tenant from the first release.
“People can finally tell that the town hall is listening.”
Selling it
The product had to explain itself to two different audiences
A comune does not buy a request-management system the way a company buys a CRM. The person who signs is not the person who will use it, residents have to be persuaded to install an app before the system is worth anything, and everyone involved wants to know what happens to a report before they trust it with one. So the public site was part of the product, not a marketing afterthought — and we designed it too.
The administration gets the same loop in its own words on a separate page — moderator, operator, contractor, photo report, publication, confirmation. That is the vocabulary a comune uses when it asks the only question that matters before signing: who actually does this on Monday morning.
The concept it started from
On the spelling
The mock-up above says Smart Commune, with two m’s. That was the English-language variant of the name, drawn when the system was being shown to customers outside Italy. In Italian the word is comune — one m — and that is the spelling the product carries in the country it was built for. We have left the original mock-up as it was rather than retouching it.
Under it
One domain model, two clients, no second source of truth
Requests, categories, crews, deadlines and roles live once, in one model. The web portal and the mobile application are two views of it, over the same API — that is all “two clients on one core” means, and it is why there is no separate mobile back end to keep in sync. A second back end is the usual place systems of this shape rot.
The interface ships in four languages — Italian, English, French and German. Less exotic than it sounds for an Italian comune: the border provinces need at least two of them, and a resident who cannot read the form does not file the report.
Platform
- CUBA Platform
- Java
- Now Jmix
Data
- PostgreSQL
- Geolocated records
- Photo storage
Clients
- Web portal
- Native mobile
- Android 4.4+
- iOS 10+
- Public feed and map
Operations
- Role-based access
- Per-comune configuration
- Audit trail
- 4 interface languages
What we would do differently today
Build the integration with the protocollo informatico first, not last. A resident’s report becomes an administrative act the moment it is accepted, and every hour spent bridging that later is an hour of reconciliation.
Treat the accessibility audit as a sprint deliverable rather than a pre-launch task. For a public-facing municipal service in Italy this is not optional — Legge Stanca and the AgID guidelines apply — and retrofitting is always more expensive than building to it.
And publish the statistics to residents, not only to the office. The administrations that show their own overdue rate get fewer angry reports, not more.
Our part ended at the handover
We built this system and handed it over, and that is where our involvement stopped. The six years it has been running since are the customer's achievement, not ours — what they say about us is that the handover worked: documentation, a team that could take it on, and no dependency on the people who wrote it.
We publish it because it is the clearest example we have of the architecture and the workflow decisions we are describing, not because we are still in it. If you want to know what we are running today, the other three cases are better evidence.
Questions
Smart Comune, answered directly
What is Smart Comune?
A web portal and a mobile application that let a municipal administration receive, assign, track and close reports from residents about public infrastructure — street lighting, waste, roads, green spaces, signage, water. Far Rainbow designed and built it. It has been in production since 2020, running the day-to-day work of an administration serving around 80,000 residents, and it closes the average request in five days.
Why is the customer not named?
Public administrations rarely allow a supplier to publish operational detail, and we do not ask them to make an exception for our marketing. We can describe the system, the architecture and the way it is run. We cannot say which administration uses it or where it runs. Under NDA, in a meeting, we can go further.
What technology is it built on?
CUBA Platform — the framework that became Jmix — on Java and PostgreSQL, with native mobile clients. We chose it years before the rename, which is the plain answer to how long we have worked with this stack: since its previous generation. Far Rainbow is also the seller of record for Jmix licences in Italy, so the platform under this system is the platform we support commercially today.
Can you build a good-looking product on Jmix, or only back-office screens?
Both, and this case is the evidence. Jmix and its predecessor CUBA Platform give you a data model, security, roles and an administrative back end almost for free — which is why they are usually shown as internal tools. Nothing stops the customer-facing side from being designed properly: the Smart Comune mobile client is a photo-led, card-based consumer app, and it runs on the same domain model as the administrative side. The framework decides how fast you get to a working system, not how the product looks.
What happens if the resident does not agree that the work was done?
They dispute the work report, and the system opens a new request linked to the original one instead of quietly reopening it. The first attempt keeps its real history and its real duration; the second attempt starts its own clock and runs the whole cycle again. The resident has seven calendar days to accept or dispute; if they say nothing, the request closes on a timeout that is recorded as a timeout, not as a confirmation.
Is it Comune or Commune?
In Italy it is comune, with one m — that is the Italian word for a municipality and it is the spelling the product carries. Commune, with two m’s, was the English-language variant of the name used when the system was shown to customers outside Italy, and it survives on some of the early mock-ups. Same product.
Can residents report a crime through it?
Yes, and it is handled as a separate channel rather than a thirteenth category. A criminal report can be filed anonymously, it is never published to the public feed, and it is visible only to the law-enforcement role — not to the moderators, not to the operators, not to the contractors. The same screen also carries an SOS action and a direct call to 112.
How is the resident’s personal data handled when work is outsourced?
The job that goes to an external contractor is anonymised: location, category, description and photographs, without the name, phone number or account behind the report. Contractors receive work, not residents’ personal data. For an Italian public administration that distinction is what makes the workflow defensible under the GDPR rather than a problem for its DPO.
Can the same system be deployed for another comune?
Yes. It was built multi-comune from the first release: categories, subcategories, crews, deadlines, roles and branding are configuration rather than code. Standing up a new administration is a setup and data-loading exercise, not a fork. Integration with an existing protocollo or ticketing system is the part that needs project work.
How long does a system like this take to build?
A first production release of a request-management system of this shape is typically four to seven months with a team of three to five people. Where an administration already has a protocollo informatico or a GIS layer to integrate with, budget an additional discovery phase before committing to a date.
Does it meet Italian public-sector accessibility requirements?
Accessibility is part of the specification for anything a public administration puts in front of residents — in Italy, Legge Stanca and the AgID guidelines, which follow EN 301 549 and WCAG. We treat a documented accessibility statement and a conformance audit as deliverables of the project, not as a later remediation.
Next
Building something with the same shape?
Requests in, work out, and a record that survives an audit — municipal services, utilities, field maintenance, facilities. The workflow is the same; the vocabulary changes.
A 30-minute call
Bring the workflow you have today. We will tell you where it breaks before we quote anything.
JmixConsulting, engineers, migration
We sell Jmix licences in Italy and we build on it. Both, from the same company.
More workOther case studies
Systems in production, with the figures we are allowed to publish.