Maximo Mobile at Scale: Data Sets, Sync Policies, and the Field Service Workflow That Actually Works

Maximo Mobile at Scale: Data Sets, Sync Policies, and the Field Service Workflow That Actually WorksMaximo Mobile is not Maximo Anywhere. Anywhere was a hybrid app that talked to a MobileFirst server through an adapter layer. Mobile is a REST-native client over the same Manage APIs you already run, with an offline-first design that treats the device as the primary workspace. Anywhere was discontinued at MAS 8.9 and is not supported through MAS 9. If you are still running Anywhere, the migration question is not optional.

What works in Maximo Mobile at scale is not the same as what works in a 50-user pilot. The data set definitions that work for ten technicians in one location fall over for 200 technicians across twelve sites. The sync policies that seem fine in development create chaos in production when the network drops out for eight hours during a storm. The field-tested patterns that have emerged over the past twelve months of MAS 9.x deployments are concrete and worth replicating.

This article walks through the Maximo Mobile architecture as it stands in mid-2026, the data set scoping rules that prevent the most common sync failures, the sync policy patterns that match real-world field conditions, and the conflict resolution rules that keep work moving when the device and the server disagree.

The Maximo Mobile Architecture

Maximo Mobile is built on three concepts that explain almost everything about how it works. Understanding them is a prerequisite for designing data sets and sync policies that hold up in production.

The first concept is the REST-backed data set. Where Anywhere used bespoke adapters, Mobile pulls data through object structures over the standard Manage REST APIs. The object structures are the same ones the desktop uses. The validation rules are the same. The mobile app is simply another consumer of them. There is no mobile-specific data layer and no parallel business logic. This is the architectural reason the Anywhere-to-Mobile migration is mostly a configuration exercise rather than a rewrite.

The second concept is the sync engine. The sync engine moves data between the server and the device. Sync policies govern how the sync happens: what refreshes, how often, how much, and how conflicts are handled. Sync is incremental and scoped. A technician pulls the work orders, assets, locations, job plans, domains, and failure codes relevant to their assignment, work group, or location, not the entire database.

The third concept is the local device database. Synced data lands in a local SQLite database on the device. From there, the technician works fully offline. Every change (a status update, a labor record, a material issue, an inspection result) queues locally and is reconciled on reconnect, with conflict resolution applied per the sync policy.

These three concepts are the foundation for everything that follows. If you understand them, you can design data sets and sync policies that match your field conditions. If you do not, you will end up with a Mobile deployment that works in the lab and falls apart in the field.

What the Technician Sees

The Maximo Mobile Technician app is the role-based app most teams deploy first. It replaces the bulk of what Anywhere's Work Execution app did, with the addition of true offline-first behavior and a far simpler deployment model. The technician opens to an assigned work order list, fed from the supervisor or graphical assignment process, filterable, and fully usable offline once synced. From there, the app supports the full field workflow.

The technician can start and stop work, which drives work order status on the device. They can record labor actuals, which are written back as LABTRANS records. They can issue and return materials against the work order. They can capture meter readings for assets and locations. They can complete tasks on the job plan. They can record failure codes (class, problem, cause, remedy) against the same taxonomy the desktop uses. They can attach photos and documents via DOCLINKS. They can launch a linked inspection inline without leaving the work order.

All of this runs against the local device DB, which holds the work orders, assets, locations, job plans, domains, and failure codes needed for the assignment. Offline changes queue and resolve conflicts on reconnect. The technician never has to think about connectivity.

A feature channel update in 2026 added the ability for technicians to enter meter readings on work orders created offline. This is a meaningful enhancement because it removes a prior limitation where offline-created records could not have meter data attached until sync. For utilities and other meter-heavy operations, this is a real productivity gain.

Data Set Scoping: The Field-Tested Rules

The most common Maximo Mobile failure is bad data set scoping. A data set that is too large makes the initial sync slow and uses too much device storage. A data set that is too narrow means the technician does not have the data they need in the field. The field has settled on a set of scoping rules that work for most operations.

Rule 1: Scope by Assignment, Not by User

The most common scoping mistake is to scope data sets by user. "Give this technician everything they might need" produces bloated data sets and slow syncs. The correct pattern is to scope by assignment. The technician gets the work orders assigned to them, the assets linked to those work orders, the locations for those assets, the job plans for those work orders, and the failure codes for those asset classes.

A typical data set for an individual technician holds 250 to 400 work orders, plus their linked assets (up to 1,200 records) and a rolling two-week inventory cache of around 800 line items. These numbers are not magic; they are what the field has converged on as the right balance between coverage and performance.

Rule 2: Scope Inventory by Storeroom, Not Globally

Inventory is the biggest data volume risk. A global inventory cache of 100,000 items is unusable on a mobile device. The correct pattern is to scope inventory by storeroom. The technician gets the items in the storerooms they are likely to draw from. For most operations, that is one to three storerooms per technician.

