P_ORGIN — P_ORGIN Authorization Object for HR Master Data
P_ORGIN controls read and write access to HR master data infotypes based on the employee's own organizational values (personnel area, employee group, employee subgroup, organizational key) and the infotype/subtype being accessed. Because the check uses the values stored on the employee record itself, the same role can grant access to one employee and deny it for another with different org assignment.
This page covers P_ORGIN, the general authorization object for HR master data infotypes, focusing on the fields it evaluates, where the check actually fires during PA20/PA30 and infotype-driven reports, and the trace sequence needed to isolate a failure when it looks like a role problem but is really a data mismatch. It also covers the ownership split with security and the pitfalls that make a role look broken when the employee's org values have simply changed.
Published 16 Sept 2026· 886 words
What it protects
P_ORGIN protects display and maintenance of HR master data infotypes in transactions like PA20 and PA30, and in any report or program that reads infotype records through the standard HR macros. The check is not tied to a fixed list of personnel numbers. Instead it evaluates the organizational assignment values stored on the employee's own record at the moment of access: personnel area, employee group, employee subgroup, and organizational key, combined with the infotype and subtype being touched. This is the structural fact that causes most confusion: a role that works perfectly for one employee can fail outright for another employee under the same manager, simply because the second employee sits in a personnel area or employee subgroup not covered by the role's value ranges. The check also fires per infotype, not once per transaction screen, so a single PA20 display with several tabs can pass on some infotypes and fail on others.
Fields checked
- AUTHC - the activity level being checked, such as display, write, or matchcode search
- INFTY - the infotype number being accessed, restricted to a range or explicit list
- SUBTY - the subtype of the infotype, where the infotype uses subtypes
- PERSA - personnel area from the employee's organizational assignment
- PERSG - employee group from the same organizational assignment
- PERSK - employee subgroup
- VDSK1 - organizational key, often used to route access by department or reporting line
Where it is checked
- PA20 (display HR master data) - check fires each time an infotype is opened for display, evaluated against the values on that employee's current record
- PA30 (maintain HR master data) - check fires separately for read and for write/save, so a user can sometimes see a record but not save changes
- PA40 (personnel actions) - each infotype update triggered by the action framework is checked individually, so one action can fail partway through
- PA10 (personnel file) - checked per infotype displayed in the overview
- Custom ABAP reports and interfaces that call standard infotype read function modules or HR macros inherit the same check, often without any visible error handling
How to trace a failed check
Start with SU53 run immediately after the failed action, before doing anything else, since it only captures the most recent failed check and gets overwritten by subsequent authority checks. If the screen shows several infotypes or tabs, SU53 alone is not enough because it will only show the last one that failed, not all of them. Follow up with a full authorization trace (ST01 or the newer trace transaction) started before reproducing the exact PA20/PA30 sequence, then filtered to authorization object P_ORGIN. Capture the employee's personnel number, the infotype and subtype that failed, and the exact PERSA, PERSG, PERSK, and VDSK1 values on that employee's record on the date being accessed, not the values from a different employee used to test the role. Hand security the failing combination of these org values plus the infotype range, not just a screenshot of the error, since the role may hold several value lines and the missing combination is usually one specific line, not the whole object.
Whose problem this is
Functional consultants own identification: which employee, which infotype, which action, and what the employee's organizational assignment values are on the date in question. Security owns the role's value ranges for PERSA, PERSG, PERSK, VDSK1, and INFTY. A good request states the PERNR, the infotype/subtype, the org values from the trace, and whether the request is for read or write access, so security is not left guessing which value line to extend.
Common pitfalls
- A role that grants access to an infotype range works for most employees but fails for one whose organizational assignment changed recently, since P_ORGIN checks the current record values, not a static list of names
- Historical infotype records can become inaccessible after an employee transfers to a new personnel area, even though the current record displays fine, because the check re-evaluates against present-day org values in some access paths
- A successful PA20 header display is wrongly read as proof the role is fine, when individual infotype tabs behind that header can still fail independently
- P_ORGIN gets confused with the extended object P_ORGXX, which adds further organizational fields, leading to wasted time extending the wrong object
- Multiple value lines in the same role combine with AND across fields within a line and OR across lines, so a role can look generous on paper while still missing the one combination the employee actually falls into
- Concluding the role is broken and adding a blanket wildcard value, which masks the real org mismatch and later fails a security audit
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Learn this properly
Lessons and topics
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/p-orginERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.