Add an intent for requisitions

Requesters want to ask “my open requisitions for laptops”, and buyers “requisitions for monitors ordered since June”. This guide adds the intent behind those questions, find_requisitions, from the search definition to the release, the way you’d add any intent.

You’ll use: the Search Framework’s administration pages, the Intent Store, the test set, and the service’s test command.

Plan it

Decision	For requisitions
Category	`ZZ_REQUISITIONS`, with one search definition of the same name
Fields	`requester`, the person who asked for it; `status`; and `ordered`, the requisition date
Words	Text search on the requisition’s name, and its lines’ item descriptions
Security	Document-level, on `BUSINESS_UNIT`, following the same rules as your requisition pages
Synonyms	The words users say for items, such as laptop where the catalog says notebook

Prepare the search definition

Build a Connected Query, ZZ_REQUISITIONS_QRY, with the requisition header as the parent query and its lines as the child, so that each document holds the header’s fields and every line’s item description. The header needs BUSINESS_UNIT, REQ_ID, REQ_NAME, REQ_STATUS, REQ_DT, REQUESTOR_ID, and a last update date and time for incremental builds.
Create the search definition ZZ_REQUISITIONS on it, with REQUESTOR_ID, REQ_STATUS, and REQ_DT as attributes, the name and item descriptions in the text that searches match, and document-level security on BUSINESS_UNIT.
Create the category ZZ_REQUISITIONS, deploy both, run a full build, and schedule incremental builds, as in Prepare the search definitions.

The requester field compares REQUESTOR_ID with the signed-in user’s ID. That works when requester IDs are the users’ IDs. If yours aren’t, add each requester’s user ID to the query, and use that attribute instead.

Look up the status codes

The status field needs the words users say, and the codes PeopleSoft stores for them. Take them from REQ_STATUS’s translate values on your system. If you use AI Assist, ask for them in your IDE: its get_translate_values tool lists each code with its label. Use the labels users see on the requisition pages as the words.

Write the intent

intent: find_requisitions
label: Requisitions
description: >-
  Find purchase requisitions by what they're for, who
  requested them, their status, and the date ordered.
category: ZZ_REQUISITIONS
text_search: true              # item descriptions to match
examples:
  - My open requisitions for laptops
  - Requisitions for monitors ordered since June
  - Has my request for a standing desk been approved?
  - My requisitions that are still pending approval
  - Canceled requisitions from last week
  - Approved requisitions for office chairs
fields:
  requester:
    attribute: REQUESTOR_ID
    type: user
    operators: [equals]
  status:
    attribute: REQ_STATUS
    type: code
    operators: [equals, not_equals]
    values:                    # check against REQ_STATUS
      open: O
      pending approval: P
      approved: A
      denied: D
      complete: C
      canceled: X
  ordered:
    attribute: REQ_DT
    type: date
    operators: [on, before, after, between]
synonyms:
  laptop: notebook
  display: monitor

text_search is on, because users describe what they ordered, and those words are in the item descriptions, not in a field.
Several examples say my, so questions about the user’s own requisitions match this intent, and the LLM learns to use the requester field for them.
Synonyms cover item names, because users say laptop where the catalog says notebook. From PeopleTools 8.63, semantic search bridges words like these too.
The codes are examples. Replace them with your system’s translate values.

Add test questions

A test compares only the parts of the plan that its expect lists. The third question checks that the new intent doesn’t take questions that belong to another one:

- question: My open requisitions for laptops
  today: 2026-10-01
  expect:
    intent: find_requisitions
    text: notebook
    filters:
      - { field: requester, op: equals, value: me }
      - { field: status, op: equals, value: open }

- question: Laptops ordered since June
  today: 2026-10-01
  expect:
    intent: find_requisitions
    text: notebook
    filters:
      - { field: ordered, op: after, value: 2026-05-31 }

- question: Vouchers from Acme entered last month
  today: 2026-10-01
  expect:
    intent: find_vouchers

Test it and release it

Bump the version. In a working copy of the service’s files, such as ~/nlsearch-next, set the version in intents/store.yaml to 2026.10.1.

Run the tests against the working copy:

podman run --rm \
  -v ~/nlsearch-next:/etc/aipeoplesoft:ro,Z \
  --secret aips_llm_api_key,type=env,target=AIPS_LLM_API_KEY \
  aipeoplesoft-nlsearch:1.0 test

Prompt plan-writer v7, Intent Store 2026.10.1
52 of 52 questions produced the expected plan

Release it. Copy the working copy’s intents and tests directories to ~/nlsearch, set intents.version to 2026.10.1 in nlsearch.yaml, and restart the service with systemctl --user restart aipeoplesoft-nlsearch.

Try it

Sign in as a requester who has ordered laptops, open the search page, and ask “My open requisitions for laptops”. The summary reads Requisitions · “notebook” · Requester: you · Status: open, and the results are that requester’s open requisitions for notebooks, and nobody else’s.

Check it

A requester gets only their own requisitions, for any question that says my.
A buyer who asks “open requisitions for laptops”, without my, gets every open laptop requisition in the business units they may see.
A user who can’t see requisitions gets none, whatever they ask.
Voucher questions still go to find_vouchers, as the third test checks.