Designing Maximo Mobile 9.1 for the Real Field: Offline Data, Sync, Security, and Support

A mobile rollout succeeds in the places where architecture diagrams are least accurate: a substation with intermittent service, a plant room behind concrete walls, a remote right-of-way, or a shared tablet changing hands between shifts. In those locations, the field technician experiences one system, but that system spans device storage, local application state, authentication, Maximo Manage data, attachments, maps, integration dependencies, and a synchronization process that may be interrupted at any point.

Maximo Mobile 9.1 adds capabilities that can materially improve field operations. IBM documents automatic refresh after login, centralized controls in Mobile Admin, enhanced delta refresh for transactional child data, meter readings on work orders created offline, multiple-attachment selection, files up to 200 MB on supported iOS and Android devices, timezone selection, GPS-spoofing prevention, shared-device controls, and new ways to generate preloaded databases by site and language. Each feature solves a real problem, but none removes the need to design data scope and operating procedures.

Offline capability should not be framed as “the app works without a network.” It is a distributed-data contract. The team must decide which records a technician receives, what can be created or changed locally, how dependent reference data arrives, how conflicts are handled, how large payloads behave, and how support can distinguish a device issue from a server or data issue. Security adds another dimension because authentication choices suitable for individually assigned devices may not be acceptable for shared devices.

This article provides an implementation method centered on field scenarios and measurable acceptance criteria. It uses documented 9.1 capabilities as building blocks, while avoiding the assumption that enabling every feature automatically produces a reliable experience. The objective is a mobile design that is intentionally scoped, observable, testable under degraded conditions, and supportable by people who are not standing beside the affected device.

1. Model the Offline Data Contract Before Configuring the App

Begin with personas and journeys. A corrective-maintenance technician, inspector, supervisor, warehouse worker, and service-request reporter do not need the same records. For each persona, map a shift from login through travel, work execution, attachments, meter readings, inspections, status changes, and final synchronization. Mark every step that must work offline and every step that can require connectivity.

Translate those journeys into a data contract. Separate data into four groups:

1. Assigned transactional data, such as work orders and service requests.
2. Supporting transactional children, such as tasks, labor, work logs, attachments, and inspection results.
3. Reference data, such as domains, classifications, assets, locations, job plans, labor, and failure codes.
4. Optional context, such as history, maps, documents, or broad asset search.

The goal is not to put Maximo on the device. The goal is to provide the smallest complete set that supports the persona. Excess data increases initial download time, local storage, query cost, refresh duration, and exposure if a device is lost. Too little data causes lookup failures or forces technicians to postpone work.

Define scope rules with business language before implementing queries. For example:

code block

IBM notes that 9.1 can include more child details during delta synchronization, including work-order attachments, asset status updates, work logs, labor records, and inspection reports. Enable those details based on the journey, not by habit. Every additional child collection should have a reason and a volume estimate.

Build a sizing worksheet from representative users. Count assigned work orders, children per work order, reference records, attachment metadata, and binary files. Test heavy but legitimate users, not only the average. A planner temporarily assigned to a large backlog or a crew lead receiving an entire site's work can reveal scope errors that normal test accounts hide.

The data-contract gate is reached when the business owner can state what is available offline, the technical team can show how it is selected, and support can explain what is intentionally absent.

2. Engineer Initial Load, Delta Refresh, and Preloaded Databases Separately

Initial onboarding and daily synchronization are different performance problems. The initial load creates the local database and supporting state. Daily refresh should primarily move changed data. If the design treats every sync like an initial load, devices consume unnecessary time and bandwidth. If it assumes delta refresh can repair an incomplete base, offline functions may fail in subtle ways.

Maximo Mobile 9.1 automatically refreshes device data after login. That is helpful for freshness, but administrators must still control what refresh includes through Mobile Admin and application configuration. Measure refresh under three network profiles: reliable Wi-Fi, ordinary mobile service, and a throttled or unstable connection representative of the field. Capture data volume, elapsed time, retries, device storage growth, battery impact, and whether the user can understand progress.

Preloaded databases can reduce onboarding time by preparing data in advance. IBM documents 9.1 methods to generate and assign preload data for users associated with a site or language. Use preload when the dataset is substantial, many users need similar reference data, or field connectivity makes first synchronization impractical. Govern the preload artifact like a release:

* Record the generation date and source environment.
* Define site and language eligibility.
* Protect the artifact in transit and at rest.
* Set an expiration or regeneration policy.
* Validate the first delta refresh after assignment.
* Test what happens when a user's site or responsibilities change.

