Skip to content
Iñigo EcheverríaGeologist · Geospatial developer
All work

Multi-team workflow platform

A web platform that moves vector GIS layers through the teams that produce and review them, with files, notifications and a verified hand-off to an operations system. Later generalised into a reusable framework.

Role
Designer and developer
Period
2025–2026
Services
  • Maps, dashboards and apps
  • Data pipelines
The platform's main table in progress view. Each row is a record with its flow, region, number, name, overall status (completed or in progress) and the team in charge, shown as a coloured badge. A line of icons runs across the steps, from drafting through reviews, corrections and approval to the final registration: green ticks for finished steps, arrows for skipped corrections, a clock for the current one (red when overdue) and empty circles for steps ahead. Above, a search box, a filter by assigned team and a switch between progress and summary views. Below, five delay charts: mean delay by step for each of the two flows, days late by record, and two donut charts counting the steps that are late right now, by team and by region.
Every record and where it stands, in the progress view, with the delay charts from the summary view below it. Real interface, translated into English, with invented data.

A national public agency produced vector GIS layers (shapefiles) through a chain of regional and central teams: every record went through drafting, review, corrections and a final registration in the agency’s operations system, coordinated by email and shared spreadsheets. I designed and built the platform that replaced that coordination, and later generalised it into a framework for any process of the same kind.

How it works

  • One view of every record. A table lists each record with its current step, deadline and team in charge. Opening one shows a stepper with the whole flow: finished steps show what each team submitted, and the current step shows its form to the team that owns it.
  • Deadlines and delays. Each step has a deadline sized to the work it involves. A summary view charts delays by step, record, team and region, both over the period and right now.
  • A state machine for the flow. Steps and their order are configuration stored in the database. A workflow engine made of pure functions decides every transition, including branches such as corrections, and emits actions (complete a step, close a record, copy a file) that the backend carries out.
  • Files straight to Google Drive. Uploads go from the browser to a Drive folder owned by the agency, as resumable uploads that never pass through the backend, so even large files cost no server time. The platform checks that every shapefile is complete, and names and files each upload itself.
  • Notifications. Every submitted step emails the next team in charge, copying everyone involved, from the platform’s own account, with templates built in React Email.
  • Authenticated access only. Google sign-in, with access and administrator rights as Firebase custom claims, enforced both by the backend and by Firestore security rules.
  • Administration. An admin panel for users and teams, record lifecycles, storage folders and database backups, plus a command-line tool to seed and pull collections.

The page of one record. A stepper shows its flow: drafting, review, correction, approval, topological correction and final registration, each with the team that owns it. Drafting, review and approval are done, the correction was skipped, and the topological correction is the current step. Below, its form for the central GIS team: a drop zone for the shapefile’s files, the calculated area in hectares, technical observations and a submit button. Invented data.

A verified hand-off

The last step registers the final files in the agency’s operations system, which the platform could only read. To prove that what got registered was exactly what the teams had approved, I asked that system’s maintainers to record a SHA-256 fingerprint of every upload. The platform computes the same fingerprint when it packages the final ZIP and, before letting a record close, compares it with the one the operations system publishes, together with the registered area. If either differs, the record stays open and the team sees exactly what doesn’t match.

From one app to a framework

The parts that weren’t specific to this process became a framework for any process made of ordered steps owned by teams. A rigid core is shared by every deployment: identity and access, case lifecycle, workflow engine, forms, file attachments, notifications, dashboard, admin panel, audit log, analytics and internationalisation. Each process plugs in as a domain, made of configuration and seed data, without ever changing the core. The original platform is its reference domain.

Results

  • Used by 36 people across five regional and central teams, who moved from emails and spreadsheets to one shared workflow, with video tutorials built into the platform.
  • No unverified hand-offs: a record only closes once its files match what the operations system registered.
  • Free infrastructure: it runs entirely on free cloud tiers (Firebase, Vercel, Deno Deploy and Google Drive).
  • Tested: 325 automated tests cover the platform, and the framework’s core has its own unit tests and an end-to-end smoke test of a full process.