IW28 — Change Maintenance Notifications List
IW28 is the multi-level list transaction for changing maintenance or service notifications in bulk. It selects notifications through a variant-driven list (built on the same selection logic as VIQMEL) and lets a planner apply mass functions such as put in process, complete, or print, or drill into a single notification for detailed change via the same screens IW22 uses.
This page covers IW28, the change-mode list transaction for PM/CS notifications, and how it differs structurally from IW22 despite sharing the same underlying data. It focuses on the selection logic, the tables the list reads and updates, and the diagnostic patterns that explain why notifications go missing from a selection or refuse to update from the list screen.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,157 words
Purpose
IW28 opens a multi-level ALV list of maintenance or service notifications, selected by plant, notification type, status, technical object, or date range, and allows change-mode actions against the selected set: put in process, complete, print, assign a person responsible, or navigate into a single notification for detailed editing. The structural fact that causes most confusion is that IW28 is not a separate data model or a spreadsheet-style editor. It is a worklist built on the same header table and status framework as IW21/IW22/IW23. Selecting a row and trying to type over a value in the grid usually does nothing, because most fields are not directly editable in the list; changes have to go through a mass function or through the detail screen reached by double-clicking a row.
When it is used
IW28 is the tool of choice when a planner or maintenance coordinator has to work through a backlog rather than a single notification: triaging overdue notifications, releasing a batch for planning, closing out notifications tied to a completed order, or printing a set of notifications for a shift handover. A single notification that needs detailed editing, item-level malfunction codes, or catalog entries is still better handled in IW22. IW28 sits between the single-object transactions (IW21/22/23) and the order-side list transactions (IW38/39), and on S/4HANA it is increasingly replaced in daily use by the Fiori notification list apps, which offer inline editing that the GUI list does not.
How to use it in practice
- Call IW28 and choose or build a selection variant restricting plant, notification type, status, and a relevant date range
- Execute the selection to render the ALV list
- Sort or filter the list on-screen to isolate the target rows
- Select one or more rows and apply a list function: put in process, complete, print, or mass change of person responsible or priority
- Double-click a row to jump into the IW22 detail screen when item-level, cause, or task data needs editing
- Save; the list refreshes and rows that no longer match the selection status drop out of view
Key data objects
- QMEL - notification header: type, plant, dates, person responsible, functional location/equipment, linked order number
- QMFE - notification items: damage codes and object part codes recorded against the notification
- QMUR - notification causes: cause codes linked to each item
- QMMA - notification tasks/activities: follow-up work items and their completion state
- JEST - object status records: current status flags (open, in process, completed) against the notification's object number
- JCDS - status change history: timestamped log of every status transition, used to reconstruct the timeline
How to prove it in the data
Pull QMEL filtered on plant, notification type, and creation or malfunction date to confirm which notifications should be in scope. Take the OBJNR from those QMEL rows and check JEST for the active status set (filter on INACT blank) to see the true current status rather than trusting what the list column shows. Cross-reference JCDS on the same OBJNR sorted by change date to see whether a completion was later reversed or a status was skipped. If a notification is missing from the IW28 list, compare its QMEL date fields against the exact date field the selection variant filters on; a mismatch there is the most common cause.
ECC vs S/4HANA
The underlying tables and status logic behind IW28 are unchanged on S/4HANA; the notification data model was not restructured. IW28 itself remains available and functions the same way. What has changed is the front end: the Fiori notification list apps allow inline editing of several fields directly in the list, something the GUI ALV grid never supported, and are the app most organizations push users toward for day-to-day triage while keeping IW28 available for exception handling and legacy scripts.
Common pitfalls and how to diagnose them
- Authorization scope: the list comes back empty or shorter than expected for a user who should see it. Check the maintenance planning plant authorization and notification type authorization before assuming a data problem.
- Wrong date field in the variant: notifications the business considers overdue do not appear. Selection variants can filter on notification date, malfunction start, or required end date; confirm which one the variant actually uses, since these rarely match business intuition.
- Status shown in list versus true status: a notification looks open in IW28 but the business insists it was completed, or vice versa. Check JEST for the active status flag and JCDS for the full history; a completion can be technically reversed, or an outstanding task in QMMA or an open follow-up order can block final closure even though the notification looks complete on screen.
- Grid edits that silently do not save: a user changes a value directly in the ALV cell and it reverts on refresh. Most fields in IW28 are display-only in list mode; the change has to go through a mass function or the detail screen via double-click.
- Missing follow-up order link: a notification shows no linked order even though one was created against it. Check whether the order number was actually written back to the notification header; a broken link here means the order and notification lifecycles are being tracked independently, which causes premature or delayed notification completion.
- Performance on wide selections: a broad date range across all plants and notification types without further restriction can time out or return an unmanageable list. Narrow by plant and type first, then widen only if the result set is too small.
Whose problem this is
Functional PM or CS consulting owns notification type configuration, status profiles, and catalog/code group setup. ABAP involvement is limited to custom selection variant fields or enhancements to the list layout. Basis owns the plant and notification type authorization objects. A good handover states the exact selection variant used, the plant and notification type in scope, and whether the discrepancy is in the list display or in the underlying status history.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/iw28ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.