Articles on psLens

Solving Duplicate Student Records: How an AI Agent Used psLens MCP to Reverse-Engineer PeopleSoft Name Search Normalization in 3 Minutes

Wed, 21 Oct 2026 00:00:00 +0000

Duplicate person records (EMPLIDs) are one of the most expensive data-integrity problems in PeopleSoft Campus Solutions and HCM. Once a student or employee is assigned two EMPLIDs, financial aid disbursements, enrollment history, transcripts, and residency records split across two identities.

Recently, a college running PeopleSoft Campus Solutions 9.2 on Microsoft SQL Server reported that their real-time Continuing Education integration was generating duplicate EMPLIDs—specifically for students with apostrophes or punctuation in their names, such as Denise O’Rourke.

Tracing Every Place a PeopleSoft Field Is Updated Using an AI Agent and the psLens MCP Server

Fri, 16 Oct 2026 00:00:00 +0000

Every PeopleSoft developer and functional analyst has been asked a version of this question:

“Where in the system does STDNT_CAR_TERM.TUITION_CALC_REQ get set to 'Y'?”

On a traditional codebase stored in Git, ripgrep answers that question in two seconds. In PeopleSoft, a single flag can be flipped across seven different architectural layers:

Record Field Defaults stored in PSRECFIELD (DEFFIELDNAME / DEFRECNAME)
Record Field PeopleCode (RowInit, FieldChange, SavePreChange, SavePostChange)
Scroll Buffer Functions (UpdateValue() targeting the record or a view over the record)
Database Views (STDNT_CAR_TE_VW) that write through to the underlying table
Inline SQLExec Statements with hardcoded UPDATE PS_STDNT_CAR_TERM strings
Application Packages & Application Engine Programs (both PeopleCode and SQL actions)
COBOL Stored SQL Statements in PS_SQLSTMT_TBL
Online Pages and Component Interfaces where users or integrations toggle the field directly

Worse, raw text searches in Application Designer or against PSPCMTXT routinely return false positives from commented-out code (/* ... */ or REM), miss updates that happen through SQLExec("UPDATE PS_STDNT_CAR_TERM ..."), and ignore COBOL stored SQL entirely.

Connecting AI Coding Agents to PeopleSoft with Model Context Protocol (MCP)

Fri, 14 Aug 2026 00:00:00 +0000

PeopleSoft has always been a black box to modern AI coding assistants.

Tools like Claude Code, Cursor, and Claude Desktop work by reading files on disk, navigating Git repositories, and parsing project trees. PeopleSoft does not work like that. Its object definitions, record structures, SQL objects, and PeopleCode live inside relational database tables (PSRECDEFN, PSRECFIELD, PSPROGMETA, PSAEAPPLDEFN), not on the filesystem.

Until now, getting that context to an LLM required writing ad-hoc SQL queries, taking screenshots of Application Designer, or manually copying and pasting code blocks into a chat window. That workflow is slow, breaks context across object hierarchies, and makes autonomous coding assistants impossible to use with PeopleSoft.

Why psLens Runs on Go, a Hypermedia UI Stack, and SWS Instead of Living Inside PeopleSoft

Mon, 13 Jul 2026 00:00:00 +0000

When I started building psLens, I was not trying to create another PeopleSoft bolt-on. I wanted a tool that could sit beside PeopleSoft, search metadata fast, run audits, monitor Process Scheduler and Integration Broker, and stay easy to deploy and maintain.

That requirement set ruled out a lot of obvious choices.

psLens now runs as a standalone Go application with server-rendered UI components built in templ, live updates handled by Datastar (GitHub), and a PeopleSoft-side access layer provided by SWS. That combination is not accidental. Each part solves a specific problem that PeopleSoft teams run into when they try to build admin and security tooling the old way.

Which Service Operations Can Half Your Users Call?

Tue, 07 Jul 2026 00:00:00 +0000

Ask a PeopleSoft security administrator “who can call this web service?” and you will usually get a pause. There is no delivered screen that ranks service operations by how many users can reach them. The grant is buried one level below where anyone looks: a service operation is authorized to a permission list, and permission lists ride roles out to users. A single broadly-held role can quietly put a data-moving web service in reach of hundreds of accounts that have no business calling it.

Your PeopleSoft Nodes Probably Don't Have Passwords

Thu, 02 Jul 2026 00:00:00 +0000

Here is a finding from a delivered Campus Solutions 9.2 development image: 62 active message nodes, 58 of them with no authentication configured. That is not an unusual environment. It is what delivered images look like, and refreshed non-prod environments inherit it.

Why It Matters

A message node with AUTHOPTN = 'N' accepts messages without authenticating the sender. Any system that can reach your Integration Broker gateway can send messages to or through that node. Whether that is exploitable depends on what routings and service operations the node participates in — but “unauthenticated by default and nobody has looked” is not a posture you want to explain to an auditor.

Who Can Access This PeopleSoft Component? The SQL, and the Gotchas

Thu, 02 Jul 2026 00:00:00 +0000

“Who can get to this component?” is one of the most common questions a PeopleSoft security administrator gets, and PeopleSoft has no delivered screen that answers it in one place. The data lives in three tables, and the joins are easy to get subtly wrong.

The Security Chain

PeopleSoft component access flows through a fixed chain:

PSOPRDEFN — user accounts
PSROLEUSER — which roles each user holds
PSROLECLASS — which permission lists each role carries
PSAUTHITEM — what each permission list grants: menu, component, and page entries with their authorized actions

A user can reach a component if any permission list on any of their roles has a PSAUTHITEM row for it.