This is the multi-page printable view of this section. Click here to print.
SWS sits between PeopleSoft and the systems that need PeopleSoft data. The pages in this section document specific patterns we have seen work well in production — what the architecture looks like, which SWS features make it possible, and the trade-offs to plan around.
If you are evaluating SWS for a specific scenario and do not see it covered here, contact Chris Malek — we likely have a pattern for it.
AI agents, chatbots, and Retrieval-Augmented Generation (RAG) pipelines need clean, structured data from systems of record. PeopleSoft is the system of record, but the path from PeopleSoft data to an LLM-friendly response normally goes through a development project — gather requirements, write a bespoke web service, migrate the code, encode the response, ship it. By the time the agent team gets the data, the prompt has moved on.
SWS shortcuts that loop. The data layer becomes configuration, and the agent team can iterate without an Application Designer migration for every change.
EFF_STATUS = 'A' arrive as Active so the model does not have to guess what A means.PeopleSoft tables routinely carry thirty to a hundred fields. Most are administrative (LAST_UPDATE_OPRID, audit timestamps, undocumented user-defined fields with leftover staging data). When an LLM sees those, it will often latch onto whatever looks important and reason about it — even when the field is irrelevant or wrong.
PsoftQL lets you list the fields to include, or explicitly exclude fields by name. Keep the response narrow. The model will be more accurate, the prompt will be cheaper, and the next person debugging a bad answer will not have to wonder where the model got the idea. See PsoftQL syntax for the include/exclude options.
For every field that SWS recognizes as having a prompt table or translate value, the JSON response includes the resolved description alongside the raw code. The LLM gets "EFF_STATUS": "A" and "EFF_STATUS_DESCR": "Active" in the same payload. You do not have to teach the model your XLAT values; the data is self-describing.
For records where the default prompt resolution does not point at the right table — a custom staging table, an unusual setup record — an explicit prompt table override is on the SWS roadmap.
Agent teams discover what data they actually need by trying things. SWS is suited to that loop because there is no migration overhead per endpoint. Build a PsoftQL configuration, expose it on a test path, point the agent at it, see what the model does with the response, change the configuration, retry. When the experiment is done you delete the configuration row — there is nothing to roll back.
This same pattern is what makes SWS useful for short-lived integrations more generally: conversion projects, one-off audit pulls, partner integrations that only need data for a quarter.
Most agent integrations need to scope answers to the end user. “What is my expense status?” must return my expense status, not the CEO’s.
@startuml
actor "End User" as user
participant "Chatbot UI" as ui
participant "Agent Server\n(trusted)" as agent
participant "SWS / IB" as sws
database "PeopleSoft" as ps
user -> ui: Question\n("what is my expense status?")
ui -> agent: HTTP + SSO token
agent -> agent: Resolve SSO\n→ EMPLID / OPRID
agent -> sws: GET /sws/.../expenses\nBasic Auth: service account\n?oprid={user_oprid}
sws -> sws: Auth service account\nBind :oprid → end user
sws -> ps: SQL with WHERE EMPLID = :oprid
ps -> sws: Rows
sws -> agent: JSON (with descriptions)
agent -> agent: LLM reasons over JSON
agent -> ui: Natural-language answer
ui -> user: Answer
@enduml
The pattern in one paragraph: your agent server is a trusted server. It authenticates the end user through your existing SSO, knows that user’s PeopleSoft OPRID (or can look it up), and then calls SWS as a single service account, passing the end-user identity as a request parameter. The configured SQL or PsoftQL binds that parameter (for example :oprid) to scope the query to that user. The full mechanics, including when to reach for PS token minting instead, are documented in Identity Flow & User Context.
SWS is the data layer. It is intentionally not:
Keep SWS narrow on purpose. It exposes PeopleSoft data over REST cleanly enough that the agent layer above it can be anything you want.