The inventory cache should also be rolling. Two weeks of historical issues is enough for the technician to know what they typically use. Older history can be looked up on the desktop if needed.

Rule 3: Scope Job Plans by Asset Class

Job plans are another volume risk. A site with 5,000 job plans will not fit comfortably on a mobile device. The correct pattern is to scope job plans by asset class. The technician gets the job plans for the asset classes on their assigned work orders. This typically narrows the set to a few dozen plans rather than thousands.

# Example data set configuration (conceptual YAML)
dataSet:
  name: TECHNICIAN_ASSIGNED
  scopeBy: assignment
  objects:
    - name: WORKORDER
      filter: "ASSIGNEE=:user and STATUS in ('APPR','INPRG','WSCH')"
      includeRelated:
        - ASSET
        - LOCATION
        - JOBPLAN
        - FAILURELIST
      maxRecords: 400
    - name: ASSET
      filter: "ASSETNUM in (select assetnum from workorder where assignee=:user)"
      maxRecords: 1200
    - name: INVENTORY
      filter: "STOREROOM in (:assigned_storerooms)"
      maxRecords: 800
      lookbackDays: 14
    - name: JOBPLAN
      filter: "JPNUM in (select jpnum from workorder where assignee=:user)"
      includeFailureCodes: true
      maxRecords: 100
  domains:
    - FAILURECODE
    - PRIORITY
    - WORKTYPE
  offlineRetentionDays: 30

Rule 4: Define Lookback Windows for History

The technician does not need the full asset history. They need the recent history. Define a lookback window (typically 90 to 180 days) and scope the work history, failure history, and inspection history to that window. Older history is available on the desktop.

Rule 5: Validate with Real Field Data

The data set sizing numbers above are starting points. Every operation is different. Validate your data set definitions against real field data before you go live. Take a snapshot of production data, simulate a technician's workload, and measure the data set size, the sync time, and the storage usage. Adjust the scoping until the numbers are in the right range.

Sync Policies: The Patterns That Match Real Field Conditions

The sync policy determines when sync happens, how much data syncs, and how conflicts are resolved. The default policy in Maximo Mobile is to sync on login and on reconnect, with delta sync during active sessions. This default is fine for an office but inadequate for a plant with poor cellular coverage.

Pattern 1: Scheduled Sync at Known Connectivity Points

For operations where the technician returns to a known location at known times (end of shift, meal break, mid-day at a depot), configure scheduled sync to run when the device detects it is at that location. This gives you predictable sync windows without requiring the technician to remember to sync manually.

SHIFT_BASED_SYNC

SCHEDULED 0 0 6,14,22 * * ?

LOCATION_BASED

DEPOT_NORTH DEPOT_SOUTH

NETWORK_AVAILABLE WIFI

INCREMENTAL LAST_WRITE_WINS 3 60

Pattern 2: WiFi-Only Sync for Large Data Sets

For operations where cellular data is expensive or capped, configure the policy to only sync over WiFi. This is common for utility crews who return to a depot at the end of the day and sync over the depot WiFi. The trade-off is that real-time visibility is delayed until the device is back on WiFi.

Pattern 3: Conflict Resolution Rules by Object

The default conflict resolution is last-write-wins. This is fine for most fields (status updates, labor records, material issues) but not appropriate for all. Work order priority, asset criticality, and safety flags should never be overwritten by the device. Configure per-object conflict resolution rules.

The recommended pattern is to define conflict resolution by object and field. Status, labor, materials, and notes use last-write-wins. Priority, criticality, and safety flags use server-wins. Failure codes use a manual review queue.

Pattern 4: Partial Sync When Connectivity Is Intermittent

For operations in remote areas with intermittent cellular coverage, configure partial sync. The device detects that connectivity is available but unreliable and syncs the highest-priority data first (open work orders, status updates, safety records) and lower-priority data second (inspection results, meter readings, attachments). This ensures the most critical data makes it through even when the connection drops mid-sync.

Pattern 5: Conflict Review Queue

Some conflicts should not be auto-resolved. If a technician changes a work order priority offline and the planner changes it on the server before sync, the conflict should go to a review queue rather than being silently overwritten. Configure the sync policy to write conflicts to a review table and notify a supervisor. The supervisor resolves the conflict and the resolution syncs back to the device.

The Field Service Workflow That Actually Works

The Maximo Mobile Technician app supports a complete field workflow, but the workflow only works if the underlying business process is designed for offline-first operation. The most common operational mistake is to take a workflow designed for connected desktop operation and force it onto a disconnected mobile device.

Workflow Pattern 1: Pre-Assignment, Not Real-Time Assignment

Real-time assignment (where the supervisor assigns a work order to a technician mid-shift) does not work in offline-first. The technician may not sync for hours, and the work order may not appear on their device until they sync. The correct pattern is pre-assignment. The supervisor assigns work orders before the shift starts. The technician syncs at the start of the shift and has the full workload on their device.

