Having worked hands-on with ClickSoftware 8.x, migrating to Salesforce Field Service (SFS) is not a lift-and-shift exercise—it’s a fundamental re-architecture. ClickSoftware was extremely powerful, but that power lived in deeply customized rules, policies, and extensions that tightly controlled scheduling and dispatching.
With Click 8.x reaching end-of-life (around 2023–2024), developers are forced to confront technical debt that can no longer be justified. Salesforce Field Service carries forward Click’s optimization DNA, but the way it’s implemented is very different. Direct rule manipulation, batch schedulers, and Java extensions give way to Apex, Flows, policies, and near real-time optimization.
From the ground, the biggest shift for developers is mindset:
- Stop chasing 1:1 functional parity
- Redesign scheduling logic using declarative-first patterns
- Accept that some legacy behavior should be retired, not replicated
Migration is challenging—but it results in a platform that is more scalable, observable, and supportable than Click ever was.
Real-World Use Case: Waste Collection Council Migration
Background
A local waste collection council was running ClickSoftware 8.x to manage residential waste, recycling, and green waste pickups. The system handled:
- Zone-based routing
- Fixed pickup schedules
- Missed-bin requests
- Ad-hoc bulk waste collections
- Contractor workforce management
The Click platform was heavily customized and nearing end-of-life, with growing support and integration risks.
Migration Goals
From a developer perspective, the council wanted to:
- Replace Click 8.x with Salesforce Field Service
- Reduce custom scheduling code
- Improve visibility for customer service teams
- Enable near real-time reallocation of jobs
Salesforce Field Service Design
Data Model Mapping
- Click Activities → Salesforce Work Orders
- Scheduled pickups → Service Appointments
- Collection crews → Service Resources
- Council zones → Service Territories
- Missed bin requests → Case → Work Order flow
Scheduling & Optimization
- Fixed weekly collections modeled using recurring work orders
- Skill and vehicle constraints handled via resource skills and operating hours
- Route optimization configured using SFS optimization policies
- Emergency or missed-bin jobs inserted with high-priority appointments
Integrations
- Council CRM and ratepayer systems integrated via REST APIs
- Bin sensors (where available) triggered service requests through platform events
- Completion status synced back for billing and compliance reporting
Mobile Execution
- Crews used Salesforce Field Service Mobile
- Offline support enabled for low-connectivity areas
- Simple mobile flows for “collected”, “blocked”, or “missed” statuses
Key Developer Learnings
- Legacy Click routing logic had to be simplified and redesigned
- Historical schedule data was not migrated—only open and future jobs
- Performance improved once batch scheduling was replaced with incremental optimization
- Supportability improved due to reduced custom code
Outcome
The council achieved:
- Faster response to missed collections
- Better visibility across customer service and field teams
- Reduced reliance on niche ClickSoftware expertise
- A future-proof, cloud-native FSM platform
Final Thought
For developers who worked deeply in ClickSoftware, Salesforce Field Service migration is painful—but necessary. In public-sector use cases like waste collection, the real win is not replicating old behavior, but delivering a simpler, more resilient service model that councils can support for the next decade.
