Look up a record by its ID

Users ask about specific records: “What’s the status of requisition 12345?”. Unlike a tool about the user’s own data, this tool takes an ID that anyone could type, so its API has to decide whether the user may see that record, and must never give away that a record exists when they can’t.

You’ll build: the GET /requisitions/{requisitionId} operation in ZZ_ASSISTANT_FIN, and the get_requisition_status tool.

Plan it

Decision	For this tool
Input	`requisitionId`, as the user typed it
Output	Each matching requisition the user may see: its name, status, date, and a link
Who may see one	Whoever your requisition pages allow: the requester, and buyers for its business unit
When there’s none	The same message whether the requisition doesn’t exist or the user can’t see it

Build the API

Normalize the ID. Requisition IDs are 10 characters, usually padded with zeros, but users type 12345. Pad a numeric ID to 10 characters, so 12345 becomes 0000012345.
Build a security view, such as ZZ_REQ_SEC_VW, that lists the requisitions each user may see, by user ID, business unit, and requisition ID. Base it on the same rules as your requisition pages: the requester’s own requisitions, and those in the business units the user’s purchasing security allows.

Select through the view, so the user’s access is part of the query itself:

SELECT H.BUSINESS_UNIT, H.REQ_ID, H.REQ_NAME,
       H.REQ_STATUS, H.REQ_DT
  FROM PS_REQ_HDR H, PS_ZZ_REQ_SEC_VW S
 WHERE S.OPRID = :1
   AND S.BUSINESS_UNIT = H.BUSINESS_UNIT
   AND S.REQ_ID = H.REQ_ID
   AND H.REQ_ID = :2

Describe the status with REQ_STATUS’s translate value in the user’s language, rather than the code, and build each requisition’s link with GenerateComponentContentURL.
Answer the same way when there’s nothing. If the query returns no rows, return an empty list and the message “No requisition 0000012345 that you can see.”, whether it doesn’t exist or belongs to someone else.
Create the operation as the GET method of the URI template requisitions/{requisitionId} in ZZ_ASSISTANT_FIN, with requisitionId as a base template parameter, and OAuth 2.0 required.

The same ID can exist in two business units, so the API returns a list, and the Assistant can ask which one the user means.

Write the description for the LLM

Get a purchase requisition by its ID, if the signed-in user may
see it: its name, status, and date, with a link to it. Pass the
ID as the user gave it. Returns a message instead when there's
no such requisition that the user can see.

What happens

A requester asks “What’s the status of requisition 12345?”:

The LLM calls get_requisition_status with {"requisitionId": "12345"}.

PeopleSoft pads the ID, finds the requisition through the security view, and returns:

{
  "requisitions": [
    {
      "businessUnit": "US001",
      "id": "0000012345",
      "name": "Laptops for new hires",
      "status": "Approved",
      "requested": "2026-09-15",
      "page": {
        "label": "Requisition 0000012345",
        "url": "https://fin.example.com/psc/ps/EMPLOYEE/ERP/..."
      }
    }
  ]
}

The Assistant answers:

Requisition 0000012345, Laptops for new hires, is Approved. It was requested on 15 September.

The user follows up with “Who approved it?”. The result doesn’t say, so the Assistant says it can’t see who approved it, and points to the requisition’s page, which shows its approval history. It doesn’t guess.

Check it

The requester asks about their requisition, and gets it.
A user in another business unit, with no access to it, gets “No requisition 0000012345 that you can see”: the same message as for 0000099999, which doesn’t exist.
A buyer for US001 asks about it, and gets it.
An ID in two business units that the user can both see returns both, and the Assistant asks which one they mean.
The audit log shows the ID as the user typed it, and the call’s response status.