Maximo Mobile 9.1 in Production: Building an Offline-First Field Service Operation

Maximo Mobile in MAS 9.1 is not an incremental update. It is a full rewrite of the mobile experience, replacing the legacy Anywhere and MobileFirst platforms with a modern, offline-first architecture built on the Maximo Application Framework (MAF, also called Graphite). The shift eliminates the mobile middle tier, simplifies integration, and gives field technicians a faster, more capable experience. But the new architecture also introduces a new set of operational decisions. Data sync policies, conflict resolution, query scoping, and inspection form design all behave differently in the Graphite model.

This article walks through the production deployment of Maximo Mobile 9.1. It covers the architecture shift, the data sync strategy, the new inspection and GIS features, the HSE Incident Reporter app, and the operational patterns that determine whether your mobile rollout succeeds or stalls.

The Architecture Shift: Anywhere to Graphite

The single biggest change in Maximo Mobile 9.1 is the removal of the mobile middle tier. In the Anywhere era, mobile requests flowed from the device to a dedicated MobileFirst server that translated Maximo object structures into device-friendly payloads, then forwarded to the Maximo application server. The Anywhere server was a separate WebSphere instance that had to be sized, secured, patched, and maintained. It had its own clustering story, its own failure modes, and its own integration patterns.

In MAS 9.1, the mobile middle tier is gone. The Maximo Mobile shell app on the device talks directly to the Maximo Manage REST APIs. The same object structures, the same validation rules, the same business logic that the desktop uses are consumed by the mobile app. There is no mobile-specific data layer, no parallel validation, no separate business rules engine. The mobile app is simply another consumer of the Manage REST surface.

This change has profound operational implications. The MobileFirst server, its custom adapters, and its bespoke integration code are now decommissioned. Anywhere extensions move into object structures, automation scripts, or Maximo Mobile configuration. Custom adapters, where still needed, become standard OSLC or REST integrations against Manage. The skills your team built around MobileFirst clustering, adapter development, and anywhere-specific debugging are no longer the relevant skills. The new skills are REST API tuning, object structure design, and Graphite application configuration.

The deployment model is also new. The Maximo Mobile shell is a native app distributed through the Apple App Store and Google Play. The shell is a React-based runtime that downloads Graphite application definitions from the Manage server at first login. Application updates are pushed as new Graphite bundles, not as new app store releases. This means workflow changes can be deployed in days rather than weeks, and there is no app store review process to navigate. The shell itself updates only when the runtime requires a change.

Offline-First: The Local SQLite Database

Maximo Mobile 9.1 is offline-first by design. When a technician first logs in, the shell authenticates against Manage, downloads the assigned Graphite applications, and synchronizes a scoped slice of data into a local SQLite database. The technician can then work indefinitely offline. Every change, whether a status update, a labor record, a meter reading, or a photo attachment, is queued locally and synchronized when connectivity returns.

The local SQLite database is the source of truth for the technician's working session. The technician sees data immediately on every action, with no spinners and no "syncing" messages. The user experience is identical online and offline. This is a major improvement over the Anywhere model, where offline behavior was a degraded mode rather than the default.

The technical implication is that you must design your data sync policies carefully. The initial sync payload determines what data the technician can work with offline. The incremental sync delta determines what changes flow back to Manage. The conflict resolution policy determines what happens when the same record is changed on the device and on the server. Get any of these wrong, and the technician either cannot do their job offline, or they overwrite work done by other users.

Designing Data Sync: Scoping, Frequency, and Conflict Resolution

The Mobile Admin app, which is new in MAS 9.1, centralizes the configuration of data sync. From the MAS Administration page, administrators can configure mobile-specific properties, define data synchronization settings, manage preloaded databases, and identify active mobile users. This is a major improvement over the Anywhere model, where these settings were scattered across multiple applications and configuration files.

The first sync decision is data scope. The Mobile Data Manager application allows you to define saved queries that determine what data is pulled to each device. The recommended pattern is to scope by assignment: pull work orders, assets, locations, job plans, and failure codes relevant to the technician's work group, labor code, or assigned location. Avoid the temptation to sync everything. A typical technician needs 50 to 200 work orders, 100 to 500 assets, and the related failure codes and job plans. A larger payload increases the time to first sync, increases storage on the device, and increases the risk of stale data.

A sample saved query for a rotating asset crew might look like this:

workorder.status in (APPR, INPRG, WAPPR)
and workorder.assignedowner = :user
and workorder.worktype in ('PM', 'CM', 'EM')
and workorder.scheduledate <= add_days(:today, 14)

