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:
Persona: electrical corrective technician
Assigned work: current user or crew, approved/in-progress statuses
Time horizon: due from 7 days before through 14 days after today
Sites: user's authorized operating sites
Asset lookup: assets referenced by downloaded work plus local emergency scope
History: last 5 completed work orders for the selected asset, on demand online
Attachments: metadata in scope; binary download based on field need
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 rules at each site. An incorrect default can quietly distort the backlog.
Design clear local-state cues. Users should be able to distinguish:
Saved locally and pending upload
Upload in progress
Synchronized successfully
Rejected by server validation
Blocked by missing supporting data
Attachment pending separately from the parent transaction
Train users on recovery actions that preserve data. “Reinstall the app” should not be the first response to a sync problem because it can destroy diagnostic evidence or unsynchronized work. Provide a short field guide for reconnecting, refreshing, reviewing pending transactions, capturing support details, and escalating without repeated edits that create more conflicts.
Run usability tests in gloves, bright light, noisy conditions, and realistic travel. Include technicians with different roles and device familiarity. Field reliability is partly technical and partly cognitive. A technically correct workflow that encourages duplicate taps or ambiguous status changes will still create data-quality problems.
5. Build an Operational Model for Sync Failures and Release Changes
Mobile support spans several teams, so triage must be based on evidence. Define ownership for device and OS, identity, network, Mobile configuration, Manage application logic, attachment storage, GIS, and integrations. Give the service desk a decision tree that starts with scope: one record, one user, one device model, one site, or all users.
Collect a standard incident packet:
User and persona:
Device model and OS:
Maximo Mobile app version:
Site and timezone:
Approximate incident time in local timezone:
Online or offline at action time:
Record identifiers:
Action attempted:
Pending transaction or attachment status:
Last successful refresh:
Whether issue reproduces on another approved device:
Do not ask users to send secrets or unrestricted screenshots containing sensitive data. Use approved diagnostic and support methods. Correlate the incident with server logs, integration errors, authentication events, attachment-storage status, and recent configuration changes.
Release management must account for the client and server together. Record compatible Mobile, Manage, and MAS levels using current IBM documentation. Test application upgrades, OS updates, Mobile configuration changes, object-structure changes, security-group changes, and server validation changes in a representative environment. A server-side automation script can break offline uploads even when the mobile app itself did not change.
Use pilot rings. Start with support staff and a small, diverse technician group, then expand by site or persona. Define exit criteria such as successful initial load, refresh duration within the locally approved threshold, zero unexplained duplicate transactions, successful offline work completion, attachment completion, and support readiness. Avoid inventing universal benchmarks. Measure against the organization's actual network, data, and operational tolerance.
Monitor trends, not just incidents. Useful measures include initial-load completion, delta-refresh failures, pending-transaction age, rejected server transactions by message, attachment failures by size and network, active client versions, and incidents by device type. Review the data after every release and major field campaign.
Practical Implications
A dependable Maximo Mobile implementation needs three signed agreements. The business signs the field journey and offline scope. Security signs device, authentication, location, and data-handling policy. Operations signs synchronization monitoring, incident evidence, and recovery procedures. Configuration should follow those agreements.
Use Mobile Admin to centralize supported 9.1 controls, but retain configuration governance. Record the owner, rationale, environment values, test cases, and deployment date for each property. Test automatic refresh, enhanced delta data, preloads, shared-device behavior, timezone controls, GPS controls, Quick Reporting defaults, and attachment limits with actual personas.
Plan network-independent onboarding for remote sites where practical, while remembering that preloaded data still needs a current delta refresh. For shared devices, plan online authentication at shift change. For large media, set an operational limit below the technical maximum when field bandwidth and storage justify it.
Most importantly, never make destructive recovery the default. Preserve pending work and diagnostics before resetting local state. A good support process treats the device as a participant in a distributed transaction, not a disposable browser cache.
Bottom Line
Maximo Mobile 9.1 offers stronger tools for offline work, synchronization, attachments, shared devices, location integrity, and centralized administration. Those capabilities deliver value only when they are assembled into a deliberate field architecture.
Define the minimum complete offline dataset for each persona. Separate initial load from delta refresh. Govern preloaded databases. Test interruption at every synchronization phase. Align attachment, location, timezone, authentication, and device-management rules. Give technicians clear local-state cues and give support teams a standard evidence packet.
The result is not merely an app that opens without a signal. It is a field-service system that preserves work, explains its state, limits data exposure, and recovers predictably when real-world connectivity fails.
Sources
IBM: What's new in Maximo Mobile 9.1
IBM: Configuring Maximo Mobile
