Who Can Access This PeopleSoft Component? The SQL, and the Gotchas

“Who can get to this component?” is one of the most common questions a PeopleSoft security administrator gets, and PeopleSoft has no delivered screen that answers it in one place. The data lives in three tables, and the joins are easy to get subtly wrong.

The Security Chain

PeopleSoft component access flows through a fixed chain:

1. PSOPRDEFN — user accounts
2. PSROLEUSER — which roles each user holds
3. PSROLECLASS — which permission lists each role carries
4. PSAUTHITEM — what each permission list grants: menu, component, and page entries with their authorized actions

A user can reach a component if any permission list on any of their roles has a PSAUTHITEM row for it.

The Query

To list users who can access a component (for example, USERMAINT):

SELECT DISTINCT RU.ROLEUSER, O.OPRDEFNDESC, RU.ROLENAME, RC.CLASSID
FROM   PSAUTHITEM AI
JOIN   PSROLECLASS RC ON RC.CLASSID = AI.CLASSID
JOIN   PSROLEUSER  RU ON RU.ROLENAME = RC.ROLENAME
JOIN   PSOPRDEFN   O  ON O.OPRID = RU.ROLEUSER
WHERE  AI.BARITEMNAME = 'USERMAINT'
AND    O.ACCTLOCK = 0
ORDER  BY RU.ROLEUSER;

In PSAUTHITEM, the component name is in BARITEMNAME; MENUNAME is the menu that exposes it, and PNLITEMNAME narrows a row to a specific page within the component.

Four Gotchas That Produce Wrong Answers

1. Locked accounts. Without ACCTLOCK = 0 your audit lists users who cannot sign in. Fine for “who is provisioned,” wrong for “who can get in today.” Decide which question you are answering.
2. The same component on multiple menus. A component can be attached to more than one menu, and each menu grants a separate PSAUTHITEM row. Filtering on MENUNAME alone undercounts.
3. Page-level rows. A permission list may grant only specific pages within a component (PNLITEMNAME). If you are auditing access to a specific page, you need the page-level rows; component-level results overstate access.
4. Display-only is still access. PSAUTHITEM.DISPLAYONLY = 1 means the user can see the page but not save. For a data-exposure audit, display-only access to sensitive data still counts.

And a fifth that isn’t in the SQL at all: dynamic roles. If a role is populated by a role query or rule, PSROLEUSER tells you who holds it now, not who could acquire it tomorrow.

The Faster Way

psLens answers this from the component’s own page: search the component, and its detail page shows the permission lists that grant it, the roles that carry those permission lists, and the users who hold those roles — each one a link, so you can keep tracing in either direction. The same chain works backwards from a user or a permission list. The Security Admin workflow shows the click path, and the User Access report produces the audit-ready Markdown version.

No SQL access required — which also means the analyst asking the question doesn’t need the database account that usually comes with it.

Subscribe for Updates

If you found this article helpful, subscribe to get notified of new PeopleSoft technical notes and psLens updates.

• ←Previous
• Next→