This query pulls approved, in-progress, and waiting-approval work orders assigned to the current user, scheduled within the next two weeks. The add_days function is relative to the device's current date, so the sync window moves with the calendar. The 14-day window is a tunable parameter; shorter windows reduce payload size, longer windows improve flexibility.

The second decision is sync frequency. The default in MAS 9.1 is automatic background sync with manual override. The shell detects connectivity and runs a delta sync when the network is available. Sync frequency is configurable; hourly is a common default, with manual triggers available for technicians who need immediate sync. Sync priority can be FIFO, priority-based, or critical-first. For most operations, priority-based sync (pushing high-priority work orders first) is the right balance.

The third decision is conflict resolution. When the same record is changed on the device and on the server between syncs, a conflict is detected. The default policy in MAS 9.1 is server wins with an error queue for review. This is the safest default, but it can frustrate technicians who lose offline work. For specific record types, a client-wins or last-write-wins policy may be more appropriate. For example, meter readings should typically use client wins, because the technician's reading is the authoritative value. Status changes should typically use server wins, because the server is the system of record for workflow state.

A common error code during sync is 409 Conflict, which indicates the record state on the server changed while the technician was offline. For example, a status moved from APPR to INPRG by another user. The 409 error is captured in the error queue, and the technician is notified. The data is preserved locally; the conflict is resolved by re-reading the record, applying the technician's changes to the updated state, and resubmitting.

Inspection Form Builder: Authoring Once, Running Anywhere

The Inspection Form Builder was modernized in MAS 9.0 and extended in 9.1. The builder runs on the same Maximo Application Framework as Maximo Mobile, which means a form authored on the desktop is the same form that executes on a phone. There is no separate mobile design step, no drift between the desktop definition and the mobile experience. Build once, run anywhere.

The builder provides drag-and-drop authoring with improved hover behavior, conditional logic, formula support, and the ability to attach documents, videos, and other media to questions. In 9.1, inspection forms were added to the Incidents application and the Audit and Surveys application, so the form-building investment pays off across more of Manage, not just inspections.

For inspection designers, the key decisions are question types, conditional logic, scoring, and the integration with Maximo Visual Inspection. Question types include text, numeric, date, single-choice, multi-choice, signature, photo, document, and (in 9.2) geolocation, QR/NFC/barcode, and calculated responses. Conditional logic determines which questions appear based on prior answers. Scoring determines how the form is graded, and how the result drives follow-up work.

A particularly powerful 9.1 feature is the integration with Maximo Visual Inspection. If you have Visual Inspection deployed, you can configure an inspection form question to automatically analyze attached images using a trained MVI model. For example, a corrosion inspection question can include a photo upload, and the MVI model can automatically classify the severity of the corrosion visible in the photo. The technician sees the AI's assessment immediately, along with the option to override it.

GIS and Maps: Spatial Workflows in the Field

GIS-based workflows are a major theme in Maximo Mobile 9.1. The map view is now embedded in work order creation, asset lookup, and the new HSE Incident Reporter. Technicians can long-press on a map to create a work order at those GIS coordinates. They can preview existing incidents from a map, or add a new incident associated with an asset or location. The map view is fully functional offline, with tiles cached locally and the ability to record points, lines, or polygons.

The practical implications are significant. Field crews no longer need to know an asset number to create a work order. They can drive to a location, see the asset on the map, and create a work order directly. This is especially valuable in industries with spatially distributed assets, such as utilities, transportation, and civil infrastructure. The same workflow that required a desk lookup in the desktop era now happens in seconds from the field.

The configuration work to enable GIS workflows is non-trivial. You need the GIS data loaded into Manage (typically through the Spatial asset module), the map tile server configured, the layer mappings defined, and the long-press behavior enabled. The MAS Spatial application provides a centralized configuration surface. The investment is worth it; the productivity gain for field crews is measurable, often reducing work order creation time by 50 percent or more.

The HSE Incident Reporter: A New Safety App

The HSE Incident Reporter app is a new addition in Maximo Mobile 9.1. It enables field staff to report health, safety, and environmental incidents directly from their mobile device. The reporter supports immediate incident reporting, photo attachments, GPS location capture, and free-text descriptions. The data flows into Maximo Manage and triggers the configured escalation workflows for safety incidents.

The HSE app is configured as a separate Maximo Mobile application, distinct from the standard Technician app. It can be deployed to all field users, including those who do not normally execute work orders, such as contractors, supervisors, and safety officers. The incident creation flow is streamlined for speed, recognizing that safety incidents are time-sensitive and that the reporter may be under stress.

