Idepoo Software
EventFlow: from defining an event to the citizen’s verdict, in one flow
Cultural events automation for municipalities and cultural organisations: a multi-stage approval chain, a mapped atlas of cultural venues, class registration and hall booking, geofenced field reporting and citizen surveys — on web, mobile and an API.
Which organisations it is for
Municipalities, cultural and arts organisations, and public bodies that run dozens or hundreds of cultural events a year and manage them today with spreadsheets, internal memos and messaging groups.
The problem is usually one of four: an approval nobody can locate — the content is signed off, the budget is not, and no one knows whose desk the file is on; venues with no current record — the capacity, facilities and classes of each cultural centre sitting in an old file; field reports that prove nothing — a photograph with no evidence of where or when it was taken; and evaluation that never happens, because collecting citizen feedback is harder than running the event itself.
EventFlow solves all four in one system, and it is a deployed product rather than a proposal: the installed version runs the cultural events of all 22 districts of Tehran.
The life of an event
01 — Draft
The responsible unit defines the event: programmes, sub-activities, venue, dates and a proposed budget.
02 — Content approval
The cultural secretariat reviews and signs off the programme itself.
03 — Budget approval
Finance approves the figure or returns it with a reason.
04 — Deputy and HQ
The organisational approval path up to headquarters, with a checklist gate at each stage.
05 — Dispatch and delivery
The event is dispatched to the districts and delivery begins; field reports are filed from the site.
06 — Evaluation and closure
Citizen survey and delivery-team evaluation, then formal closure of the file.
Every transition is governed by a state machine inside the domain, not by a button in the interface: without the permission for that transition the event does not move, by any route. Programmes and sub-activities are versioned and a change history is kept — so when someone asks six months later who moved the budget from one figure to another, the system has the answer.
Eight working domains on one platform
Event management
The full cycle from draft to closure, with versioned programmes and sub-activities, dispatch to districts, checklist gates and change history.
Cultural atlas
Cultural venues — cultural centres, neighbourhood houses, Quran houses, parks — with categories, photographs, facilities, coordinates and a map view, each with its own district approval flow.
Venue services
Classes, bookable facilities (halls, libraries, workshops, free consultation) and clubs; online registration, booking and membership, switched on per venue.
Evaluation and surveys
A question bank, evaluation plans and methods, and citizen surveys through single-use tokens — with the citizen and the delivery team asked different things.
Field reports
Photographs captured at the event location inside a geofence and a time window, with an offline queue and automatic sync when the network returns.
Citizen experience
Browsing events and venues without signing in, a Jalali calendar, "near me" by GPS, festivals, competitions and cultural ambassadors.
Organisation and geography
A geographic hierarchy of districts, areas and neighbourhoods alongside the organisational one; each user sees only their own scope.
Access and audit
Fine-grained capability-based permissions — each endpoint is guarded by a named capability — plus multi-tenancy and a full audit trail on every access.
Three clients, one source of truth
- The web panel for the cultural unit, the districts and headquarters: defining events, approving them, the atlas, venue services and reports.
- The mobile app for two very different audiences: the field officer filing a report, and the citizen browsing events and venues and answering a survey.
- The API both are fed by, so neither ever holds a different version of the truth.
The architecture is Clean Architecture with domain-driven principles: the business core at the centre, independent of technology, with infrastructure and presentation in the outermost layers. When another client arrives — a kiosk, a partner organisation's panel, a new app — the rules are not written a second time.
Engineering decisions that hold up in the field
Offline work in the field
A report goes into a local queue and syncs itself when the network returns. The reachability probe is tuned against your own server, so national filtering does not make the system report itself "offline" — the failure mode of apps built assuming an open internet.
Field reports that prove something
A photograph is only accepted inside the event's geofence and within its time window. A report sent from the office is not recorded.
In-app updates
The sideloaded app detects a new version on your own server, downloads and installs it, with support for forced updates — no app-store dependency.
Capability-based authorisation
Instead of raw roles, every endpoint is guarded by a named capability, and every access is written to the audit trail. In an organisation with several layers, roles alone cannot express who may do what.
An automated design gate
Colour and typography tokens with a build gate: WCAG AA contrast and the Persian font and RTL rules are checked before every build. Accessibility is not a claim, it is a condition of the build passing.
Real Persian and RTL
Native RTL at the Android layer, the Jalali calendar, Persian numerals and dedicated typography — in all three clients, not only on the web.
The stack
- Web client — React with Vite and TypeScript, maps with Leaflet, a Persian RTL interface.
- Mobile app — React Native and Expo, with offline operation and in-app updates.
- API — ASP.NET Core on .NET 10, versioned REST, JWT authentication, capability-based authorisation, multi-tenancy and an audit trail.
- Business core — domain-driven entities, a state machine, validation with FluentValidation.
- Infrastructure — Entity Framework Core, scheduled jobs with Hangfire, object storage for images, centralised logging with Seq, and spatial data with NetTopologySuite.
- Data and operations— SQL Server, Docker Compose, nginx, Linux, with automatic incremental schema setup at service start.
Frequently asked
Is it suitable for a smaller municipality?
Yes. The geographic and organisational hierarchies are configurable: 22 districts with areas and neighbourhoods, or one municipality with a few units. Modules you do not need stay off, and registration and booking are switched on per venue.
Our approval chain is different.
Stages and roles are configured to your organisation; what is fixed is the principle — every transition needs an authorisation, every rejection carries a recorded reason, and everything stays in the audit trail. Fitting the workflow to your structure is part of deployment.
How do you load our venue data?
From your existing file — a spreadsheet or an export from the previous system — with coordinates and images. Venues without coordinates are flagged on the map for the district officer to complete.
Do citizens have to register to see events?
No. Browsing events, the venue atlas and festivals is open without signing in; a login is needed only to enrol in a class, book a hall or join a club.
Is the app on Google Play?
The app is distributed by sideload and updates itself from your own server, with forced updates supported.
What does it cost, and how long does deployment take?
Setup starts at 180m toman, with annual support at 20% of the setup fee. The final figure follows a demo, once the number of districts, venues and approval stages are clear.
A demo with your own structure
In the demo we lay your approval chain and district hierarchy onto the system, so you see what it actually looks like.
The organisation, how many districts or units, and roughly how many events a year — those three answers are enough to set up a demo.