PM Work Orders Not Generated for One Site
A preventive maintenance schedule has generated work orders for BEDFORD and SPRINGFIELD for months, but not for NORTH. The NORTH PM records are active, have a 30-day frequency, and their last start date is 45 days ago. The PMWOGEN cron task instance runs every 60 minutes and reports SUCCESS on every run. Last month the administrator created a new organization NORTHOPS and moved NORTH assets and PM records into it. The existing PMWOGEN instance has ORGID = BEDFORDOPS and SITEID = BEDFORD. The Run As user for the instance is a Maximo administrator with access to all sites. The administrator wants to fix NORTH without changing generation for the other two sites or editing the PM records' organization again.
1. What would you inspect in the cron task instance and PM records before changing anything?
Read the worked answer
Inspect the PMWOGEN cron task instance, not just the cron task definition. Confirm whether the instance is active, its schedule, its Run As user, its parameter values for ORGID, SITEID, PMTYPE, LEADTIME, and USELASTSTART, and its recent history. A SUCCESS status only means the job completed; it does not prove the job selected NORTH records.
On the PM records, check ORGID and SITEID first, because they must match the cron instance filters. Then check Active, Frequency and Frequency Unit, Last Start Date, Next Due Date, Lead Time, Use Last Start Date, Start Date, End Date, and Job Plan status. A PM can be active yet have a future Next Due Date, an expired End Date, or an unapproved job plan. Also confirm that the Run As user has site access to NORTHOPS and NORTH. This separates a filter problem from a PM data problem before you change the schedule.
2. Given the ORGID and SITEID parameters, what are the options, and which is least risky?
Read the worked answer
The existing instance is filtered to BEDFORDOPS and BEDFORD, so it will not select NORTHOPS PM records. The options are to clear the ORGID and SITEID parameters so one instance covers all organizations and sites, to change the existing instance to a broader scope, or to create a second PMWOGEN instance for NORTHOPS and NORTH. Editing the PM records back to the old organization is not an option because the business already moved them.
The least risky change is a second instance with ORGID = NORTHOPS and SITEID = NORTH, using the same schedule and an appropriate Run As user. It isolates NORTH from the existing generation, makes monitoring independent, and avoids widening the existing instance unexpectedly. Clearing parameters on the existing instance is simpler but increases blast radius and changes behavior for every site. After creating the instance, use Run Now or wait for the next scheduled run, then verify that only NORTH work orders are generated.
3. After adding a NORTH instance, the instance is SUCCESS but no work orders appear. What next?
Read the worked answer
Do not assume the cron task is at fault. Check the PM selection criteria and the generation result. Confirm the NORTH PM records are active, their ORGID is NORTHOPS, their SITEID is NORTH, and their Job Plan is approved. Compare Last Start Date, Frequency, Lead Time, and Next Due Date; a 45-day-old last start with a 30-day frequency should be due, but a future Start Date or an expired End Date can suppress generation.
Inspect the cron task history for the number of records processed and any message text. If zero records were selected, recheck the instance parameters and Run As site access. If records were selected but no work orders appeared, look for generation errors in the logs and validate required work order fields, such as status, work type, and priority. Also check whether Use Last Start Date is enabled and whether the PM has an existing work order that the system considers already generated.