The incident data captured by the app is the same data that the desktop Incidents application uses. The form is the same, the validation is the same, the escalation is the same. This is one of the most important consequences of the Graphite architecture: every form defined in Manage can be exposed on the mobile device without rewriting it.

Common Pitfalls and Field-Tested Patterns

The first pitfall is over-syncing. Teams that default to syncing all work orders, all assets, and all locations for every user end up with devices that take 30 minutes to perform the initial sync. Technicians leave the device on the charger overnight to "charge and sync." This is unacceptable. Scope the sync to the user's assignment, and tune the window to two to four weeks of work.

The second pitfall is ignoring device storage. Maximo Mobile downloads attachments up to 200 MB in size (the new limit in 9.1, up from 50 MB in earlier versions). A crew that takes photos for every work order can accumulate several GB of local data. The shell manages local storage by purging old records after sync, but you need to ensure the device has enough free space. A 64 GB device is the practical minimum; 128 GB is recommended for crews with heavy photo use.

The third pitfall is skipping user training on offline behavior. Technicians who do not understand that their work is queued locally may close the app expecting the work to be saved. It is saved, but it is not on the server until sync. Train users to recognize the sync status icons, to manually trigger sync before critical handoffs, and to read conflict notifications. Adoption suffers when users lose trust in the data after a sync conflict.

A field-tested pattern is to designate shared devices. MAS 9.1 allows you to mark a device as shared, which disables biometric and PIN login at the device level. This is useful for crews that hand off a single device between shifts. The shared device mode also disables offline login; users can only authenticate while online, which prevents the previous user from leaving data on the device for the next user.

Another field-tested pattern is to use push notifications sparingly. MAS 9.1 supports extended push notifications including background data synchronization. The temptation is to push everything: every new work order, every status change, every comment. The result is notification fatigue. Technicians ignore all notifications, including the critical ones. Configure push notifications for high-priority events only, and use the in-app feed for routine updates.

Practical Implications

For administrators, Maximo Mobile 9.1 means a new set of operational surfaces. The Mobile Admin app, the Mobile Data Manager, and the Inspection Form Builder are the three primary configuration points. The anywhere-era skills around MobileFirst clustering, adapter development, and push notification configuration are obsolete. The new skills are saved query design, sync policy tuning, and conflict resolution configuration.

For field service managers, the offline-first model means rethinking field operations. In the Anywhere era, a technician who lost connectivity had to drive back to a coverage area to enter work. In the offline-first model, the technician can complete the entire day's work without connectivity. The implication is that supervisor rounds, parts requests, and follow-up work can be entered in the field and synchronized at the end of the day. This is a fundamental change in how field operations are measured.

For safety leaders, the HSE Incident Reporter is a major step forward. Safety incidents that would have been reported hours later (after the technician returned to the office) are now reported in minutes, with photos and GPS coordinates. The data quality of safety reports improves, the response time of safety teams improves, and the regulatory compliance posture improves. The investment in deploying the app pays back through faster incident response and more accurate reporting.

For IT teams, the shift to Graphite and the removal of the mobile middle tier simplifies the operational model. There is no MobileFirst cluster to patch, no MobileFirst database to back up, and no MobileFirst-specific security configuration. The mobile device is a thin client that talks to the same Manage REST surface as the desktop browser. Mobile security reduces to device-level MDM policies and Manage-level API key management.

Bottom Line

Maximo Mobile 9.1 is the most capable field service platform that IBM has shipped. The offline-first architecture, the Graphite application model, the centralized mobile administration, the GIS workflows, the Inspection Form Builder, and the HSE Incident Reporter together represent a generational improvement. The cost is the migration from Anywhere, the decommissioning of the mobile middle tier, and the operational learning curve for sync policies and conflict resolution.

The path forward is clear. Decommission the MobileFirst server. Remove Anywhere extensions. Configure Maximo Mobile through the Mobile Admin app. Define scoped saved queries for data sync. Build out inspection forms. Enable GIS workflows. Deploy the HSE app. Train field crews on offline behavior. Pilot on 10 to 20 users, then expand.

The capability is mature. The documentation is solid. The community has documented patterns. The investment in Maximo Mobile 9.1 pays back through faster work order execution, more accurate data, and a field service operation that can survive any connectivity condition. If you are planning a MAS 9.1 migration, include the mobile rollout in the same project plan. The two initiatives share infrastructure, share skills, and share outcomes.