ENTERPRISE · FRONTEND
FORCE
An intelligent workforce platform for scheduling, tracking, and field-team coordination.
The context
FORCE is TM R&D’s intelligent workforce management system for field teams such as technicians, engineers, inspectors, and service crews. The platform automates scheduling, tracks attendance and work hours, supports GPS tracking, connects customers, dispatchers, and field staff through real-time communication, and gives operations teams dashboards for ticket status, productivity, and resource visibility. It runs as multi-tenant software: one shared core serving separate client organisations across water utilities and telco field operations, including SAMB, Ranhill SAJ and Unifi TM (TMFORCE), with custom tenant builds where a client needs something the core does not cover.
What I contributed
- Developed Webix.js portal interfaces on the shared FORCE core with REST API integration.
- Led frontend UAT readiness for FORCE DSS, a custom build integrating Hikvision CCTV with field operations.
- Resolved defects through testing cycles and facilitated module validation for official project sign-off.
- Contributed to FORCE Ranhill SAJ from design and development planning, translating business requirements into technical solutions.
- Built reusable components across modules for scheduling, reporting, field tracking, and operational dashboards.
- Worked as backup backend developer during resourcing gaps, in a 20+ module Java 17 codebase (Dropwizard, with Spring Boot on the enterprise integration service) built through GitLab CI.
What I decided, and why
Built for the shared core, not for one tenant
Every tenant wants something slightly different, and every divergence you allow becomes something maintained forever across all the others. When I built portal screens I kept tenant-specific behaviour at the edges and pushed anything reusable back into the shared core, so custom builds stayed thin.
Reusable components before new screens
Rather than building each module’s screens independently, I built a set of modular UI components used across scheduling, reporting, field tracking and operational dashboards. It slowed the first few screens down and paid back on every screen after them.
Protected the UAT date by managing scope, not quality
For FORCE DSS the test-ready date was fixed and external. My job was to make sure every committed portal function was complete and genuinely testable on that date — which meant raising anything at risk early rather than shipping something that would fail in front of the client.
Joined Ranhill SAJ at design stage, not at handover
Being in design and development planning meant the client’s business requirements became technical decisions before any code existed. Mismatches surface far more cheaply in a planning session than halfway through a build.
Stayed useful across the stack
When backend resourcing was short I worked in the Java services rather than waiting for someone to free up. Being able to move between the portal and the backend kept delivery moving during the gaps.
The hard part
FORCE is not software anyone uses at a desk. Technicians use it on phones while doing physical work, often with patchy coverage, and dispatchers need to know where every crew is right now. When a workforce platform misbehaves the cost is not a frustrated user — it is a water repair or a broadband installation that does not happen. That changes how you treat defects during test cycles: the question is never only whether a screen renders, but whether a crew can still do their job when something fails.
The outcome
- Delivered the FORCE DSS frontend test-ready on the committed date.
- Supported testing and validation through official project sign-off.
- Contributed to shared and custom tenant portals that help field teams coordinate jobs, track activity, and monitor service performance.
What I’d do differently
- AngularJS and Webix.js are both past their prime. The platform is stable, but much of this work sits on frameworks nearing end of life — which is exactly what the TMFORCE modernisation set out to address, and why I moved to Angular 22 on my next project.
- More automated coverage on the portals. Testing ran largely through manual UAT cycles; the reusable components in particular were good candidates for unit tests I did not write at the time.
- Better written records of what differs between tenants. Custom builds accumulate small divergences, and that knowledge tends to live in the people who built them rather than anywhere someone else can read.
Inside FORCE
