Preventive Maintenance in D365 Asset Management: Maintenance Plans, Rounds, and Triggers
In my last article on the Asset Management foundation I laid out the structure that everything in Dynamics 365 Asset Management hangs from: functional locations as the stable places, assets installed into them, asset types as the maintenance taxonomy, and the work order as the thing that finally posts cost when it is ended. I closed with a promise to go a level deeper into the preventive side, and that is where I want to spend today. Preventive maintenance is the part of the module that earns its keep, because it is the difference between equipment that fails on its own schedule and equipment that gets attention before it fails on yours. I will walk through maintenance plans and maintenance rounds, the two ways preventive work is defined, how time-based and counter-based triggers actually generate a forecast of work, and how to keep that forecast from either burying your technicians or quietly drying up.
WHY PLAN PREVENTIVE WORK AT ALL
Corrective maintenance is reactive: something breaks, someone raises a request, a work order follows. It is necessary, but if it is all you do then your maintenance team lives in a permanent state of firefighting and your production schedule inherits every surprise breakdown as an unplanned gap. Preventive maintenance flips the timing. Instead of waiting for failure, you decide in advance that a given asset needs a given task at a given cadence, and Dynamics 365 projects those tasks into the future as a forecast you can see, resource, and schedule. The payoff is twofold: fewer unplanned outages, and a maintenance workload you can level and staff for rather than one that arrives in unpredictable spikes. The whole preventive apparatus exists to turn "we should probably service that every so often" into a concrete, dated, costed stream of work orders.
MAINTENANCE PLANS: THE BUILDING BLOCKS
The maintenance plan is where preventive work is defined. A plan is attached either to an asset type, so it applies to every asset of that type, or to an individual asset when something is special enough to deserve its own rules. Attaching to the asset type is the move that scales: define the plan once for "hydraulic press" and every press inherits it, which is exactly why the asset type taxonomy from the foundation article matters so much here. A plan that is too granular, written asset by asset, becomes a maintenance burden in its own right.
Inside the plan sit one or more plan lines, and the line is where the real configuration lives. Each line names a maintenance job type (the controlled vocabulary I argued for last time: inspection, lubrication, calibration, replacement), the trade or worker capability the job needs, an interval that says how often, a start date that anchors the cadence, and the trigger rule that decides whether the interval is counted in calendar time or in usage. One plan can carry several lines, so a single press might have a monthly visual inspection, a quarterly lubrication, and an annual overhaul all defined together and all forecast from the same plan.
TIME-BASED AND COUNTER-BASED TRIGGERS
The trigger is the heart of the whole thing, and there are two kinds. A time-based trigger fires on the calendar: every 30 days, every quarter, every twelve months. It suits work that has to happen on a fixed rhythm regardless of how hard the asset is run, such as statutory inspections, safety checks, and anything driven by a regulation or a manufacturer's calendar recommendation. A counter-based trigger fires on usage instead, read from a counter you maintain on the asset: operating hours, machine cycles, units produced, distance travelled. It suits wear-driven work, where a machine running flat out should be serviced sooner than one that sits idle half the week. Counter-based triggers are only as good as the counter readings behind them, so part of the design is deciding how those readings get into the system, whether by manual entry, by import, or by a feed from the equipment itself.
You do not have to choose globally; different plan lines on the same asset can use different triggers, which is normal. The inspection runs on the calendar while the bearing service runs on hours. What matters is matching the trigger to the failure mode: if a component wears with use, count the use; if it degrades with time regardless of use, count the time. Getting that match wrong is how shops end up either over-servicing idle equipment or under-servicing the workhorses.
MAINTENANCE ROUNDS: GROUPING THE SMALL STUFF
Not every preventive task deserves its own work order. A great deal of routine maintenance is small and repetitive: check a gauge, top up a fluid, listen for a noise, confirm a guard is in place. Raising a separate work order for each of these would drown the system in administrative noise. The maintenance round exists for exactly this. A round bundles many small checks, often across several assets along a physical route, into a single piece of work that a technician walks through in one pass. Think of it as the structured version of the morning walk-around: one document, many line items, recorded together. Rounds are still driven by the same plan and trigger machinery, so they forecast and schedule like everything else, but they keep the count of work orders sane and they match how the work is actually performed on the floor.
FROM FORECAST TO SCHEDULED WORK
Here is the sequence that ties it together. You configure the plans and their lines, then you run the forecast over a horizon you choose, say the next twelve months. The forecast is a projection only: it shows you every preventive job that would fall due, with its date, before you have committed to anything. That is the moment to sanity-check the load, because the forecast will tell you honestly whether you have just scheduled three overlapping overhauls in the same week. Once you are happy, you generate work orders from the due forecast lines, and from there each work order behaves exactly as I described in the foundation article: it is scheduled against the maintenance worker and the asset's own availability, executed, completed, and finally ended, which is the point at which labour and consumed items post as cost.
The horizon you pick is a real decision. Forecast too short and you are blind to a big job creeping up just past the edge of your window; forecast too long and the projection drifts, because counter-based predictions in particular depend on usage assumptions that get shakier the further out you look. I tend to keep a rolling medium horizon for planning visibility and generate actual work orders over a much shorter committed window, so the near term is firm and the far term stays advisory.
KEEPING THE FORECAST HEALTHY
A preventive setup is not fit-and-forget. Two failure modes show up again and again. The first is flooding: intervals set too aggressively, so technicians are buried in low-value tasks, start skipping them, and the whole discipline loses credibility. The fix is to be honest about which tasks genuinely reduce failure and to lengthen or drop the ones that do not. The second is the opposite, the forecast going quiet, usually because counter readings have stopped flowing. A counter-based plan with no fresh readings simply stops projecting due dates, and the work silently disappears from the forecast without anyone noticing until something breaks. So part of running preventive maintenance well is monitoring that the counters are actually being updated, not just that the plans exist.
WHAT GOES WRONG
• Plans written per asset instead of per asset type. You lose the scale benefit and create a maintenance chore out of your maintenance setup. Define on the type and override only the genuine exceptions.
• Wrong trigger for the failure mode. Calendar triggers on wear-driven parts over-service idle machines and under-service busy ones; usage triggers on time-driven checks let a statutory inspection slip. Match the trigger to how the thing actually fails.
• Counter-based plans with no counter discipline. No readings means no forecast, and the work vanishes quietly. Decide up front how readings arrive and monitor that they keep arriving.
• Everything as its own work order. Small recurring checks belong in maintenance rounds, not in a flood of individual orders that nobody can schedule sensibly.
• Forecast horizon mismatched to reality. Too short hides large jobs; too long pretends to a precision the usage assumptions cannot support. Keep a long advisory view and a short committed one.
TAKEAWAYS
Preventive maintenance in Dynamics 365 is built from a small set of parts that fit together cleanly once you see the shape. Maintenance plans, attached to asset types so they scale, carry plan lines that each pair a job type and a trade with an interval and a trigger. Time-based triggers count the calendar and counter-based triggers count usage, and the art is matching each to the way its asset actually wears or ages. Maintenance rounds keep the high-volume small checks from drowning you in paperwork. The forecast projects all of this into a dated stream of upcoming work that you review before committing, and the resulting work orders flow through the same lifecycle that only becomes a financial fact at ending. Get the plans, the triggers, and the counter discipline right and your maintenance team moves from reacting to breakdowns toward preventing them, which is the entire point of the module.
Next time I will follow the work order into execution and money: how a maintenance work order picks up labour hours and spare parts from the same inventory the shop floor draws on, how it schedules against worker and asset availability, and how the cost lands when the order is ended so finance sees the true cost of keeping equipment running.
In this series: previous article Asset Management in D365 SCM: Functional Locations, Assets, and the Maintenance Foundation
In my last article on the Asset Management foundation I laid out the structure that everything in Dynamics 365 Asset Management hangs from: functional locations as the stable places, assets installed into them, asset types as the maintenance taxonomy, and the work order as the thing that finally posts cost when it is ended. I closed with a promise to go a level deeper into the preventive side, and that is where I want to spend today. Preventive maintenance is the part of the module that earns its keep, because it is the difference between equipment that fails on its own schedule and equipment that gets attention before it fails on yours. I will walk through maintenance plans and maintenance rounds, the two ways preventive work is defined, how time-based and counter-based triggers actually generate a forecast of work, and how to keep that forecast from either burying your technicians or quietly drying up.
WHY PLAN PREVENTIVE WORK AT ALL
Corrective maintenance is reactive: something breaks, someone raises a request, a work order follows. It is necessary, but if it is all you do then your maintenance team lives in a permanent state of firefighting and your production schedule inherits every surprise breakdown as an unplanned gap. Preventive maintenance flips the timing. Instead of waiting for failure, you decide in advance that a given asset needs a given task at a given cadence, and Dynamics 365 projects those tasks into the future as a forecast you can see, resource, and schedule. The payoff is twofold: fewer unplanned outages, and a maintenance workload you can level and staff for rather than one that arrives in unpredictable spikes. The whole preventive apparatus exists to turn "we should probably service that every so often" into a concrete, dated, costed stream of work orders.
MAINTENANCE PLANS: THE BUILDING BLOCKS
The maintenance plan is where preventive work is defined. A plan is attached either to an asset type, so it applies to every asset of that type, or to an individual asset when something is special enough to deserve its own rules. Attaching to the asset type is the move that scales: define the plan once for "hydraulic press" and every press inherits it, which is exactly why the asset type taxonomy from the foundation article matters so much here. A plan that is too granular, written asset by asset, becomes a maintenance burden in its own right.
Inside the plan sit one or more plan lines, and the line is where the real configuration lives. Each line names a maintenance job type (the controlled vocabulary I argued for last time: inspection, lubrication, calibration, replacement), the trade or worker capability the job needs, an interval that says how often, a start date that anchors the cadence, and the trigger rule that decides whether the interval is counted in calendar time or in usage. One plan can carry several lines, so a single press might have a monthly visual inspection, a quarterly lubrication, and an annual overhaul all defined together and all forecast from the same plan.
TIME-BASED AND COUNTER-BASED TRIGGERS
The trigger is the heart of the whole thing, and there are two kinds. A time-based trigger fires on the calendar: every 30 days, every quarter, every twelve months. It suits work that has to happen on a fixed rhythm regardless of how hard the asset is run, such as statutory inspections, safety checks, and anything driven by a regulation or a manufacturer's calendar recommendation. A counter-based trigger fires on usage instead, read from a counter you maintain on the asset: operating hours, machine cycles, units produced, distance travelled. It suits wear-driven work, where a machine running flat out should be serviced sooner than one that sits idle half the week. Counter-based triggers are only as good as the counter readings behind them, so part of the design is deciding how those readings get into the system, whether by manual entry, by import, or by a feed from the equipment itself.
You do not have to choose globally; different plan lines on the same asset can use different triggers, which is normal. The inspection runs on the calendar while the bearing service runs on hours. What matters is matching the trigger to the failure mode: if a component wears with use, count the use; if it degrades with time regardless of use, count the time. Getting that match wrong is how shops end up either over-servicing idle equipment or under-servicing the workhorses.
MAINTENANCE ROUNDS: GROUPING THE SMALL STUFF
Not every preventive task deserves its own work order. A great deal of routine maintenance is small and repetitive: check a gauge, top up a fluid, listen for a noise, confirm a guard is in place. Raising a separate work order for each of these would drown the system in administrative noise. The maintenance round exists for exactly this. A round bundles many small checks, often across several assets along a physical route, into a single piece of work that a technician walks through in one pass. Think of it as the structured version of the morning walk-around: one document, many line items, recorded together. Rounds are still driven by the same plan and trigger machinery, so they forecast and schedule like everything else, but they keep the count of work orders sane and they match how the work is actually performed on the floor.
FROM FORECAST TO SCHEDULED WORK
Here is the sequence that ties it together. You configure the plans and their lines, then you run the forecast over a horizon you choose, say the next twelve months. The forecast is a projection only: it shows you every preventive job that would fall due, with its date, before you have committed to anything. That is the moment to sanity-check the load, because the forecast will tell you honestly whether you have just scheduled three overlapping overhauls in the same week. Once you are happy, you generate work orders from the due forecast lines, and from there each work order behaves exactly as I described in the foundation article: it is scheduled against the maintenance worker and the asset's own availability, executed, completed, and finally ended, which is the point at which labour and consumed items post as cost.
The horizon you pick is a real decision. Forecast too short and you are blind to a big job creeping up just past the edge of your window; forecast too long and the projection drifts, because counter-based predictions in particular depend on usage assumptions that get shakier the further out you look. I tend to keep a rolling medium horizon for planning visibility and generate actual work orders over a much shorter committed window, so the near term is firm and the far term stays advisory.
KEEPING THE FORECAST HEALTHY
A preventive setup is not fit-and-forget. Two failure modes show up again and again. The first is flooding: intervals set too aggressively, so technicians are buried in low-value tasks, start skipping them, and the whole discipline loses credibility. The fix is to be honest about which tasks genuinely reduce failure and to lengthen or drop the ones that do not. The second is the opposite, the forecast going quiet, usually because counter readings have stopped flowing. A counter-based plan with no fresh readings simply stops projecting due dates, and the work silently disappears from the forecast without anyone noticing until something breaks. So part of running preventive maintenance well is monitoring that the counters are actually being updated, not just that the plans exist.
WHAT GOES WRONG
• Plans written per asset instead of per asset type. You lose the scale benefit and create a maintenance chore out of your maintenance setup. Define on the type and override only the genuine exceptions.
• Wrong trigger for the failure mode. Calendar triggers on wear-driven parts over-service idle machines and under-service busy ones; usage triggers on time-driven checks let a statutory inspection slip. Match the trigger to how the thing actually fails.
• Counter-based plans with no counter discipline. No readings means no forecast, and the work vanishes quietly. Decide up front how readings arrive and monitor that they keep arriving.
• Everything as its own work order. Small recurring checks belong in maintenance rounds, not in a flood of individual orders that nobody can schedule sensibly.
• Forecast horizon mismatched to reality. Too short hides large jobs; too long pretends to a precision the usage assumptions cannot support. Keep a long advisory view and a short committed one.
TAKEAWAYS
Preventive maintenance in Dynamics 365 is built from a small set of parts that fit together cleanly once you see the shape. Maintenance plans, attached to asset types so they scale, carry plan lines that each pair a job type and a trade with an interval and a trigger. Time-based triggers count the calendar and counter-based triggers count usage, and the art is matching each to the way its asset actually wears or ages. Maintenance rounds keep the high-volume small checks from drowning you in paperwork. The forecast projects all of this into a dated stream of upcoming work that you review before committing, and the resulting work orders flow through the same lifecycle that only becomes a financial fact at ending. Get the plans, the triggers, and the counter discipline right and your maintenance team moves from reacting to breakdowns toward preventing them, which is the entire point of the module.
Next time I will follow the work order into execution and money: how a maintenance work order picks up labour hours and spare parts from the same inventory the shop floor draws on, how it schedules against worker and asset availability, and how the cost lands when the order is ended so finance sees the true cost of keeping equipment running.
In this series: previous article Asset Management in D365 SCM: Functional Locations, Assets, and the Maintenance Foundation
No replies yet. Be the first to respond!