A preload is a starting point, not a substitute for synchronization. Users still need current assignments, changed statuses, updated domain values, and server-side transactions that occurred after generation.

Build interruption tests. Terminate connectivity during initial load, delta download, local upload, and attachment transfer. Close the app during sync. Restart the device. Let authentication expire. For each case, verify whether the operation resumes, retries, rolls back, or requires user action. The expected result should be documented rather than inferred from a spinner or success message.

Use a controlled sync ledger during testing:

| Test record | Device action | Connectivity event | Expected server result |
|---|---|---|---|
| WO-MOB-101 | Add labor and work log | Drop before upload | Local queue retained, later single commit |
| WO-MOB-102 | Enter meter reading offline | Restore after restart | Reading synchronized once |
| SR-MOB-103 | Duplicate service request | Intermittent network | One new SR, no duplicate |
| WO-MOB-104 | Add three attachments | Drop during second file | Clear status for each file |

This evidence turns “offline seems fine” into a repeatable acceptance result.

3. Design Attachments, Location, Time, and Device Security as One Policy

Attachments are often the largest and least predictable mobile payload. Maximo Mobile 9.1 supports selecting multiple attachments in one flow and, on supported iOS and Android devices, files up to 200 MB. The limit is not a design target. A 200 MB video can still be unsuitable over constrained service, expensive to retain, and slow for downstream users.

Create an attachment policy by work type. Define acceptable media, preferred resolution, maximum operational size, metadata requirements, retention, malware controls, and whether download is automatic or user initiated. Test the complete storage path, including device, Manage attachment configuration, file or object storage, ingress limits, proxies, and retrieval. A client capability does not override a lower limit elsewhere in the chain.

Location data also needs explicit purpose. GPS can support service-address capture, travel events, maps, and operational verification. IBM documents a 9.1 control intended to prevent devices and emulators from reporting false GPS information. Decide which workflows require location, what happens when permission is denied or accuracy is poor, and who can access collected location information. Apply legal, labor, privacy, and records policies. Collect only what the approved process requires.

Time is another field-data dependency. Mobile 9.1 allows a user's timezone to be selected on the device when enabled through Mobile Admin. This matters for crews crossing time zones and for accurate timestamps. Define whether users may change timezone, how the system of record stores time, and how reports display it. Test work that begins before a timezone change and completes afterward. Also test daylight-saving transitions where relevant.

Shared devices require a different authentication model. IBM states that administrators must disable offline login and device authentication options for environments in which users share mobile devices. In 9.1, designating a device as shared disables biometric or PIN login configuration, and users of a shared device cannot log in while offline. That creates an operational dependency: a shift-change login needs connectivity.

Document the shared-device procedure:

1. Prior user completes synchronization.
2. Prior user signs out.
3. Device confirms no unresolved local transactions.
4. New user connects and authenticates online.
5. Automatic refresh completes for the new identity.
6. Support process handles a device with pending data from the prior user.

Device management should enforce OS versions, encryption, screen lock, remote wipe, application distribution, and certificate policy according to enterprise standards. Mobile application configuration cannot replace mobile-device management.

4. Optimize the Technician Experience Around Decisions, Not Screens

Mobile design should minimize uncertainty at the point of work. Technicians need to know what job is next, whether required data is present, what they can do offline, whether a save is local or synchronized, and what action resolves an error. Replicating every desktop field onto a phone usually makes those questions harder to answer.

Start with high-frequency tasks. For a work order, that may include reviewing safety and asset details, starting travel, starting work, completing tasks, recording labor and materials, entering failure information, taking meter readings, adding evidence, and changing status. Put required information in the sequence where it is used. Hide fields that are irrelevant to the persona, while preserving data needed by workflow and validation.

Maximo Mobile 9.1 allows offline meter readings on work orders created offline. Test the full rule set around those readings: meter type, rollover behavior, units, previous reading availability, validation, asset association, and the server result after synchronization. An offline form can accept a value that later conflicts with a more recent server reading, so the support process must address rejected or conflicting transactions.

Quick Reporting can use system properties for default work-order priority and work type. IBM documents `maximo.mobile.Priority`, with a documented default of 1, and `maximo.mobile.QuickWoWorktype`, with a documented default of `EM`. Treat defaults as business configuration, not mere convenience. Verify that they align with planning, SLA, workflow, and reporting

...