Siebel Field Service Guide > Preventive Maintenance > Preventive Maintenance Triggers >

Logic Governing Triggers

The following rules regulate the operation of Preventive Maintenance triggers:

• Time Interval and Date triggers are the only trigger type that can fire for a date in the future. All other triggers can fire only for the current date (when the engine runs).
• Triggers never fire in the past. If the Preventive Maintenance Engine finds a trigger that should have fired in the past, it fires for the current date unless some other constraint or condition prevents that.
• No trigger can fire more than once a day.
• No trigger can fire while there is an outstanding (future) PM activity for the asset and its associated PM plan.

When the trigger logic evaluates whether a trigger should fire, it prevents the creation of a new PM action whenever there is an existing action for the current date or any date in the future. This behavior is by design, to prevent triggers from firing multiple times for the same trigger condition. However, it means that plans with a Time or Date trigger combined with another trigger should not be run with end dates too far in the future. Time- or Date-triggered preventive maintenance actions in the future might prevent other valid triggers (such as Usage triggers) from firing, thus preventing valid service actions from being created.

NOTE:  There are no constraints built into the PM module limiting multiple triggers.

For example, a plan with Time and Usage triggers might run with an end date one year in the future. All the PM actions for the next year are created based on the Time trigger, and during that time the Usage trigger will never fire, whatever the actual usage. You can avoid this conflict by only scheduling PM actions a few weeks or one month in advance. Then, in the worst case, the engine runs and schedules a PM action based on the Time trigger even though the asset meets the usage criteria tomorrow. The actual difference in the time between when the PM action should have been scheduled and when it was scheduled is, at most, the difference between the end date passed to the engine and the current date (when the engine runs).

When an SR Template is associated to a PM Plan and one of the triggers for the plan fires, it generates service requests and PM actions with date fields automatically filled with values, as listed in Table 129: