Maintenance notifications in SAP S/4HANA

A maintenance notification is the entry point of the maintenance process — it captures a problem, a request, or a recorded activity before any order exists. It is how the organisation says "something needs attention" in a structured, reportable way, and it is the document that gets screened and, if accepted, turned into a maintenance order.

What a notification is

A notification documents a maintenance-relevant event against a technical object. It always references a functional location or equipment, and it carries a description and long text, a priority, dates, and — importantly for analysis — catalog codes for the damage, the cause, and the activity. Those codes are what later make failure analysis possible across many objects, rather than every report being free text.

Standard notification types

SAP delivers three standard notification categories, and most organisations build on them:

• Maintenance request (type M1) — "please do this": a request for new work, a modification, or a planned activity.
• Malfunction report (type M2) — "something is broken": a breakdown or fault, usually carrying breakdown timing for downtime analysis.
• Activity report (type M3) — "this was done": documentation of an activity that has already happened.

Organisations often add their own types on this backbone, but the request / malfunction / activity distinction is the model to start from.

From notification to order

A notification does not do the work — it triggers it. The typical flow is: create the notification (e.g. IW21), screen it (a supervisor decides whether it is accepted), and for accepted requests convert it into a maintenance order (e.g. via IW28/IW52), where the work is actually planned, scheduled, and executed. A notification can also be completed on its own when no order is needed.

This is exactly the readable narrative that the maintenance order phase model describes: the notification lives in the Initiation and Screening phases before an order is raised in Planning.

Why it matters

Notifications are where data quality is won or lost. Good object references and consistent catalog coding turn a year of notifications into reliability insight — top failure causes, worst-performing equipment, recurring problems. Treated as an afterthought, they become unsearchable free text. They are also the demand signal for planning: the notification backlog is what feeds planning buckets and order creation.

Common questions

What is the difference between a notification and an order? The notification reports or requests work and holds the analysis data; the order plans and executes it and carries the cost.

Which notification type do I use? A request for work → M1; a breakdown/fault → M2; documentation of work already done → M3.

Do I always need a notification before an order? Not always — orders can be created directly — but starting from a notification preserves the demand history and the analysis codes.

---

Related: the maintenance order phase model · planned and preventive maintenance · technical structure and objects. Want clean notification data in S/4HANA? Explore our SAP PM training.