Review who can open a component

Before a component goes live, or during an access review, you need to know exactly who can open it and what they can do there. In PeopleSoft, that means following the component’s menu items to permission lists, then to roles, then to users. AI Assist does that walk in one call, and the LLM points out access that looks too broad.

You’ll use: get_security, describe_component, and describe_record.

Ask

Who can open ZZ_TRAINING_REQ, and with what access? Flag
anything that looks broader than a training request process
needs.

What happens

get_security with {"component": "ZZ_TRAINING_REQ"} returns the component’s menu item, the permission lists that grant access, the actions they allow on each page, and their roles with user counts:

{
  "name": "ZZ_TRN_MGR",
  "description": "Training - Managers",
  "pages": [
    {
      "page": "ZZ_TRAIN_REQ",
      "actions": ["Add", "Update/Display"]
    },
    {
      "page": "ZZ_TRAIN_APPR",
      "actions": ["Update/Display"],
      "displayOnly": true
    }
  ],
  "roles": [
    { "name": "ZZ Training Manager", "userCount": 42 },
    { "name": "Employee", "userCount": 8950 }
  ]
}

describe_component shows who the component is for: its navigation is Manager Self Service > Training > Training Request. It also lists the component’s records.
describe_record for each of those records returns its keys. None of them has EFFDT, so the component’s data isn’t effective-dated. That matters for the Update/Display All and Correction actions, which only change how users work with the history rows of effective-dated records.

What you get

Access to ZZ_TRAINING_REQ (GBL), registered on menu ZZ_TRAINING, bar USE, item ZZ_TRAINING_REQ:

ZZ_TRN_MGR, Training - Managers. Roles: ZZ Training Manager (42 users) and Employee (8,950 users).

ZZ_TRAIN_REQ: Add, Update/Display

ZZ_TRAIN_APPR: Update/Display, display-only

ZZ_TRN_ADMIN, Training - Administration. Role: ZZ Training Admin (6 users).

Both pages: Add, Update/Display, Update/Display All, Correction

Findings

ZZ_TRN_MGR is in the Employee role. All 8,950 users with that role can add and update training requests, and view the approval page. The component is in Manager Self Service, so the permission list looks meant only for the 42 users in ZZ Training Manager.

ZZ_TRN_ADMIN allows Update/Display All and Correction. They have no effect today, because the component has no effective-dated records. But if one is added later, administrators would get Correction on it without anyone deciding they should. Granting only Add and Update/Display keeps the permission list to what the component uses.

This covers access granted by security definitions. Row-level security and PeopleCode that hides pages at runtime can narrow it further, but can’t widen it.

Check the answer

Open the definitions. Check each permission list’s pages and actions at PeopleTools > Security > Permissions & Roles > Permission Lists, on the Pages tab. For each role, the Permission Lists tab at PeopleTools > Security > Permissions & Roles > Roles shows what it includes.
Test as a user. In a test environment, sign in as a user who has only the Employee role, and try to open Manager Self Service > Training > Training Request.
Check row-level security separately. A component’s search record usually decides which rows a user can open. describe_component names it, and describe_record shows how it’s defined.

Go further

“Which roles can use Correction mode on JOB_DATA?”
“Compare access to ZZ_TRAINING_REQ with access to the other ZZ training components.”_
“Draft a change request to remove ZZ_TRN_MGR from the Employee role.”