I_IWERK — Authorization Object for Maintenance Planning Plant
I_IWERK controls access to Plant Maintenance orders, notifications, task lists and maintenance plans based on the planning plant (IWERK) recorded on the object, checked together with the activity performed. It is frequently confused with I_SWERK, which governs the separate maintenance (location) plant field, and mixing the two up is the most common cause of a failed check.
This page covers what I_IWERK actually restricts in Plant Maintenance, the fields it evaluates, the transactions where SAP triggers the check, and the practical steps for tracing a failed authorization back to a specific planning plant value. It also flags the recurring confusion with the maintenance (location) plant object, I_SWERK.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 814 words
What it protects
I_IWERK guards access to PM objects at the level of the planning plant - the plant whose planner group is responsible for scheduling and processing the work, held in the field IWERK. It is checked whenever a transaction creates, changes, displays or lists orders, notifications, task lists or maintenance plans that carry a planning plant value. The structural fact behind most confusion is that PM distinguishes two plant concepts on the same order: the maintenance (location) plant, where the technical object physically sits, and the planning plant, which does the planning. One planning plant commonly services several location plants in a shared-services setup. A user can be fully authorized for the location plant and still be blocked, because the role does not cover the planning plant assigned to that specific order or notification, or the reverse.
Fields checked
- ACTVT - the activity being performed: 01 create, 02 change, 03 display, and other standard activity codes depending on the transaction (release, print, and similar follow-on actions use their own activity values where applicable).
- IWERK - the planning plant value or range of values the user is authorized to work with. Access is denied if the planning plant on the order, notification, task list or maintenance plan header falls outside this range.
Where it is checked
- Notification create, change and display transactions, and notification list/reporting transactions, checked against the planning plant stored on the notification header.
- Order create, change and display transactions, and order list/reporting transactions, checked against the planning plant on the order header, not the location plant on the equipment or functional location.
- Task list maintenance transactions, checked against the planning plant the task list group is assigned to.
- Maintenance plan and maintenance item transactions, checked against the planning plant driving the scheduling.
- Follow-on actions such as order release, technical completion and print output, where the check fires again at the point the action is executed rather than only at initial entry.
How to trace a failed check
Start with SU53 run immediately after the failure - it shows the last authorization check and, if I_IWERK is the culprit, the failing field will be IWERK with the value taken from the order or notification header, not from the equipment record. If SU53 is empty or inconclusive (common when the failure happens inside a background step or a BAPI call), run the authorization trace for the specific user and transaction, reproduce the exact steps, then filter the trace output for I_IWERK. Note the planning plant value the system actually checked against and the activity code. Hand security the transaction code, the user id, the object or order number involved, the planning plant value read from the trace, and the activity - not a general 'PM access broken' description. This lets security compare the exact value against the role's authorization range in one pass instead of re-running the trace themselves.
Whose problem this is
Functional PM consultants identify which planning plant is actually assigned to the order, notification or task list in question, since that is not always obvious from the transaction screen alone. Security maintains the role values. A complete request states the transaction, the planning plant value(s) needed, the activity, and the object type (order, notification, task list, or maintenance plan).
Common pitfalls
- A role restricted correctly on I_SWERK (location plant) but missing the matching planning plant in I_IWERK still fails, and the failure is read as a general PM access problem rather than a single missing field value.
- The planning plant defaulted from a work center or equipment record can be overridden manually on the order; a user authorized for the object's 'home' plant is blocked because the order was created against a different planning plant on purpose.
- Wildcard or full-range IWERK access granted in a test system gets narrowed in production without anyone checking whether all planning plants actually used by that user group are still covered.
- New plants added during a reorganization or plant rollout are not automatically added to existing roles, so a check that worked for months starts failing the day a new planning plant goes live.
- Background jobs and interfaces running under a technical user often carry a narrower planning plant range than the interactive roles used for the same process, so a report that works fine when run manually fails or returns a partial result set when scheduled.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/i-iwerkERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.