How NL Search works

NL Search splits every search into two jobs: understanding the question, which the LLM does, and running the search, which PeopleSoft does. The two meet in a query plan, a small JSON document that says which search to run, and with which filters.

The LLM sees the question and the candidate intents, never the results. PeopleSoft runs the search as the user, so what anyone finds stays under PeopleSoft's security.

The parts

• The search page is a Fluid page with a single search box, opened from a tile. It shows the results with a summary of how the question was understood above them.
• The search application class, such as ZZ_NLSEARCH:Search, does PeopleSoft’s half of the work. It sends the question to the NL Search Service, then runs the plan it gets back with the Search Framework. An application service built with the Application Services Framework (ASF) makes the same class available to other callers, such as the PeopleSoft Assistant.
• The NL Search Service turns a question into a validated query plan. It holds the Intent Store, the Prompt Store, and the LLM credentials. It has no access to PeopleSoft data.
• The LLM reads the question and the intents that might answer it, and writes the plan.
• The Search Framework runs the plan against PeopleSoft’s OpenSearch indexes as the signed-in user, applying each search definition’s security. See PeopleSoft Search and OpenSearch.

One search, step by step

Here’s what happens when a user searches for “Vouchers over $10,000 from Acme entered last month”:

1. The application class sends the question to the NL Search Service, with today’s date and the user’s language. It doesn’t send the user’s ID or roles, because the service doesn’t need them.

2. The service picks candidate intents, the ones in the Intent Store whose examples are most like the question, and builds the prompt from the active version in the Prompt Store.

3. The LLM writes a query plan, constrained to the plan’s JSON Schema.

4. The service validates the plan against the intent: the fields, the operators, the values, and the dates. It then writes a plain-language summary of the plan.

5. The application class runs the plan with the Search Framework: the intent’s search category, the plan’s text as the query text, and each filter on the attribute it names. The Search Framework then adds the user’s security, as it does for any search: definitions the user may not search are left out, and where a definition has document-level security, its application class supplies the values this user may see. OpenSearch returns only documents that match both the plan and the security filters.

6. The page shows the results, with the summary above them: Vouchers · Supplier: Acme · Amount: over 10,000 · Entered: 1–31 August 2026. Selecting a result opens it in PeopleSoft.

The plan for this question, on 25 September 2026:

The query plan

{
  "intent": "find_vouchers",
  "text": "",
  "filters": [
    { "field": "supplier", "op": "contains", "value": "Acme" },
    { "field": "amount", "op": "greater_than", "value": 10000 },
    {
      "field": "entered",
      "op": "between",
      "value": ["2026-08-01", "2026-08-31"]
    }
  ]
}

The question named no words to search for, only filters, so text is empty. For “open requisitions for laptops”, text would be laptops, and the Search Framework would match it against the requisitions’ descriptions. The supplier filter uses contains, so it also finds vouchers from Acme Corporation.

Results come from the index

Like every PeopleSoft search, NL Search searches the index, not the application’s tables. A voucher entered a minute ago appears once the index is updated: after the next incremental build, or shortly after it’s saved, if the search definition uses real-time indexing. See Keeping the index current.

What the LLM sees

The LLM sees the question, today’s date, the user’s language, and the candidate intents: their names, descriptions, fields, operators, and examples. It never sees the search results, the user’s identity, or anything else from PeopleSoft. What a user can find is decided entirely by PeopleSoft, after the LLM’s work is done.

Questions about the user, such as “my open requisitions”, still work: the plan says me, and PeopleSoft fills in the user’s ID. See Questions about the user.

Using NL Search from the Assistant

The PeopleSoft Assistant can offer NL Search as a tool, such as search_peoplesoft, through the NL Search application service. The Assistant passes on the user’s question, PeopleSoft runs the search as the user, and the Assistant summarizes what was found. In that case the Assistant’s LLM sees the results, as it does any tool result, while NL Search’s own LLM still never does. Offer NL Search to the Assistant shows how to set it up.

What NL Search doesn’t do

• Totals and charts. NL Search finds documents, but doesn’t total or group them. Questions such as “voucher totals by supplier” belong in a PeopleSoft Insights dashboard.
• Changes. NL Search only finds things. Users open a result to change it.
• Two kinds of data at once. Each plan uses one intent, so a question such as “Acme’s vouchers and purchase orders” runs the intent that fits best. Users can ask about each separately.