Designing Offline Mobile Flows That Technicians Trust (and That Don't Bankrupt Your Storage Budget)

A field service organization runs on one question: can my technician execute the work I just dispatched, even if the truck is in a dead zone? Everything else — the schedule, the geospatial layer, the parts inventory, the safety forms — exists to make that answer yes.

The Maximo Mobile + Maximo Optimizer stack is built to answer yes. The May 27, 2026 release of Optimizer 9.1.12 is the latest in a steady cadence that has been improving dispatch realism, what-if analysis, and the breadth of business rules the engine can honor. But the offline experience on the technician's device is still the part of the stack that requires the most design care, and the most willingness to say "no" to features that look good in a demo.

What Optimizer 9.1.12 actually changed

The 9.1.x line of Optimizer has been about three things:

1. More accurate what-if analysis. The April 2026 Feature Channel moved the algorithm from the older heuristic to a Radial Basis Function (RBF) model. That change shipped into the GA line and is now the default in 9.1.12. The practical effect: when a dispatcher asks "what happens if I add Joe to the route and pull Sara off," the optimizer returns a scenario that is meaningfully closer to what the optimized schedule would actually look like, not just a fast approximation.
2. Broader business-rule coverage. The 9.1 line added first-class support for overtime management, crew qualification checks, technician service-time utilization, external assignment handling, and emergency work-specific rules. That last one is the most consequential — emergency work used to short-circuit the optimizer, which meant dispatchers had to manually re-sequence the whole day when a priority job came in. 9.1 can now treat emergency work as a constraint and re-optimize the rest of the schedule around it.
3. Deployment flexibility. Optimizer can now run on Single Node OpenShift (SNO), which is the right answer for sites with limited infrastructure footprint or for customers who want a dedicated dispatch cluster.

There were also under-the-hood improvements to the Large Neighborhood Search (LNS) algorithm for high-volume dispatch problems. If you are running Optimizer across thousands of work orders a day, the LNS improvements translate directly to faster solve times and more iterations per scheduling window.

The mobile offline problem, restated

The promise of Maximo Mobile is that a technician opens the app, sees their work, executes it, captures data, and syncs when they are back in coverage. The reality is more subtle:

• The technician may be in a coverage dead zone for 20 minutes or for 8 hours.
• The work may generate new records (a follow-up work order, an inventory issue, a safety observation) that need to be visible to the rest of the operation as soon as the device is back online.
• The technician may be using a device with limited storage — a 64 GB phone, not a laptop.
• The technician may not be technical. The offline experience cannot require them to "manage" their local cache.

A bad offline design shows up in three places: a sync storm when the device comes back online, a corrupted local database when two records conflict, and a technician who doesn't trust the app because "the work wasn't there this morning."

The five design rules for offline work execution

1. The local dataset is a curated view, not a sync of everything

This is the biggest design mistake. The temptation is to give the device "everything assigned to me, ever." That is wrong on three dimensions:

• It explodes the local database.
• It makes sync take longer with every record change.
• It puts records on the device that the technician should not be able to act on without an updated record from the server.

The right pattern is a role-scoped, time-bounded, status-filtered query that defines the work window. A typical profile:

• Status: APPR (approved), INPRG (in progress), WSCH (waiting on scheduling)
• Scheduled start: between now − 7 days and now + 14 days
• Assigned to: the current user, or to a crew the user is a member of
• Site: the user's primary site (with an option to switch sites for the day)

That query is published to the device, refreshed when the device is online, and treated as authoritative for offline work. Records outside that query are not on the device. If the technician needs to see a record that isn't in their window, that is a coverage-area workflow — they go online, look it up, and act.

2. Conflict resolution is a server-side decision, not a device-side one

When a technician updates a work order offline, the device stores the change locally with a timestamp. When the device syncs, the server applies the change. But what if the work order was updated server-side while the device was offline?

The temptation is to do device-side conflict resolution: "the device wins" or "the server wins" or "merge by field." All of these are wrong. Conflict resolution is a business decision that depends on which field changed. Examples:

• Status change on server (e.g., from APPR to CANCELLED). The device update should be rejected. The technician needs to know the work was cancelled.
• Status change on device (e.g., from APPR to INPRG). The server should accept it. The technician started the work.
• Field update on both sides (e.g., the technician noted a problem code, the planner updated the priority). Both updates should be accepted, but the technician's update should win for the field they own (problem code) and the server's update should win for the field the planner owns (priority).

The right pattern is a field-level ownership map that lives in the integration layer (MIF or a custom object structure handler) and decides, per field, who wins. This map is part of your business process documentation, not your code. The code reads the map.

3. Storage is finite — design the eviction policy before you need it

A 64 GB phone will fill up faster than you think, especially with attached photos, videos of asset conditions, and signed PDF inspection forms. The eviction policy needs to be designed up front, not after a technician complains that the app is slow.

A workable default:

• Active work window: 30 days. Records older than 30 days are evicted from the device (they're still on the server).
• Completed records with no attachments: evicted after 7 days.
• Completed records with attachments: kept on device for 30 days, then the attachment is evicted but the record metadata stays.
• Drafts (uncommitted work): kept indefinitely until submitted or manually deleted.

The mobile app should expose this as a "Storage" screen the technician can use to free up space, and a background task that prunes automatically.

4. Geospatial is a hint, not a hard constraint

Maximo Mobile + Maximo Spatial gives you the ability to render assets, routes, and work locations on a map. The 9.1 line added tighter integration between the Optimizer's output and the geospatial layer: the dispatcher's optimized schedule can be rendered as a route on the technician's device, with travel-time estimates.

The design rule: the map is a hint about order, not a constraint on order. Technicians will deviate from the optimized order for reasons the optimizer doesn't know about (a customer call, an equipment issue, a safety concern). The mobile app should make it easy to deviate and re-sync the actual order back to the server, not fight the technician about it.

5. Sync is observable

When the device comes back online, the sync should be visible. The technician should see:

• A progress indicator with a count of records syncing
• A clear "synced as of HH:MM" timestamp
• A list of any records that failed to sync, with a reason

This sounds like polish, but it is actually the most important trust-building feature in the offline flow. The technician who sees "all records synced, you're current" trusts the app. The technician who sees a spinner with no end trusts nothing.

Optimizer dispatch patterns that work in 2026

Two patterns from recent Optimizer deployments are worth highlighting:

Pattern 1: Emergency work as a constraint, not an override

The classic dispatch pattern was: optimizer produces a daily plan, the dispatcher executes it, an emergency work order comes in, the dispatcher manually re-sequences the rest of the day. That manual re-sequencing is exactly the work the optimizer should be doing. With 9.1's emergency-work business rules, the dispatcher can insert the emergency work order and ask the optimizer to re-optimize the rest of the day around it. The result is a new plan in seconds, not a manual re-shuffle in minutes.

Pattern 2: What-if analysis for staffing decisions

The RBF-based what-if engine is fast enough to run interactively. A dispatcher considering "what if I move Jose from the west zone to the east zone for the second half of the day" gets an answer in seconds. That makes what-if a real-time decision-support tool, not a quarterly planning exercise. The pattern that works: dispatchers run 2–3 what-if scenarios per shift, compare the results, and pick the one that closes the most high-priority work.

The integration between Optimizer and Mobile

The 9.1 line preserves the contract between Optimizer and the rest of the suite: Optimizer publishes its dispatch plan as records, and Mobile reads those records through the standard object structures. There is no magic. If the dispatch plan is not visible in the mobile app, the most common cause is a filter on the object structure or a publish channel that is not running.

The two checks that catch 80% of these issues:

• Confirm the MXWOInterface (or your equivalent) object structure includes the assignment fields Optimizer writes to.
• Confirm the publish channel that mirrors Optimizer's output to the device query is enabled and its cron task is healthy.

Where this is going

Two trends to watch through the rest of 2026:

• Voice and computer vision in the mobile app. MAS 9.2 is positioned to bring AI to the frontline in a bigger way — hands-free voice interaction for inspections, computer vision for asset condition capture. The offline design rules above still apply; the local dataset still needs to be curated, the storage still needs to be managed.
• Optimizer + agentic workflows. When the assistant evolves from "answer a question" to "do a task," one of the natural tasks is "re-optimize the rest of today's schedule given this new work order." That is exactly the use case the 9.1 emergency-work rules were built for, and the 9.2 agentic layer will make it conversational.

For now, the work is the same: design the offline flow carefully, scope the local dataset ruthlessly, make sync observable, and treat the optimizer's plan as a starting point, not a contract.