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

Processing Logic for Triggers

The following rules regulate the operation of Preventive Maintenance triggers:

• Only Time Interval and Date triggers can occur for a date in the future. All other triggers can occur only for the current date (when the engine runs).
• Triggers never occur in the past. If the Preventive Maintenance Engine finds a trigger to occur in the past, then the trigger occurs for the current date unless some other constraint or condition prevents the trigger from occurring.
• No trigger can occur more than once a day.
• No trigger can occur when there is an outstanding (future) PM action for the asset and its associated PM plan.

NOTE:  The Preventive Maintenance module has no built in constraints to limit multiple triggers.

When the trigger processing logic evaluates a trigger occurrence, a new PM action is not generated when there is an existing action for the current date or any date in the future. This behavior prevents triggers from occurring multiple times for the same trigger condition. However, plans with a Time or Date trigger combined with another trigger do run with end dates too far in the future. Time- or Date-triggered service actions in the future might prevent other valid triggers (such as Usage triggers) from occurring, and thus prevent the generation of valid service actions.

For example, a plan with Time and Usage triggers might run with an end date 1 year in the future. All the PM actions for the next year are generated by using the Time trigger, and during that time the Usage trigger never occurs, regardless of the actual usage. You can avoid this conflict by scheduling PM actions only a few weeks or a month in advance. Then, in the worst case, the engine runs and schedules a PM action by using the Time trigger even though the asset meets the usage criteria tomorrow. The difference in the time between when the PM action should be scheduled and when the PM action is actually scheduled is, at most, the difference between the end date passed to the engine and the current date (when the engine runs).

When a service request template is associated with a PM plan, and a trigger for the plan occurs, service requests and activities are created with date fields automatically populated with values. Table 44 lists the fields from PM triggers: