I'll start with I'm not a fan of Application Import for Job Plans. The use case for Application Import is for end users to be able to make quick adjustments to records. For example, if you want to update the work type on 20 work orders you can export the work orders, update the work type, and then import.
Almost every import of job plans I have seen are someone develops job plans in a lower non-production environment and want to migrate to a higher environment. Job Plans are really difficult because there are many child tables involved (including new ones for qualifications in MAS 9), columns, and dependencies. For example, if your job plan has an inspection form you might need to migrate the new inspection forms in addition to the job plan. If you have classifications or specifications involved, those may need to migrate too. There's a lot of related things that you may want to combine into a single deployment.
Application import is almost exclusively used with flat file structures like CSV to be used in Excel for example. This means you need to alias a ton of attributes or exclude them (which can lead to issues if you later use them). For something like job plans I always use XML or JSON to migrate the data because it does better with the 1 to many aspect of most of the tables.
With all that out of the way, let's try to understand what might be going on here. Job plans have an inbound processing class now (psdi.iface.app.jobplan.MaxJPProcess) that should be used. MXLoader object structures don't use this (or at least, didn't) but you want to ensure this inbound processing class is referenced on your object structure you're using for application import. There was a bug with this inbound processing class on some versions Known Issue: DT400428
Second, the column headers in MXLoader are NOT the aliased column names that you would need for an import using application import/export. When you reference child objects in MXLoader, you'll use something like JOBTASK.DESCRIPTION. In Application Import, each column in the child object could be aliased to something like JT_DESCRIPTION. You need to use the Add/Modify alias action in the Object Structures application to confirm for each field what you need to use. Some will be the same column name, but others will be prefixed to make it unique across all the columns on all the objects. This is where using XML rather than CSV can help but then it makes editing much more difficult.
------------------------------
Steven Shull
Naviam
------------------------------
Original Message:
Sent: 08-26-2025 08:56
From: Oumayma Azouz
Subject: Revise Job Plans using Application Import
Hello everyone,
I am trying to configure the application import functionality to revise job plans in Maximo. The revised job plan are not created, while using the same data in MXLoader, the job plan is successfully revised. Anyone can provide an explanation on this matter ? Thank you in advance.
#Integrations
------------------------------
Oumayma Azouz
AtkinsRealis
------------------------------