IW21 — Create PM Notification

IW21 creates a maintenance notification: a structured record of a fault, a completed activity, or a request for work, tied to a technical object (equipment or functional location) or, less often, standing alone. The single structural fact that explains most confusion is that the notification type is not cosmetic. It is a configuration key that determines which screen tabs appear, which catalog profile supplies the damage/cause/activity codes, which partner functions default, and whether a maintenance order is generated automatically. Two notifications that look identical to the end user can behave completely differently in the system if their notification types are configured differently. The notification itself carries no cost and consumes no budget; that only happens once an order is linked to it.

IW21 is reached for whenever a fault, request, or observation needs to be logged before or independent of planning the work, which is the standard reactive maintenance entry point in most plants. Field technicians, shift supervisors, or a service desk raise the notification; a planner later reviews it, adds a cause and task list if needed, and either releases the automatically generated order or creates one manually. In S/4HANA landscapes many end users now raise notifications through a Fiori app instead, but the underlying object and the configuration behind it are unchanged, so IW21 remains the transaction consultants use to reproduce and diagnose issues raised against the Fiori equivalent.

Pull the notification number from QMEL and confirm QMTYP (notification type), QMDAT (creation date), and STRMN/STRUR (malfunction start) match what the user reported. Check JEST for the active status entries against that notification number and object type QMEL, joined on OBJNR, to confirm whether it was ever put in process or completed. If the complaint is a missing catalog code, check QMFE for the notification and compare the catalog fields against the catalog profile configured for that notification type; a blank row usually means the code was never valid in that catalog, not a save failure.

The notification data model (QMEL and its item/cause/activity tables) is unchanged on S/4HANA. IW21 still runs as-is in the SAP GUI. Many end users now create notifications through a Fiori app for maintenance notifications instead of the GUI transaction, but that app writes to the same tables through the same underlying logic, so a discrepancy reported in the Fiori app can usually be reproduced and diagnosed directly in IW21.

Functional PM/EAM consultant territory: notification type configuration, catalog profiles, partner determination, and status profiles are all customizing. ABAP is only involved for custom fields added via the standard enhancement points or a BAdI implementation. A clean handover states the notification number, notification type, expected versus actual field or code behavior, and whether the issue is reproducible on a new notification of the same type.

IW22 and IW23 are the change and display counterparts once the notification exists; IW28 and IW29 are the list transactions used to find and mass-process notifications, useful for confirming whether a data issue affects one record or a whole notification type. IW31 creates the maintenance order that a notification often triggers, either automatically or manually with reference. IE02 and IL02 are worth checking whenever a notification's defaulted fields look wrong, since equipment and functional location master data drive most of what IW21 fills in automatically.