For operations that need mid-shift assignment (emergencies, breakdowns), use a separate "urgent" channel. The supervisor can mark a work order as urgent and trigger an immediate push to the assigned technician's device. The technician is notified, syncs immediately if connectivity is available, and picks up the work.

Workflow Pattern 2: Document at the Point of Work, Not at the End of Shift

The worst mobile workflow pattern is the technician who does the work, drives back to the depot, and then tries to remember what they did and enter it into the system. This produces inaccurate data and unhappy technicians. The correct pattern is to document at the point of work. The technician records labor, materials, and notes as they do the work, on the device, in real time.

The Maximo Mobile app supports this with field-level validation, attachment capture, and barcode scanning. The technician opens a work order, starts the work, scans the asset barcode to confirm the right asset, records labor hours as they accrue, scans materials as they issue them, captures photos at each step, and completes the work. The documentation is complete when the work is complete.

Workflow Pattern 3: Inspections Inline, Not Separate

A common anti-pattern is to send a technician to do a work order and then send them back to do an inspection on the same asset. The correct pattern is to launch the inspection inline from the work order. The technician completes the work, then runs the linked inspection form on the same visit. The work order completion and the inspection result are recorded together.

Workflow Pattern 4: Failure Coding at the Point of Discovery

Failure codes are notoriously under-recorded because technicians are asked to record them after the fact. The correct pattern is to capture failure codes at the point of discovery. When the technician diagnoses a failure, they record the class, problem, cause, and remedy on the device before they leave the asset. The failure data feeds Maximo Health and Maximo Predict, which improves the AI models over time.

Workflow Pattern 5: Photo and Attachment Capture as Default

Photos and attachments are the most under-used mobile capability. The correct pattern is to make attachment capture the default. The technician takes a photo of the asset before work starts, photos during the work (especially of any anomaly or unexpected condition), and a photo after work is complete. Attachments are uploaded on sync and stored in DOCLINKS. This creates an auditable record that pays dividends when the work is reviewed months later.

Common Pitfalls in Maximo Mobile Deployments

The teams that have published the worst Maximo Mobile post-mortems share several common patterns. The pitfalls are predictable and avoidable.

Pitfall one is treating Mobile like Anywhere. The Anywhere migration is not a 1:1 port. Anywhere's adapter layer, MobileFirst server, and hybrid build pipeline do not exist in Mobile. The architecture is different. The deployment model is different. The configuration is different. Teams that try to recreate their Anywhere configuration in Mobile end up with a hybrid that does not work well.

Pitfall two is over-scoping the data set. The instinct is to give the technician everything they might possibly need. The result is a data set that takes hours to sync, uses gigabytes of device storage, and times out before the technician can leave the parking lot. Scope tight. Expand later if needed.

Pitfall three is under-scoping the data set. The opposite pitfall is to scope so tightly that the technician does not have what they need in the field. The result is calls to the supervisor, manual data entry after the fact, and a frustrated technician who stops using the app. Validate with real users in real conditions before broad rollout.

Pitfall four is ignoring conflict resolution. The default last-write-wins works for most cases but not all. Conflicts on priority, criticality, and safety flags should never be silently overwritten. Conflicts on failure codes should go to a review queue. Configure per-object conflict resolution before go-live.

Pitfall five is not testing offline. The most common failure mode is a deployment that works in the lab (where connectivity is reliable) but falls apart in the field (where connectivity is unreliable). Test offline. Disable WiFi and cellular on the test device and use the app for a full shift. That is the only way to validate the offline behavior.

Practical Implications

For mobile architects, the practical implication is that the data set and sync policy design is the most important work in a Maximo Mobile deployment. The application configuration is straightforward. The device provisioning is straightforward. The hard part is getting the data scoping right.

For field service managers, the implication is that the workflow design matters as much as the technology. A mobile deployment that tries to support a connected workflow on a disconnected device will fail. Design the workflow for offline-first operation, with pre-assignment, point-of-work documentation, and inline inspections.

For IT operations, the implication is that conflict resolution needs to be configured before go-live, not after. The default is fine for some fields but not for others. Make the conflict resolution decisions explicit and document them.

For the business, the implication is that Maximo Mobile at scale requires investment in the field workflow. The technology is ready. The operational discipline is the bottleneck.

Bottom Line

Maximo Mobile at scale is a solved problem, but only if you treat the data set scoping and sync policy design as the primary work. The architecture is sound. The application is reliable. The conflict resolution is configurable. The pieces work together when they are configured correctly.

The teams that succeed with Maximo Mobile at scale are the ones that scope data sets by assignment, configure sync policies for their actual field conditions, design workflows for offline-first operation, and validate everything with real users in real conditions before broad rollout.

The teams that fail are the ones that treat Mobile like Anywhere, over-scope the data set, ignore conflict resolution, and do not test offline. These are predictable failures with predictable fixes.

If you are running Anywhere, the migration to Mobile is overdue. Anywhere is unsupported past MAS 8.9. If you are running Mobile but struggling with sync times or storage usage, the answer is almost always in the data set scoping. Start there.