Loading Maximo job plans and tasks

Updated August 7, 2026 · Mathias, LLC

The key is four columns, and one is the revision

A JOBPLAN record is not identified by its job plan number alone. Four attributes together identify it:

The revision number is part of the primary key. Revision 0 and revision 1 of job plan PM-1006 are two separate rows, not one row carrying a version stamp. Maximo says so itself when a load collides:

BMXAA4129E - The record for job plan=1006, organization=gnpower,
site=gmcp, revision=0 already exists. Ensure that the key value
for the given record is unique.

The message names every part of the key, revision included. When this error appears on a load that was meant to be an update, the load is inserting instead. Either the tool is not matching on all four columns, or the sheet is missing one of them.

JOBPLAN has 57 attributes and none of them are non-persistent. Unlike locations, what you see on a job plan is stored. The complexity here is in the key and the lifecycle rather than in hidden derivation.

Tasks are a child object with their own revision

JOBTASK is keyed on the task number and its own revision reference:

Two details in that table cost people time. The first is that a task description holds 300 characters while the job plan description holds 100. A sheet that reuses one description column across both tabs truncates at the parent without reporting it.

The second is that JPTASK and TASKSEQUENCE are different things. The task number identifies the task and the sequence orders it. They usually hold the same values, which hides the distinction until you need to reorder tasks without renumbering them.

A task row also has to carry the parent's key columns: JPNUM, ORGID, SITEID, and PLUSCREVNUM. Those columns are what attach the task to the right plan. A task sheet holding only task-level columns cannot say which job plan it belongs to.

Loading a job plan with its tasks

This is a parent/child load. The rules that govern it are not specific to job plans, and they apply equally to an asset with meters or a work order with labor.

1. Send the plan and its tasks as one nested structure, with the task rows beneath the parent record on the relationship. Uploading tasks as independent records does not work, because the object structure expects them nested.
2. Put all four of the parent's key columns on every child row. This is identity rather than redundancy.
3. Do not mix actions that cannot both succeed. A task update against a plan that is being inserted in the same run has nothing to update against. Catch that before submission.
4. Treat a failed plan as a failed set. If the plan errored, its tasks did not load, and any report that marks them successful will send you looking for records that were never created.
5. Keep skipped rows out of the payload rather than sending them with a flag.

A minimal working pair of sheets carries these columns:

JOBPLAN
JPNUM, ORGID, SITEID, PLUSCREVNUM, DESCRIPTION, STATUS

JOBTASK
JPNUM, ORGID, SITEID, PLUSCREVNUM,
JPTASK, PLUSCJPREVNUM, TASKSEQUENCE, DESCRIPTION

Note both revision columns on the task sheet and the organization column on both sheets. Omitting either revision column from the task sheet is the failure we see most often.

STATUS comes from the JOBPLANSTATUS domain. Load plans in a draft status and promote them once you have verified them, rather than loading straight to active. An active job plan that is wrong will start generating work.

Revisions and PNDREV

Job plan revisioning exists so that work orders already generated from a plan are not rewritten when the plan changes. The goal is reasonable. The implementation is where people get stuck.

Revising a plan creates a new record, in a pending revision state commonly seen as PNDREV. Because the revision number is part of the key, this is a new row rather than an edit. The original stays active and keeps serving existing work while the pending revision is edited. The revision takes over only when it is approved.

"You cannot revise a job plan that is in revised status"

BMXAA8318E - You cannot revise a job plan that is in
revised status.

A pending revision already exists. Maximo permits one open revision per plan, so deal with the revision already in flight rather than starting another. Find it, then either complete and approve it or cancel it. Nothing is wrong with the plan itself.

The same situation explains the question "how do I set a revised job plan back to active". You are not reactivating the original. You are advancing the pending revision through its statuses until it becomes the active one.

Loading into a revision

Loading changes into a revision means targeting the revision's number rather than the original's, again because the revision number is part of the key. Getting it wrong produces one of two results: the load edits the live plan when you meant to stage a change, or it fails on a duplicate key. Confirm which revision number you are writing to before you start.

Why tasks appear to be missing

"Some of my job plan tasks are gone" is an alarming thing to discover. It is usually a revision-scoping effect rather than data loss.

Tasks are keyed to a revision through PLUSCJPREVNUM, so the tasks you can see belong to the revision you are viewing. If you are viewing revision 2 and the tasks were loaded against revision 1, they are where you put them. You are reading a different record.

JOBTASK also carries PLUSCREVSTATUS, a per-task change status within a revision, backed by the REVSTATUS domain. A task can therefore be marked as changed within a revision rather than simply existing, which is more state than a spreadsheet view of the data suggests.

Check these four things before concluding that anything was lost:

• Which revision number is on screen.
• Which revision number the load wrote to.
• Whether the tasks exist against a different PLUSCJPREVNUM.
• Whether the plan was revised between the load and the look.

One related point to decide deliberately: changing a job plan does not change work orders already generated from the previous version. If existing work needs the new content, that is a separate exercise.

Nested plans, predecessors, and flow control

JOBTASK carries more structure than most loads use. These are the parts that come up often enough to name:

• Nested job plans. A task can reference another job plan through NESTEDJPNUM, with its own revision number in PLUSCNESTEDJPREVNUM. That is how a large plan embeds a smaller one, and the nested reference is revision-specific too.
• Predecessors. PREDECESSORTASKS is a single 256-character text attribute rather than a relationship table, so long predecessor lists reach that limit.
• Flow control. FLOWCONTROLLED, FLOWACTION, and SUSPENDFLOW govern automatic task progression. Loading them without knowing the flow configuration on the receiving system produces work orders that advance unexpectedly.
• Conditional tasks. CONDITIONNUM sets a condition on the task.
• Meters and inspections. METERNAME holds 10 characters and INSPFORMNUM holds 12. They tie a task to a meter or an inspection form.
• Scheduling. TASKDURATION is a duration type rather than a plain number, and INCTASKSINSCHED controls whether the task appears in scheduling at all.

Verifying the load

• Count the tasks per plan against your source. A plan that loads with only a subset of its tasks is the most common silent failure.
• Confirm the revision number on the plans and on the tasks, and confirm that the two agree.
• Check that the sequence values are what you intended rather than a copy of the task numbers.
• Open one plan in the user interface and read it as a planner would. Field-level correctness and a usable job plan are not the same test.
• Look at the descriptions closest to the limits. The 100-character plan description is where truncation shows up first.

Where a loading tool fits

Everything above is Maximo behavior and applies however you load. What tooling changes is whether the four-part key, the parent/child nesting, and the revision targeting are things you have to remember every time.

MaxQuickLoad handles parent/child structures such as JOBPLAN with JOBTASK from one spreadsheet or several, keeps the main and child data separated, and shows current Maximo values against proposed ones before anything is committed. On a job plan load, that means seeing the revision you are about to write to.

If job plans are what you are loading, ask for a demo. It is a good one to watch end to end.