Skip to main contentMAF Configuration Practices

Understanding the Mobile Master Schema

Overview

The mobile master schema is the combined schema Maximo builds for mobile use across all active mobile applications.

A useful way to think about it is:

  • each mobile app contributes its own disconnected schema
  • Maximo reads those individual app schemas
  • Maximo merges them into one shared master schema
  • the mobile platform then uses that master schema as a common definition of objects, fields, and relationships

So the master schema is the shared result, while each app’s mobileDisconnectedSchema.json is one of the inputs.

High-level flow

Active mobile app packages
  -> Read each mobileDisconnectedSchema.json
  -> Resolve object structures to Maximo objects
  -> Merge fields, relationships, and datasource metadata
  -> Generate combined object schema
  -> Store mobile master schema

What is the purpose of the master schema

The purpose of the master schema is to give Maximo Mobile a single shared schema definition that works across active mobile apps.

Instead of treating every app separately at runtime, the platform can use one merged schema that describes:

  • which Maximo objects are used
  • which object structures map to those objects
  • which fields are needed
  • which related objects are needed
  • which datasource behaviors matter for offline use

This makes the platform more consistent because it has one central schema view instead of many disconnected app-specific views.

Conceptual example

Imagine two apps are active:

  • Technician uses work orders and assets
  • Inspection also uses work orders, but asks for slightly different fields

Without a master schema, the platform would need to reason about those app definitions separately.

With a master schema, Maximo can say:

  • MXAPIWODETAIL maps to WORKORDER
  • the shared Work Order definition needs to support fields required by both apps
  • the shared schema should also know about the related records those apps use

That shared view is the purpose of the master schema.

How the master schema is generated

At a high level, the generation process works like this:

  1. Maximo finds the active mobile applications.
  2. For each active mobile app, it reads the packaged disconnected schema file.
  3. It separates top-level datasources from related datasources.
  4. It resolves object structures to their primary Maximo objects.
  5. It merges entries that point to the same underlying object.
  6. It combines field selections, datasource metadata, and relationship information.
  7. It generates a combined schema definition for the merged result.
  8. It stores that combined result as the mobile master schema.

In plain language, Maximo starts with many app-level schema fragments and turns them into one shared schema.

Conceptual example

Suppose Maximo sees these active apps:

  • TECHMOBILE
  • INSPECTION
  • SERVICE_REQUEST

Each app package contains its own disconnected schema.

Maximo reads all three, then asks questions like:

  • do these apps use the same underlying object?
  • if yes, what fields do all of them require together?
  • what relationships should be preserved in the shared schema?

The final master schema is built from those combined answers.

How individual applications merge into the master select

One of the most important parts of master schema generation is the way app-level select values are merged.

The merge is object-based, not datasource-id-based.

That means if multiple apps use object structures that resolve to the same Maximo object, their field requirements can be combined into one broader master select.

Simple example: two apps using the same object

Imagine App A contributes this idea:

{
  "objectStructure": "MXAPIWODETAIL",
  "select": "wonum,description,status"
}

And App B contributes this idea:

{
  "objectStructure": "MXAPIWODETAIL",
  "select": "wonum,siteid,assetnum"
}

Because both point to the same underlying Work Order object, the master schema can merge them into a combined select like:

{
  "objectStructure": "MXAPIWODETAIL",
  "name": "WORKORDER",
  "select": "wonum,description,status,siteid,assetnum"
}

This is a conceptual example, but it illustrates the key behavior:

  • fields from App A are included
  • fields from App B are included
  • duplicate fields such as wonum only need to appear once
  • the final master select becomes the shared field set for that object

Example with three active apps

Now imagine three active apps all contribute to the same object:

  • App A needs wonum,description,status
  • App B needs wonum,siteid,assetnum
  • App C needs wonum,reportdate,location

A conceptual merged result could become:

{
  "objectStructure": "MXAPIWODETAIL",
  "name": "WORKORDER",
  "select": "wonum,description,status,siteid,assetnum,reportdate,location"
}

This shows why the master select can grow over time. Each active app can add more fields to the shared object definition.

How related data can also merge

The same idea applies to related datasources.

For example, one app may need assignment data like:

{
  "relationship": "showassignment",
  "select": "assignmentid,laborcode,status"
}

Another app may need a slightly different related field set:

{
  "relationship": "showassignment",
  "select": "assignmentid,scheduledate,finishdate"
}

A conceptual merged result could become:

{
  "relationship": "showassignment",
  "select": "assignmentid,laborcode,status,scheduledate,finishdate"
}

So the master schema does not only broaden top-level object fields. It can also broaden related-object field definitions.

Why active applications can negatively affect performance

The master schema is based on active mobile applications. That means every active app can influence the final shared schema.

This can create performance problems when many apps contribute fields for the same shared objects.

It is also important to note that this effect is tied to whether an app is active, not whether a particular user can access that app. In other words, an active mobile app can still contribute to the shared master schema even if some users do not have permission to use that application.

Why this matters

A broader master select can lead to:

  • larger payloads when data is fetched
  • broader related expansions when child relationships are included
  • more offline storage use because more fields and related data may be stored
  • more metadata to process on the server and mobile client
  • more local indexing and schema overhead on the device

Conceptual example

Imagine this progression:

  • with one app active, Work Order needs 12 fields
  • after enabling a second app, Work Order needs 20 fields
  • after enabling a third app, Work Order needs 30 fields plus extra child relationships

Even if no single app uses all of those fields at once, the shared master schema still needs to support the combined shape.

That is why active applications can negatively affect performance: each one can make the shared object definition larger.

Why the master schema can become bloated

The master schema becomes bloated when many apps contribute overlapping but slightly different requirements for the same object.

Common causes include:

  • multiple apps requesting the same object with different field lists
  • broad select statements
  • unnecessary related expansions
  • unused datasources left in an app
  • inactive business use but still-active mobile apps
  • overly broad lookup or reference datasources

The result is a shared schema that may be much larger than what any one app actually needs.

What administrators can do

Administrators usually do not change the merge algorithm itself, but they can reduce the amount of data being merged into the master schema.

Practical ways to help include:

  • trim datasource select lists so they only include needed fields
  • remove unused datasources from mobile apps
  • reduce unnecessary child relationships and nested expansions
  • review lookup datasources to avoid overly broad offline data
  • standardize shared object usage across apps where possible
  • deactivate unused mobile apps so they no longer contribute to the master schema

Conceptual example

Suppose two apps both use work orders:

  • App A selects wonum,description,status,siteid,assetnum,reportdate
  • App B selects wonum,description,status,siteid

If App A does not really need assetnum and reportdate, removing them shrinks the merged master select for the shared object.

That means one app’s cleanup can improve the shared schema for the whole mobile environment.

Summary

The mobile master schema is the shared schema Maximo builds from all active mobile application schemas.

Its purpose is to give the mobile platform one consistent, merged definition of objects, fields, and relationships.

The master schema is generated by:

  • reading each active app’s disconnected schema
  • resolving object structures to Maximo objects
  • merging field selections and related definitions
  • generating a combined shared schema

This merge is useful, but it also means active apps can enlarge the shared select for common objects. As more apps contribute more fields, the master schema can become broader and heavier, which can negatively affect performance.

That is why careful datasource design and active-app management are important parts of keeping Maximo Mobile efficient.

Edit this page on GitHub
Previous
Basic concepts: Basic concepts
Next
Basic concepts: Data Sources Guide