Workforce Management
The offline-first tablet app of the Unareti (A2A group) workforce-management platform, used every day by field crews serving 3.5M+ supply points. My main project for six years.
In 30 seconds
For six years I was the Android developer of the field app on one of Italy's largest Salesforce Field Service projects: the workforce-management platform of Unareti (A2A group), serving 3.5M+ electricity, gas, and water supply points. Offline-first out of necessity, dynamic enough to handle an ever-growing catalog of work-order types, reliable enough for emergency response. Along the way I led a team of up to 4 people and owned the client relationship.
Context and problem
Unareti distributes electricity, gas, and water over 20,000+ km of networks in 200+ municipalities, including Milan and Brescia. Its workforce-management platform coordinates about 100 dispatchers and hundreds of field crews, from the work order to on-field reporting, in a multi-commodity, multi-company setup with a huge and ever-growing catalog of work-order types.
The crews work where the network does not: basements, cellars, under-stair meter rooms. And a weak connection is worse than no connection, because the OS believes it is online and lets calls start and hang. Some of the data collected on site, like meter readings taken in person at the customer’s home, cannot be collected twice: if a reading is lost, there is no going back.
The same app also served Unareti’s emergency response, bound to the 1-hour SLA set by the authority. During Milan’s summer heat waves the outcome of an intervention could depend on the app, which among other things drove commands sent to meters through a Bluetooth probe. A failure here is not a bad review: it is the company’s public face in front of a customer without power.
My role
I was on the project for my entire time at PIC (2015-2021), with the Android app as my primary focus. Over time I came to lead a team of up to 4 people (another Android developer plus 2-3 support engineers), mentoring the junior profiles, and I owned the client relationship: requirements, estimates, technical analysis, escalations. On the side, I also built parts of the Salesforce backend the app talked to (Apex, Process Builder, Flow) and worked with the TIBCO and MuleSoft integrations.
Technical decisions
Offline-first designed for the worst connection, not the average one
Every feature works on local data, always: the network is an optimization, never a requirement. The hard case is not zero signal but flaky signal, when the OS reports connectivity and calls hang halfway. Every remote call was treated as something that can fail at any point and resume safely later, and sync was optimized to be fast and cheap for crews constantly on the move.
A local store that is not allowed to lose a reading
Whatever the operator enters is persisted locally first, survives crashes and restarts, and enters a sync queue that considers nothing done until the server has acknowledged it. Losing a meter reading was the one failure without remediation, so durability won every trade-off against speed and convenience.
Reconciling offline work with a living backend
The app synchronized with Salesforce Field Service, where automations kept modifying the same dataset while the tablet was offline: a crew could spend hours editing data that had meanwhile changed on the server. The sync had explicit conflict rules: what merges automatically, which side wins, and what must go back to a person.
A huge catalog of work-order types, zero hard-coded screens
No team can hand-design a screen for every work-order type of a multi-commodity operator. Types were defined server-side as sets of variable fields; the app downloaded the definitions and interpreted them at runtime, rendering inputs, information, and automatic calculations for each type. A new work-order type could reach the field without touching the app.
An interface for people who preferred paper
The users were experienced field technicians, many close to retirement, skeptical about trading their paper workflow for a tablet. The UI was designed around their habits and vocabulary and refined continuously through direct feedback from the crews. Adoption was treated as a feature, with its own iterations.
Debugging without bug reports
The crews could not be asked to reproduce a bug or provide technical details. So we built a diagnostic system into the app: it logged to local files and shipped them to our server at the end of each day, where analysis scripts combed them in bulk for recurring patterns and known signatures. Problems surfaced early, without depending on user reports.
Living within the limits of a cloud platform
Salesforce, as a multi-tenant cloud, enforces strict limits on API usage and processing. Sync frequency, payload sizes, and batching were designed around those limits from the start, keeping the app fast without ever hitting the platform’s ceilings.
Results
- up to -40% intervention times across the platform
- 20,000+ km of networks served
- 3.5M+ supply points served
- 6 months from kickoff to the first release in production
- One of the largest Salesforce Field Service implementations in Italy: hundreds of field crews using the app daily, about 100 dispatchers on the back end, and adoption achieved among a workforce that started out skeptical. Platform results belong to the whole team; the field app was my part.
What I learned
When data cannot be collected twice, durability beats everything: you design storage and sync around the worst failure first, and think about speed after. And the worst network is not the missing one, it is the one that half-works.
Software succeeds when people actually use it. Listening to skeptical users and iterating on their feedback did more for the project than any single technical choice, and treating adoption as part of the product is a habit that stayed with me.