Start with the security reports (Full Access Permission Lists, Stale Passwords, Nodes Without Passwords), then review the Security Admin use case for an audit workflow.
If the docs answer what psLens does, the next step is seeing it against a live PeopleSoft environment. The walkthrough is the fastest way to judge fit for your team, your security posture, and your deployment model.
Get started with psLens: install the SWS framework, deploy psLens, and connect it to your PeopleSoft environment in minutes.
Getting Started with psLens
Install SWS in PeopleSoft, run the psLens container, point it at SWS, log in. The pages in order:
Overview
psLens is a single self-contained application: a Go binary that serves the web interface and stores report data locally. There is no separate database to manage. It connects to your PeopleSoft environment through the SWS (Secure Web Services) framework, which must be installed and configured in PeopleSoft first.
The psLens dashboard — your starting point for monitoring PeopleSoft environments
Hosting psLens in production? Read Deployment Options for HTTPS, version pinning, backups, and upgrade paths.
Start psLens and open the dashboard in your browser
Quick Start
Once the SWS framework is installed in PeopleSoft:
# Create a directory for psLensmkdir pslens &&cd pslens
# Create config.yaml with your PeopleSoft connection details# (see Configuration for full details)# Start psLens with Dockerdocker compose up -d
# Open http://localhost:8080 in your browser
Not Ready to Install Yet?
If you are still evaluating architecture, security, or operator workflow, see it running first. A live demo is the quickest way to answer fit questions before you commit to an install path.
How psLens connects to PeopleSoft: a small SWS framework inside your PeopleSoft environment, and a psLens Docker container hosted externally.
Architecture Overview
psLens has only two moving parts:
The SWS framework, a small Integration Broker service installed inside your PeopleSoft environment.
The psLens application, a single Docker container hosted externally (default: fly.io) or on your own infrastructure.
Everything psLens displays (search results, alerts, reports) flows over a single HTTPS connection from the psLens container into your SWS endpoint. There is no other channel.
The Short Version
Two components, nothing else. SWS inside PeopleSoft; psLens as a Docker container outside it.
Traffic only flows one way. psLens calls SWS over HTTPS. SWS never reaches out to psLens.
One protocol. REST + HTTP basic auth + psoftQL JSON queries. No database drivers, no ODBC, no jump hosts.
One scope. SWS only answers queries against PeopleTools metadata tables that you whitelist. Anything outside the list is rejected before it touches the database.
Dedicated deployment per customer. No shared psLens app, no shared storage, no multi-tenant SaaS backend.
How the Pieces Fit
%%{init: {"flowchart": {"htmlLabels": true, "padding": 16, "nodeSpacing": 60, "rankSpacing": 80, "subGraphTitleMargin": {"top": 10, "bottom": 14}}}}%%
flowchart LR
USER(["Your team's<br/>web browser"])
subgraph EXT["Cedar Hills Group hosted <br/>or your own infrastructure"]
APP["psLens<br/>Docker container"]
end
subgraph PS["Your PeopleSoft Environment"]
SWS["SWS Framework<br/>REST endpoint"]
DB[("PeopleSoft DB<br/>read-only<br/>whitelisted tables")]
SWS --> DB
end
USER -- "HTTPS" --> APP
APP -- "HTTPS · Basic auth<br/>psoftQL JSON" --> SWS
classDef ps fill:#e8f4fd,stroke:#0d6efd,stroke-width:2px,color:#000
classDef ext fill:#fff5e6,stroke:#fd7e14,stroke-width:2px,color:#000
classDef user fill:#e9f7ef,stroke:#198754,stroke-width:2px,color:#000
classDef subgraphStyle fill:#fafafa,stroke:#666,stroke-width:1px,color:#000
class SWS,DB ps
class APP ext
class USER user
class PS,EXT subgraphStyle
Your team reaches psLens with any current web browser over HTTPS. There is no desktop client to install. Everything the user sees comes from the psLens container; the browser never talks to PeopleSoft directly.
Inside Your PeopleSoft Environment: SWS
The SWS framework is a small Integration Broker service Cedar Hills Group provides. Your PeopleSoft team installs it once, alongside everything else PeopleSoft already runs. It exposes a single REST endpoint that accepts a structured query language called psoftQL and returns JSON.
What SWS gives you control over:
The whitelist. Your PeopleSoft admins decide which PeopleTools metadata tables SWS is allowed to read. psLens cannot ask for anything off the list.
The credentials. SWS authenticates incoming requests with HTTP basic auth. Your team owns the token; rotating it is a config change on both ends.
The audit trail. Calls land on your Integration Broker like any other inbound service, visible in the tooling your team already monitors.
No PeopleSoft database username or password is ever shared with psLens.
Outside Your Environment: psLens Container
psLens itself is a single Docker container: one Go binary, with embedded NATS for storing alert history and report output. That’s the entire runtime.
Default deployment is on fly.io as a managed instance dedicated to your organization.
Self-hosting is fully supported. Docker, docker-compose, bare-metal, and air-gapped environments are all covered in the installation guide.
Stateless toward PeopleSoft. psLens does not copy your business data. The only things it persists are alert history and report output, both inside its own dedicated storage. See the Security & Trust page for details on what is and isn’t stored.
When you upgrade psLens, you pull a new container image. Nothing inside PeopleSoft changes.
psLens renders pages on the server with Go templates and streams updates over Server-Sent Events using Datastar. There is no React, no Angular, no JSON API. The browser receives HTML fragments over SSE (TLS at the transport layer) and renders them.
Two consequences fall out of this:
Nothing from PeopleSoft is stored in the browser. psLens does not write to LocalStorage, SessionStorage, or IndexedDB. Closing the tab takes the active session data with it.
No JSON wire format. The server sends pre-rendered HTML; there is no client-side data structure for an attacker to scrape or tamper with. Page transitions are server round-trips of a few KB of HTML, and the browser tab holds no result set.
Why This Shape
Bounded blast radius. Even in a worst case where the psLens container were compromised, the SWS whitelist is the ceiling on what an attacker could read. They cannot drop into PeopleSoft, run PeopleCode, or pivot to other tables.
Easy to upgrade and operate. New psLens features ship as a new container image. No PeopleSoft change request, no App Designer migration, no downtime on the PeopleSoft side.
Multi-environment from day one. A single psLens deployment can connect to DEV, TEST, and PROD at the same time. Point at the SWS endpoint in each environment via separate database entries in config.yaml.
Where Next
Installation installs SWS in PeopleSoft and runs the psLens container.
Configuration wires psLens to your PeopleSoft environments.
Security & Trust covers the read-only design, dedicated deployment, and what psLens does and doesn’t store.
1.2 - Installation
psLens uses a Cedar Hills Group, Inc. web service inside your PeopleSoft environment to connect to the psLens web application. This page describes how to install and configure the SWS framework for psLens.
The psLens web application connects to your PeopleSoft environments with a limited version of our SWS framework.
You will install a PeopleSoft Application Designer project (CHG_PSLENS) with two web services that expose a REST API for reading data from PeopleSoft tables. psLens calls the web services instead of talking to the database directly. Most of the work is performed by the CHG_PSLENS_SWSPQL service operation. There is a secondary service operation, CHG_PSLENS_METADATA_GET, that returns miscellaneous metadata about the PeopleSoft environment that cannot be read from the database tables and relies on proprietary PeopleCode functions.
We do NOT deliver the full SWS framework to customers for psLens. The full SWS framework is a commercial product that includes a query language, a web service framework, and a set of tools for building and managing REST APIs on top of PeopleSoft. psLens uses a small subset of the SWS framework to read data from PeopleSoft tables.
This installation guide assumes that Cedar Hills Group, Inc. is hosting the psLens web application. If you are hosting psLens yourself, please see Deployment Options for instructions on how to install and configure psLens in your own environment. The option where we host psLens is the simplest and fastest way to get started, and is the recommended option for most customers.
You will be given a zip file containing the CHG_PSLENS Application Designer project.
Import the project into your PeopleSoft DEV environment. Detailed instructions are included below.
Run the “whitelist” inserts to allow psLens to read the tables it needs. Detailed instructions are included below.
Configure the required service account for psLens API access and grant it the required permissions to read the tables psLens uses. Detailed instructions are included below.
Ensure that your instance of psLens can reach the PeopleSoft Integration Gateway. This often requires a firewall rule to allow the psLens server to reach the PeopleSoft Integration Gateway on port 443 (or your configured port).
Work with Cedar Hills Group to configure the psLens web application to connect to your PeopleSoft environments.
PeopleSoft Project Installation
You will repeat these steps for each PeopleSoft environment you want to connect to psLens (DEV, TST, PROD). We recommend starting with DEV first, then TST, then PROD. The steps are the same for each environment. You can follow your standard change management process for importing the project into TST and PROD.
You will be given a zip file containing the CHG_PSLENS Application Designer project.
Using Application Designer, import the project into your PeopleSoft environment.
After importing the project, you need to build the CHG_PSLENS_WL table.
This holds the list of whitelisted tables that psLens can read. You will run the whitelist inserts to populate this table.
Build
Compile all the project PeopleCode to ensure that the project was fully imported. There should be no errors. If there are errors, please contact Cedar Hills Group for assistance or try to re-import the project.
Compile
Whitelist Inserts
You will need to run the whitelist inserts to allow psLens to read the tables it needs. Please see the Whitelist Tables page for the full list of inserts. You will need to run these inserts in each PeopleSoft environment you want to connect to psLens (DEV, TST, PROD).
PeopleSoft Service Account
psLens uses a dedicated PeopleSoft operator ID (OPRID) for API access. This is the account that psLens uses to authenticate to the SWS framework.
The naming convention for the account is CHG_PSLENS_API_USER. You can use a different name if you prefer, but you will need to update the psLens configuration to match.
Create OPRID: CHG_PSLENS_API_USER
Add a complex password that meets your security requirements. This password will be used in the psLens configuration. Use a password manager to generate a strong password.
Grant the following permissions to the account:
ID Type: NONE
Role: CHG_PSLENS_API_USER
Permission List: CHG_PSLENS_API_USER
The account should NOT have any other permissions or roles. It should only have the permissions required to read the whitelisted tables. If you have any sort of dynamic security roles, make sure that they do not grant any additional permissions to this account. The account should be as limited as possible. The permission list that we deliver in the project is the entire set of permissions that psLens needs to read the whitelisted tables. If you have any questions about the permissions, please contact Cedar Hills Group.
psLens to PeopleSoft Connectivity
We will cover the most common configuration where Cedar Hills Group, Inc. hosts the psLens web application and you have a network team that can allow the psLens server to reach the PeopleSoft Integration Gateway.
The default configuration for psLens is to connect to the PeopleSoft Integration Gateway over HTTPS from the internet. The psLens server must be able to reach the PeopleSoft Integration Gateway on port 443 (or your configured port). This often requires a firewall rule to allow the psLens server to reach the PeopleSoft Integration Gateway. The hostname of your PeopleSoft Integration Gateway must be resolvable from the psLens server. This is often an entry in your public DNS. Most organizations do NOT expose the PeopleSoft Integration Gateway to the public internet.
If your organization exposes the PeopleSoft Integration Gateway to the public internet, you likely will not need to make any changes to your firewall.
The psLens server will be identified by a custom egress IP address that Cedar Hills Group, Inc. will configure for your instance of psLens. You will need to work with your network team to allow this IP address to reach the PeopleSoft Integration Gateway on port 443 (or your configured port). If you have any questions about the connectivity, please contact Cedar Hills Group.
PeopleSoft administrators often want to smoke test the connectivity between psLens and the PeopleSoft Integration Gateway before we configure the psLens web application. The following curl command can be used to test the connectivity. You will need to replace the placeholders with your actual values.
PS_LENS_API_USER - The PeopleSoft operator ID that psLens uses to authenticate to the SWS framework. This is the account that you created in the previous step. The default value is CHG_PSLENS_API_USER.
PS_LENS_API_PASSWORD - The password for the PeopleSoft operator ID that psLens uses to authenticate to the SWS framework. This is the password that you set when you created the account.
PS_HOST - The hostname of your PeopleSoft Integration Gateway. This is the hostname that psLens will use to connect to the PeopleSoft Integration Gateway. This must be resolvable from the psLens server.
PS_PORT - The port your Integration Gateway listens on. 8000 is the PeopleSoft default for HTTP; HTTPS is frequently on 8443.
PS_NODE - The name of the PeopleSoft node that fronts the REST listening connector. The default value is PSFT_CS; use the node that matches your environment.
Keep the single quotes on the variable assignments. PeopleSoft passwords often contain !, $, or a space, and an unquoted value gets mangled by the shell before curl ever sees it. In bash and zsh, an unquoted ! triggers history expansion, the assignment fails with event not found, and curl then authenticates with an empty password.
A successful call returns HTTP 200 with a data.CHG_PSLENS_WL.fields array listing the whitelisted RECNAME values. Two common failures:
401 - the operator ID or password is wrong, or the account is locked.
404 - the node name or service operation path is wrong. Check PS_NODE against the node you created and confirm the CHG_PSLENS_SWSPQL service operation is active.
1.3 - Whitelist Tables
psLens controls which PeopleSoft tables can be queried through a whitelist table (CHG_PSLENS_WL). You need to whitelist every table that psLens reads.
Whitelist Tables
psLens controls which PeopleSoft tables can be queried through a global whitelist table (CHG_PSLENS_WL). You need to whitelist every table that psLens reads. The full list of tables (organized by feature area) is documented in the Reference section.
This page contains the SQL inserts you run once during installation. After running them, restart psLens (or wait for the next whitelist cache refresh) and confirm the Settings > Database Connections page shows the database as fully connected with no missing-table warnings.
PeopleTools Tables Common to All Features
Run all of the inserts below. Each block matches a category in the Reference page. If you add new functionality to psLens that queries a new record, add it here too.
-- Whitelist record itself (optional: CHG_PSLENS_WL is always readable by the framework)
INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('CHG_PSLENS_WL');-- Security tables
INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAUTHAS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAUTHBUSCOMP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAUTHITEM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAUTHPRCS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAUTHSIGNON');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAUTHWS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSCLASSDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMENUITEM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOBJGROUP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPRDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPROBJ');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSROLECLASS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSROLEDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSROLEUSER');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SCRTY_ACC_GRP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SCRTY_QUERY');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PTACM_ACCESSTBL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPTSCRTY_ADS_A');-- Metadata tables
INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSBCDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSBCITEM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSDBFIELD');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSDBFLDLABL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSKEYDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMENUDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSXFERITEM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPNLDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPNLFIELD');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPNLGROUP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPNLGRPDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPROJECTDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPROJECTITEM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPRSMATTRVAL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPRSMDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPRSMPERM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPRSMSYSATTR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPRSMSYSATTRVL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSRECDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSRECFIELD');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPTSF_SD');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPTSF_SD_ATTR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPTSF_SD_DCATR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPTSF_SRCCAT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPTSF_SRCCATAT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSRECDDLPARM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIDXDDLPARM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSSPCDDLPARM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSDDLMODEL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSDDLDEFPARMS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPTIONSADDL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSTBLSPCCAT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSRECTBLSPC');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSFLDDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSFLDSEGDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSFLDFIELDDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSXLATITEM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SQLSTMT_TBL');-- Integration Broker tables
INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAPMSGPUBCON');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAPMSGPUBHDR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAPMSGSUBCON');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAPMSGDOMSTAT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAPMSGDSPSTAT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBLOGHDR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBRTNGDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBAPPLDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBAPPLOPR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBAPPURI');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBAPPMETHOD');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBPARAM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBBASEPARAM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBTEMPLPARAM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBBASETMPLPRM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBAPPLSTATES');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSIBAPPLHDRPROP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGNODEDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSNODECONPROP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSNODEURITEXT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSNODESDOWN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPERATION');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPERATIONAC');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPERATIONURI');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPRHDLR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPRVERDFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPRVERDFNPARM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQUEUEDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQUEUEPART');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSRTNGDFNPARM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSRTNGDFNPROP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSSERVICE');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSSERVICEOPR');-- Process Scheduler tables
INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSDEFNGRP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSDEFNPNL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSJOBDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSJOBGRP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSJOBITEM');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSJOBPNL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSJOBMESSAGE');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSMUTUALEXCL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSRECUR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSRECURDATE');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSRECUREXEMPT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPRCSRQST');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSDEFNNOTIFY');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSDEFNCNTDIST');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSJOBNOTIFY');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PRCSJOBCNTDIST');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SERVERDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSSERVERSTAT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SERVERCATEGORY');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SERVERCLASS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SERVERNOTIFY');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('SERVEROPRTN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('DAEMONGROUP');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('DAEMONGROUP_VW');-- Developer tables
INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAEAPPLDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAEAPPLSTATE');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAEAPPLTEMPTBL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAESECTDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAESTEPDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSAESTMTDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSCONTDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSCONTENT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGATTR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGCATDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGFLDOVR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGPARTS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGREC');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGSETDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSMSGVER');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPACKAGEDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPCMNAME');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPCMPROG');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPCMTXT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYFIELD');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYRECORD');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYSTATS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYEXECLOG');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYSELECT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYCRITERIA');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYEXPR');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSQRYBIND');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSSQLDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSSQLTEXTDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSTREEDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSTREENODE');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSURLDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PT_URL_PROPS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSXPRPTDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSXPDATASRC');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSXPTMPLDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSXPTMPLFILEDEF');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSXPRPTVIEWER');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSCHGCTLDEF');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSCHGCTLLOCK');-- Audit & user profile tables
INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPTLOGINAUDIT');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSPRUFDEFN');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSUSEREMAIL');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPRALIAS');INSERTINTOPS_CHG_PSLENS_WL(RECNAME)VALUES('PSOPTIONS');
Campus Solutions Specific Tables
Only run these in a Campus Solutions database. If you run them in a non-CS database, you will get errors about missing tables.
psLens reads a config.yaml file from the same directory as the binary.
Configuration
psLens reads a config.yaml file from the same directory as the binary. There is no external database server to set up; persistent state (configuration history, report results, alert state) is stored in an embedded NATS data store.
Configuration Synchronization
Active configuration is synchronized automatically between config.yaml and the embedded NATS KV store:
Bare-Minimum Boot: The server can boot with zero configured database connections. Database connections can be added later directly through the Settings UI at /settings.
Disk Edit Recognition: On boot, if config.yaml has been modified on disk more recently than the active NATS KV store snapshot, psLens automatically syncs the file changes into NATS KV.
UI Auto Write-Back: Changes made via the Settings UI update NATS KV and automatically write back to config.yaml on disk.
Password & Secret Security Options
psLens provides three secure methods for passing database and server credentials:
1Password Secret References (op://...):
Pass 1Password Secret URIs directly in config.yaml or JSON configurations:
Set OP_SERVICE_ACCOUNT_TOKEN in the environment. Secrets resolve in-memory at boot using the 1Password SDK and are never written back to disk or KV storage in plaintext.
Master Key Encryption (PSLENS_MASTER_KEY):
Set PSLENS_MASTER_KEY (a 64-character hex AES-256 key). Passwords entered in the Settings UI or stored in NATS KV/YAML are stored as encrypted strings (ENC[...]).
Environment Variable Overrides:
Override passwords dynamically via environment variables without editing files:
exportPSLENS_DB_PROD_PASSWORD="YourPasswordHere"
Bare Minimum Configuration Example
To start psLens with zero pre-configured database connections, use the following minimal config.yaml:
server:port:8080
Full Configuration Examples
psLens supports configuration in either YAML (config.yaml) or JSON (config.json) format. The application detects the format automatically on boot.
YAML Configuration Example (config.yaml)
# Schema validation pointer (optional, for IDE support)# yaml-language-server: $schema=http://localhost:8080/static/config-schema.jsonserver:port:8080host:"0.0.0.0"natsStoreDir:"./data/nats"projectStoreDir:"./data/projects"dmsStoreDir:"./data/dms"traceStoreDir:"./data/traces"appBaseURL:"http://localhost:8080"recentlyViewed:maxItems:20databases:- name:"PROD"description:"Production PeopleSoft HR"baseURL:"https://psft.example.com:8000/PSIGW/RESTListeningConnector/PSFT_HR/CHG_PSLENS_SWSPQL/"username:"PSLENS_API"password:"your-api-password"piaURL:"https://psft.example.com/psp/ps/"timezone:"America/Chicago"production:truealerts:enabled:trueintervalMinutes:10- name:"DEV"description:"Development Environment"baseURL:"https://psftdev.example.com:8000/PSIGW/RESTListeningConnector/PSFT_HR/CHG_PSLENS_SWSPQL/"username:"PSLENS_API"password:"dev-api-password"timezone:"America/Chicago"production:falsedowntimes:- name:"Nightly Downtime"enabled:truestartTime:"22:00"endTime:"06:00"daysOfWeek:[1,2,3,4,5]- name:"Weekend Maintenance"enabled:truestartAt:"2026-07-04T00:00:00Z"endAt:"2026-07-05T23:59:59Z"alerts:enabled:trueintervalMinutes:5checks:long_running_processes:enabled:truethresholdMinutes:20anomalyMultiplier:4.0anomalyMinBaselineMinutes:10process_errors:enabled:truelookbackHours:24ib_operation_errors:enabled:truelookbackHours:24ib_pub_contract_errors:enabled:truelookbackHours:24ib_sub_contract_errors:enabled:truelookbackHours:24ib_operation_stalled:enabled:truethresholdMinutes:30ib_pub_contract_stalled:enabled:truethresholdMinutes:30ib_sub_contract_stalled:enabled:truethresholdMinutes:30genericSWSAlerts:- id:"stale_users"name:"Stale User Accounts"enabled:trueseverity:"warning"alertOn:"row_found"message:"Warning: Stale user accounts detected"query:records:- recordName:"PSOPRDEFN"sqlWhereClause:"LASTUPDDTTM < CAST('2026-01-01' AS TIMESTAMP) AND ACCTLOCK = 0"rowLimit:5auth:enabled:trueauthorizedUsers:- "admin@example.com"- "auditor@example.com"smtp:host:"smtp.mailtrap.io"port:"2525"username:"smtp-user"password:"smtp-password"fromName:"psLens Alerts"fromEmail:"alerts@pslens.example.com"notifications:subscriptions:- id:"team-email"enabled:truealertTypes:["*"]databases:["PROD"]severityMin:"warning"type:"email"target:"psoft-alerts@example.com"- id:"slack-webhook"enabled:truealertTypes:["process_errors","ib_operation_errors"]databases:["*"]type:"webhook"target:"https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"- id:"teams-webhook"enabled:truealertTypes:["*"]databases:["*"]type:"webhook"target:"https://example.webhook.office.com/webhookb2/..."reports:- id:"security-full-access-permlists"enabled:truedbNames:["PROD"]schedule:interval:"daily"timeOfDay:"02:00"emailTarget:"psoft-alerts@example.com"
JSON Configuration Example (config.json)
{"$schema":"http://localhost:8080/static/config-schema.json","server":{"port":8080,"host":"0.0.0.0","natsStoreDir":"./data/nats","projectStoreDir":"./data/projects","dmsStoreDir":"./data/dms","traceStoreDir":"./data/traces","appBaseURL":"http://localhost:8080","recentlyViewed":{"maxItems":20}},"databases":[{"name":"PROD","description":"Production PeopleSoft HR","baseURL":"https://psft.example.com:8000/PSIGW/RESTListeningConnector/PSFT_HR/CHG_PSLENS_SWSPQL/","username":"PSLENS_API","password":"your-api-password","piaURL":"https://psft.example.com/psp/ps/","timezone":"America/Chicago","production":true,"alerts":{"enabled":true,"intervalMinutes":10}},{"name":"DEV","description":"Development Environment","baseURL":"https://psftdev.example.com:8000/PSIGW/RESTListeningConnector/PSFT_HR/CHG_PSLENS_SWSPQL/","username":"PSLENS_API","password":"dev-api-password","timezone":"America/Chicago","production":false}],"alerts":{"enabled":true,"intervalMinutes":5,"checks":{"long_running_processes":{"enabled":true,"thresholdMinutes":20,"anomalyMultiplier":4.0,"anomalyMinBaselineMinutes":10},"process_errors":{"enabled":true,"lookbackHours":24},"ib_operation_errors":{"enabled":true,"lookbackHours":24},"ib_pub_contract_errors":{"enabled":true,"lookbackHours":24},"ib_sub_contract_errors":{"enabled":true,"lookbackHours":24},"ib_operation_stalled":{"enabled":true,"thresholdMinutes":30},"ib_pub_contract_stalled":{"enabled":true,"thresholdMinutes":30},"ib_sub_contract_stalled":{"enabled":true,"thresholdMinutes":30}},"genericSWSAlerts":[{"id":"stale_users","name":"Stale User Accounts","enabled":true,"severity":"warning","alertOn":"row_found","message":"Warning: Stale user accounts detected","query":{"records":[{"recordName":"PSOPRDEFN","sqlWhereClause":"LASTUPDDTTM < CAST('2026-01-01' AS TIMESTAMP) and ACCTLOCK = 0"}],"rowLimit":5}}]},"auth":{"enabled":true,"authorizedUsers":["admin@example.com","auditor@example.com"]},"smtp":{"host":"smtp.mailtrap.io","port":"2525","username":"smtp-user","password":"smtp-password","fromName":"psLens Alerts","fromEmail":"alerts@pslens.example.com"},"notifications":{"subscriptions":[{"id":"team-email","enabled":true,"alertTypes":["*"],"databases":["PROD"],"severityMin":"warning","type":"email","target":"psoft-alerts@example.com"},{"id":"slack-webhook","enabled":true,"alertTypes":["process_errors","ib_operation_errors"],"databases":["*"],"type":"webhook","target":"https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"},{"id":"teams-webhook","enabled":true,"alertTypes":["*"],"databases":["*"],"type":"webhook","target":"https://example.webhook.office.com/webhookb2/..."}]},"reports":[{"id":"security-full-access-permlists","enabled":true,"dbNames":["PROD"],"schedule":{"interval":"daily","timeOfDay":"02:00"},"emailTarget":"psoft-alerts@example.com"}]}
Server Settings
The server section controls how psLens listens for incoming connections and where it stores data.
Setting
Default
Description
port
8080
TCP port psLens listens on
host
0.0.0.0
Network interface to bind (use 127.0.0.1 to restrict to localhost)
natsStoreDir
./data/nats
Directory for persistent NATS data (report results, alert history)
projectStoreDir
./data/projects
Directory for uploaded PeopleSoft project XML definitions
dmsStoreDir
./data/dms
Directory for imported Data Mover (DMS) script libraries
traceStoreDir
./data/traces
Directory for uploaded PeopleSoft trace files (.tracesql, .trc, .aet)
outageRetentionDays
90
Retention period in days for historical downtime and outage events stored in NATS JetStream.
Tip: Storage directories (natsStoreDir, traceStoreDir, etc.) can also be configured via environment variables (PSLENS_TRACE_STORE_DIR, PSLENS_PROJECT_STORE_DIR, etc.) and should be placed on persistent storage.
Database Connections
You can configure one or more PeopleSoft databases under the databases list. psLens monitors the health of each connection and shows status on the dashboard.
Setting
Required
Description
name
Yes
Short identifier shown in the UI (e.g., PROD, DEV)
description
Yes
Human-readable label for the database
baseURL
Yes
Full URL to the SWS psoftQL endpoint, including the service name
username
Yes
PeopleSoft operator ID for API authentication
password
Yes
Password for the operator ID
piaURL
No
Base URL for PeopleSoft Internet Architecture (used for deep links to PeopleSoft pages, if supported)
timezone
No
IANA timezone name for the database server (e.g., America/Chicago). Defaults to UTC if not set. Used to interpret timestamps correctly.
downtimes
No
List of scheduled downtime windows to suppress alerts and monitoring.
notifications
No
Database-specific notification delivery settings (bypasses global subscriptions).
Scheduled Downtimes
Downtimes allow silencing alerts and pausing connection health checks for non-production environments that go offline regularly (e.g., overnight or on weekends).
Each entry in the downtimes list supports the following settings:
Setting
Required
Description
name
Yes
Identifier for the downtime window.
enabled
Yes
Whether the downtime rule is active.
startTime
No
Start time of day in HH:MM format (e.g., 22:00). Set together with endTime.
endTime
No
End time of day in HH:MM format (e.g., 06:00). An end time earlier than the start crosses midnight. 24:00 means end of day, so an all-day window is 00:00–24:00.
daysOfWeek
No
Array of integers for days of week. 0 is Sunday, 1 is Monday, …, 6 is Saturday. Omit to apply every day. An overnight window belongs to the day it starts.
startAt
No
Specific start timestamp in RFC3339 format (e.g., 2026-07-04T00:00:00Z) for one-off maintenance.
endAt
No
Specific end timestamp in RFC3339 format (e.g., 2026-07-05T23:59:59Z) for one-off maintenance.
startTime/endTime are wall-clock times in the connection’s timezone (UTC if unset). Rules are validated when the configuration is saved; a rule must define a recurring window (startTime + endTime) and/or a one-off range (startAt/endAt).
When a database is in a scheduled downtime, the connection manager sets its status to Downtime on the dashboard, background alert checks are skipped (including the Integration Broker down check), email/webhook notifications are suppressed, and the database does not count against overall health. When the window ends, psLens rechecks the connection immediately and treats the first failed check as a real outage — size windows to cover the system’s boot time.
A weekend window that spans from Saturday evening to Monday morning is composed of two rules, since an overnight window belongs to its start day:
downtimes:- name:"Weekend nights"enabled:truestartTime:"22:00"endTime:"06:00"daysOfWeek:[6,0]# Sat night -> Sun morning, Sun night -> Mon morning- name:"Sunday all day"enabled:truestartTime:"00:00"endTime:"24:00"daysOfWeek:[0]
The baseURL Format
The baseURL is the Integration Broker REST endpoint for the SWS service. It follows this pattern:
Sensitive settings like passwords can be overridden with environment variables to avoid storing them in config.yaml. The override format is:
PSLENS_DB_{NAME}_{FIELD}
Where {NAME} matches the name field of the database in config.yaml.
For Fly.io and Docker container compatibility, non-alphanumeric characters (such as dashes - or dots .) in database names are automatically converted to underscores (_) and uppercased.
For example, for a database named COOL-DB-FOR-DEV, you can use:
If OP_SERVICE_ACCOUNT_TOKEN (or PSLENS_OP_SERVICE_ACCOUNT_TOKEN) is set, psLens resolves all op:// references on boot using the 1Password SDK. If the environment variable is not set, 1Password resolution is skipped.
Database-Specific Notifications
By default, alert notifications for all databases are routed using global subscription rules (see Notifications & Webhooks Settings).
However, you can configure database-specific notifications under the notifications property of a database entry. Doing so acts as a complete override: all alerts (regardless of severity level) and resolutions for that specific database are routed directly to the database-level targets, bypassing global subscriptions entirely.
Each entry in the notifications block supports the following settings:
Setting
Type
Description
emailEnabled
Boolean
Activates email notifications for this database.
emailTarget
String
Comma-separated list of recipient email addresses.
webhookEnabled
Boolean
Activates webhook notifications for this database.
webhookTarget
String
Webhook destination URL (e.g., Slack, MS Teams, or a generic endpoint).
Example database connection configuration with inline notifications:
Each alert type under checks supports some or all of the following settings:
Setting
Description
enabled
Whether this check is active
thresholdMinutes
For stalled/long-running checks: how many minutes before flagging (default varies by check). For long_running_processes, this is the fallback static threshold.
lookbackHours
For error checks: how many hours back to look for failures (default varies by check)
excludeProcesses
List of process names to skip (for process-related checks)
excludeOperations
List of IB operation names to skip (for Integration Broker checks)
anomalyMultiplier
Multiplier applied to the rolling median duration to calculate the dynamic threshold (default: 4.0)
anomalyMinBaselineMinutes
Minimum baseline duration in minutes. Dynamic thresholds are capped to be at least this value to prevent false alerts on very fast processes (default: 10)
Available Alert Checks
Check Key
Name
Description
long_running_processes
Long-Running Processes
Flags processes running longer than their rolling median-based expected runtime (or thresholdMinutes fallback)
process_errors
Process Errors
Finds processes that failed within lookbackHours (default: 24 hours)
ib_operation_errors
IB Operation Errors
Finds async IB operations in Error or Timeout status within lookbackHours (default: 24 hours)
ib_pub_contract_errors
IB Publication Contract Errors
Finds pub contracts in Error or Timeout status within lookbackHours (default: 24 hours)
ib_sub_contract_errors
IB Subscription Contract Errors
Finds sub contracts in Error or Timeout status within lookbackHours (default: 24 hours)
ib_operation_stalled
IB Operations Stalled
Finds async IB operations stuck in New or Working status longer than thresholdMinutes (default: 30 min)
ib_pub_contract_stalled
IB Publication Contracts Stalled
Finds pub contracts stuck in New or Working status longer than thresholdMinutes (default: 30 min)
ib_sub_contract_stalled
IB Subscription Contracts Stalled
Finds sub contracts stuck in New or Working status longer than thresholdMinutes (default: 30 min)
locked_oprid_processes
Locked OPRID Scheduled Processes
Finds queued or scheduled processes whose submitting OPRID has a locked account
backlogged_processes
Backlogged Processes
Detects processes currently stuck in a Queued or Blocked state longer than thresholdMinutes (default: 30 min)
queue_latency
Queue Latency
Detects processes that experienced a start delay (BEGINDTTM - RUNDTTM) greater than thresholdMinutes (default: 15 min)
failed_logins
Failed Logins
Detects users with excessive failed login attempts in PSPTLOGINAUDIT (defaults to > thresholdCount of 5)
process_run_check
Process Run Check
Monitors configured critical processes and alerts when they haven’t run successfully within their configured time window
ib_operation_volume
Abnormal IB Operation Volume
Detects when IB operation instance volume exceeds the historical average by a percentage specified in thresholdCount (default: 50)
ib_pub_contract_volume
Abnormal IB Pub Contract Volume
Detects when IB publication contract volume exceeds the historical average by a percentage specified in thresholdCount (default: 50)
ib_sub_contract_volume
Abnormal IB Sub Contract Volume
Detects when IB subscription contract volume exceeds the historical average by a percentage specified in thresholdCount (default: 50)
ib_sync_exceptions
IB Sync Operation Exceptions
Detects synchronous service operations with errors in PSIBLOGHDR within lookbackHours (default: 24 hours). Disabled by default.
no_process_completed
No Process Completed
Fires when no process has successfully completed within the lookbackHours (default: 1 hour)
ib_down
Integration Broker Down
Alerts when SWS REST endpoint connection failures indicate the Integration Broker is down
weblib_down
Web Server / WebLib Down
Alerts when PeopleSoft Web Server is down or configured WebLib URLs fail to respond
ib_no_active_domain
IB No Active Domain
Alerts when there is no active domain found in PSAPMSGDOMSTAT
ib_dispatcher_down
IB Dispatcher Down
Alerts when an Integration Broker dispatcher process is inactive or has not updated status within thresholdMinutes (default: 10 min)
ib_nodes_down
IB Nodes Down
Alerts when there are entries in PSNODESDOWN indicating message nodes are down
Authentication Settings
The auth section configures native authentication (email-based magic link or native OpenID Connect SSO). Authentication is enabled by default. To disable authentication, set enabled: false explicitly in config.yaml. Authentication settings are file-authoritative and cannot be modified or turned off from the web interface.
Setting
Default
Description
enabled
true
Defaults to true. To disable, set to false explicitly in config.yaml.
mode
magic_link
Authentication mode: magic_link or oidc.
authorizedUsers
[]
Whitelist of email addresses allowed to log in (case-insensitive).
OIDC authorization scopes requested from the Identity Provider.
oidc.allowedGroups
[]
Optional list of required group claims to restrict access.
oidc.groupClaim
groups
Claim key in the ID token used for group membership verification.
ipAllowlist.enabled
false
Enable IP allowlist enforcement. Fails closed (denies all) if list is empty.
ipAllowlist.allowedCIDRs
[]
List of allowed CIDR blocks or IP addresses (e.g. ["10.0.0.0/8", "192.168.1.50"]).
SMTP Settings
The email server is edited in the app under Settings → Notifications (Email Server card). Changes apply to alert and report emails immediately; login (magic link) emails pick them up after the next server restart. A blank password on save keeps the stored password.
The smtp block in config.yaml seeds the email server on first boot only; after that, the settings saved in the UI are authoritative. PSLENS_SMTP_* environment variables override both and make the card read-only in the UI.
Setting
Default
Description
host
-
SMTP server hostname/IP (supports op:// 1Password references)
port
-
SMTP port (e.g. 25, 465, 587, 2525, supports op:// references)
username
-
Username for SMTP auth (supports op:// 1Password references)
password
-
Password for SMTP auth (supports op:// 1Password references)
fromName
psLens
Sender name shown in emails (supports op:// 1Password references)
fromEmail
-
Sender email address for SMTP (supports op:// 1Password references)
Outbound email can be tested on the same card: enter a recipient address under Send Test Email and click Send Test. The result is recorded in Alert Delivery History.
Notifications & Webhooks Settings
Notification rules decide where alert messages are dispatched. They are managed in the app under Settings → Notifications, where email distribution lists, webhook destinations (Slack, Microsoft Teams, and custom endpoints), and subscription routing rules can be configured and live-tested.
Email Distribution Lists (notifications.email_lists)
Predefined recipient lists referenced by notifications and reports:
For production deployments, you should restrict access to the psLens interface.
Recommended Security Controls
Enable Built-In Magic Link Auth:
Turn on auth.enabled and configure SMTP credentials and authorizedUsers to require code validation on login.
Setup a Master Key (PSLENS_MASTER_KEY):
Provide a 32-byte (64 hex characters) key in the PSLENS_MASTER_KEY environment variable. All database and SMTP passwords entered in the UI or configuration are then encrypted at rest using AES-256-GCM.
Reverse Proxy / VPN:
Place psLens behind a reverse proxy (e.g., Cloudflare Access, oauth2-proxy, nginx, Tailscale) to delegate authentication to your company’s Identity Provider (SAML/OIDC). When using an external SSO proxy, you can keep auth.enabled disabled and restrict the psLens binary to bind only on 127.0.0.1 or internal networks.
Warning: Never expose psLens to the public internet without either turning on the built-in magic-link auth or placing an authenticated reverse proxy in front of it. Doing so exposes read access to PeopleSoft system metadata.
Active Configuration and Hot-Reloading
psLens keeps its settings in two places:
Active configuration (embedded key-value store): when you edit connections, credentials, email settings, alert schedules, or notification rules in the web interface, changes are saved here and take effect immediately without a server restart. Every change is kept as a numbered revision under Settings → Change History, where any revision can be viewed or restored.
config.yaml on disk: the bootstrap file that seeds the active configuration on first boot. Saved changes are also written back to it as a backup on the persistent storage volume.
Configuration Seeding
On initial boot, or when the environment variable PSLENS_FORCE_SEED_CONFIG=true is set, the application seeds the active configuration from config.yaml.
If the active configuration drifts from config.yaml, the Settings → Advanced page shows a “Settings differ from the config.yaml file on disk” notice. To resolve it:
Click Load settings from config.yaml on the Advanced page to overwrite the active configuration with the file contents (this discards changes made in the UI).
If the file path is writable, click Overwrite config.yaml on disk to write the active configuration to the file. On containerized or ephemeral deployment models (like fly.io without persistent storage volumes), these local file changes will be lost when the container restarts or is re-deployed.
Alternatively, copy the Active Configuration YAML from the Advanced page into your config.yaml file to bring the disk file in sync.
Secret Key Management (Encryption at Rest)
When the PSLENS_MASTER_KEY environment variable is set with a 32-byte hex-encoded key, all database and SMTP passwords entered in the UI are encrypted at rest. If the master key is not configured, passwords are saved in plaintext.
Rotating the Master Key
To rotate the cryptographic key used for credential encryption:
Enter a new 32-byte hex key in the Rotate Encryption Key field.
Click Rotate Master Key. The server decrypts all stored credentials using the old key and re-encrypts them with the new key in NATS KV.
Update the PSLENS_MASTER_KEY environment variable in your deployment configuration (e.g., Fly.io secrets or .env file) to match the new key before restarting the container. If the container restarts with a mismatched key, it cannot decrypt the configuration.
1.5 - Deployment Options
This page is for clients who want to host psLens themselves in a Docker container. It covers three questions in order:
Deployment Options
This page is for clients who want to host psLens themselves in a Docker container. It covers three questions in order:
How do I get the image? Distribution and authentication.
How do I upgrade without losing my config? Volumes, env vars, and the master key.
How do I do HTTPS? Six TLS options compared on the same axes.
If you just want a 5-minute install on a private network, the Installation page is enough. Come back here when you’re ready to put psLens in front of real users.
1. Image Distribution
psLens is published to the GitHub Container Registry (GHCR) as a private package. Cedar Hills Group issues a read-only token to each client.
Authenticating
Cedar Hills Group sends you a GitHub fine-grained personal access token (PAT) scoped to read:packages on the pslens package only.
The credentials are stored in ~/.docker/config.json. They persist across host reboots.
Verify the pull works:
docker pull ghcr.io/cedarhillsgroup/pslens:latest
Image Tags
The release pipeline publishes four tag flavors for every release:
Tag
Example
Use when
latest
ghcr.io/cedarhillsgroup/pslens:latest
Dev/test only — never pin production here
vMAJOR.MINOR.PATCH
:v1.4.2
Production — exact reproducibility
vMAJOR.MINOR
:v1.4
Production — auto-pickup of patch releases
Git SHA
:a3f8c12
Pinning to a pre-release build
Recommended: Pin production to vMAJOR.MINOR. You’ll automatically pick up patch fixes when you re-run docker compose pull, but never get an unexpected breaking change from a minor or major version bump.
When You Can’t Reach ghcr.io
If the Docker host can’t make outbound HTTPS to ghcr.io (common in segmented enterprise networks), use the air-gapped flow documented in Installation:
# On a machine with internet access:docker pull ghcr.io/cedarhillsgroup/pslens:v1.4.2
docker save ghcr.io/cedarhillsgroup/pslens:v1.4.2 | gzip > pslens-v1.4.2.tar.gz
# Transfer the .tar.gz to the target host (USB, internal artifact repo, etc.), then:docker load < pslens-v1.4.2.tar.gz
You can also mirror the image into your own private registry (Harbor, AWS ECR, Azure ACR, GitLab Registry). Pull it once, retag, push, and reference the mirrored image in your docker-compose.yml. Cedar Hills Group is happy to provide a one-time pull script if you need to automate this.
Troubleshooting Pull Failures
Error
Cause
Fix
denied: denied
Token expired or revoked
Renew the PAT with Cedar Hills Group
unauthorized
Token has the wrong scope
PAT needs read:packages on the pslens package
no basic auth credentials
docker login wasn’t run, or ~/.docker/config.json was lost
Re-run docker login ghcr.io
manifest unknown
The tag you asked for doesn’t exist yet
Check the release notes for available tags
2. Configuration and Secrets
The most failure-prone part of self-hosted deployment is preserving configuration and secrets through upgrades. This section is explicit about what survives docker compose pull && docker compose up -d and what doesn’t.
What Persists, What Doesn’t
Persistent (must be on a volume):
/data/nats — NATS JetStream store. Contains the recently-viewed objects KV, the report store (generated markdown reports), alert state, and, if you use the in-app config UI, the AES-256-encrypted database passwords KV.
/data/projects — project store for uploaded .zip project archives.
/app/config.yaml — bind-mounted from the host filesystem.
Ephemeral (re-created on every container start):
Whitelist cache (re-fetched from PeopleSoft on startup).
PIA URL discovery cache.
In-memory session state.
The default docker-compose.yml in Installation already wires the persistent items correctly: a named volume pslens_data mounted at /data, and config.yaml bind-mounted at /app/config.yaml:ro. As long as you don’t docker volume rm pslens_data, your data survives any number of image upgrades.
Three Configuration Modes
There are three ways to source configuration. Pick one based on how many people will administer the system and how you manage secrets.
Mode
Where config lives
Where secrets live
Best for
A. File-only
config.yaml bind-mounted from host
Plaintext in config.yaml
Internal-only dev/test
B. File + env override
config.yaml for non-secrets
PSLENS_DB_{NAME}_PASSWORD env vars, sourced from .env or a secrets manager
Recommended default for client-hosted
C. KV-encrypted
Minimal config.yaml; full config in NATS KV bucket, AES-256 encrypted at rest
Encrypted blob in /data/nats, unlocked by PSLENS_MASTER_KEY
Multi-admin setups where you use the in-app config UI
Mode B example (recommended)
config.yaml:
server:port:8080host:"0.0.0.0"appBaseURL:"https://pslens.example.com"natsStoreDir:"/data/nats"databases:- name:"PROD"description:"Production HCM"baseURL:"https://psft.example.com:8000/PSIGW/RESTListeningConnector/PSFT_HR/CHG_PSLENS_SWSPQL/"username:"PSLENS_API"password:"placeholder"# Overridden by PSLENS_DB_PROD_PASSWORDtimezone:"America/Chicago"
.env (sibling of docker-compose.yml, chmod 600, gitignored):
docker-compose.yml references env_file: .env; Docker injects every variable into the container at startup.
Tip: The env-var override convention is PSLENS_DB_{NAME}_PASSWORD where {NAME} is the database name from config.yaml, uppercased. For a database named DEV_HR, the variable is PSLENS_DB_DEV_HR_PASSWORD.
About PSLENS_MASTER_KEY
In production, psLens requiresPSLENS_MASTER_KEY to be set. It’s used to encrypt database passwords stored in the NATS KV bucket. Generate one once:
openssl rand -base64 32
Critical: back this key up out-of-band in your password manager, AWS Secrets Manager, HashiCorp Vault, or wherever you keep root-of-trust secrets. If you lose the master key, the encrypted password blob in /data/nats becomes unrecoverable and you’ll have to re-enter every database password.
Backups
Daily backup of the data volume is one line:
docker run --rm \
-v pslens_data:/data \
-v $(pwd):/backup \
alpine tar czf /backup/pslens-data-$(date +%F).tar.gz -C / data
What to back up where:
Data volume (pslens_data) — daily tarball, retain 14-30 days. Captures reports, alert state, and encrypted passwords KV.
config.yaml — check into your infrastructure-as-code repo (gitignore the password fields, or use the placeholder pattern from Mode B).
.env — store in your secrets manager. Never check this into git.
To restore: stop psLens, docker volume create pslens_data, untar into the volume, restart.
3. TLS / HTTPS Options
psLens does not terminate TLS in the binary by default. It listens on plain HTTP and expects either a reverse proxy, an in-binary TLS configuration, or a tunnel to provide HTTPS.
There are six viable options. They’re compared below on the same axes: certificate source, automation, operational complexity, and the scenario each fits best.
Quick recommendation
Your scenario
Recommended option
Default — most clients
Option 3: Caddy sidecar
Corporate PKI with certs-as-code
Option 4: nginx sidecar (or Option 1 if minimalist)
Internal-only, small team, already using Tailscale
Option 6: Tailscale Serve / Funnel
Already running Traefik
Option 5: Traefik
Public internet, single host, no proxy wanted
Option 2: in-binary autocert
Details on each option follow.
Option 1: Go-native TLS via crypto/tls (cert files)
psLens loads a PEM cert + key from disk and serves TLS directly. No reverse proxy, no extra container, no external dependencies.
Status: This requires a small code change to psLens (currently the binary only listens on plain HTTP). Contact Cedar Hills Group if you need this option — it’s roughly 30 lines of Go and a config block. Tracked in the backlog.
Cert cache lives in /data/acme so it survives container restarts as long as the pslens_data volume does. psLens listens on :80 for the ACME HTTP-01 challenge and :443 for TLS.
Axis
Detail
Certificate source
Let’s Encrypt (free, 90-day, auto-renewed at ~60 days)
Renewal
Fully automatic, in-process
Hot reload
N/A — the library reloads on its own renewal cycle
Pros
Cheapest TLS, zero ops effort after initial config
Cons
Requires port 80 reachable from the public internet for HTTP-01 challenge; rules out fully internal deployments
Best for
Public-internet hosts on a real domain (pslens.client.com)
Option 3: Caddy sidecar
Run Caddy as a second service in the same docker-compose.yml. Caddy terminates TLS and reverse-proxies to psLens on the internal Docker network.
You’ll need to add Caddy’s root cert to client browsers (push it via MDM) so they trust the internal cert.
docker-compose.yml addition:
services:pslens:image:ghcr.io/cedarhillsgroup/pslens:v1.4expose:- "8080"# no longer "ports:" — only Caddy needs an external portvolumes:- ./config.yaml:/app/config.yaml:ro- pslens_data:/dataenv_file:.envrestart:unless-stoppedcaddy:image:caddy:2-alpineports:- "80:80"- "443:443"volumes:- ./Caddyfile:/etc/caddy/Caddyfile:ro- caddy_data:/data- caddy_config:/configrestart:unless-stoppedvolumes:pslens_data:caddy_data:caddy_config:
Axis
Detail
Certificate source
Let’s Encrypt (public), or Caddy’s built-in CA (tls internal)
Renewal
Fully automatic; cert state in the caddy_data volume
Hot reload
Caddy reloads certs on its own renewal cycle
Pros
Trivial config, handles both public-internet and internal-only, decouples TLS from the app (restarting psLens doesn’t drop TLS sessions)
Cons
Second container to operate; internal CA requires distributing the root cert to clients
Best for
The default recommended option for most client deployments
Option 4: nginx sidecar
Same shape as Caddy but with nginx, using customer-provided cert files.
nginx.conf:
events{}http{server{listen443sslhttp2;server_namepslens.example.com;ssl_certificate/certs/pslens.crt;ssl_certificate_key/certs/pslens.key;ssl_protocolsTLSv1.2TLSv1.3;location/{proxy_passhttp://pslens:8080;proxy_set_headerHost$host;proxy_set_headerX-Real-IP$remote_addr;proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;proxy_set_headerX-Forwarded-Proto$scheme;# Server-Sent Events: disable buffering for the SSE endpoints
proxy_bufferingoff;proxy_cacheoff;}}server{listen80;server_namepslens.example.com;return301https://$host$request_uri;}}
Important for psLens: the proxy_buffering off directive is required. psLens relies on Server-Sent Events for most of the UI; with buffering enabled, the UI will appear frozen until pages finish loading entirely.
Cert renewal is a separate concern, typically certbot run as a host cron job that replaces the files in ./certs/ and signals nginx with docker compose exec nginx nginx -s reload.
Axis
Detail
Certificate source
Customer-managed PEM (corporate CA, commercial CA, certbot)
The most-deployed reverse proxy on earth; every enterprise ops team has nginx runbooks; easy to add request-level customization (auth, rate-limits, rewrites)
Cons
No built-in cert automation; more boilerplate than Caddy for the same outcome on the happy path
Best for
Clients who already standardize on nginx, or who need request-level customization
Option 5: Traefik sidecar
Same shape as Caddy but Traefik discovers routes from Docker labels on the psLens service. Useful only if the client already runs Traefik.
Bypass TLS-at-psLens entirely by exposing the service over a managed tunnel. TLS terminates at the tunnel provider’s edge; psLens stays on plain HTTP inside the tunnel.
Tailscale Serve (private to your tailnet — internal use):
You’ll get a URL like https://pslens.tailnet-name.ts.net. Tailscale issues and renews the cert. Only members of your tailnet can reach it.
Tailscale Funnel (public internet via Tailscale’s edge):
tailscale funnel --bg 443
Same URL shape; reachable from the public internet but rate-limited and not designed for high-volume traffic. Fine for an admin dashboard.
Cloudflare Tunnel (public, no inbound ports):
Install cloudflared on the Docker host (or run it as a sidecar container). Authenticate, create a tunnel, point a Cloudflare-managed DNS name at it.
Axis
Detail
Certificate source
Tunnel provider (Tailscale or Cloudflare)
Renewal
Fully automatic
Pros
Zero TLS config on the psLens side; no inbound ports opened on the firewall; mesh networking (Tailscale) is great for multi-DB connectivity
Cons
Adds a third-party dependency in the data path; some clients have policies against cloud tunnels for compliance-relevant tools; rate limits
Best for
Internal-only deployments where you want easy access for a small team without standing up a reverse proxy or opening firewall ports
4. Upgrades
The upgrade flow depends on whether you can reach ghcr.io and whether you’re pinning to a specific version. The data volume and config.yaml are untouched in all three cases.
Standard (online) upgrade
If you pinned to :latest or to a vMAJOR.MINOR tag that’s auto-receiving patch fixes:
cd /opt/pslens
docker compose pull pslens
docker compose up -d pslens
pull fetches the new image; up -d recreates the psLens container with the new image and reattaches the existing volume and config. Data is preserved.
Pinned-version upgrade (recommended for production)
To upgrade to v1.5: edit the file, then pull and recreate:
# Edit docker-compose.yml: v1.4 to v1.5docker compose pull pslens
docker compose up -d pslens
Rollback is a one-line edit back to the previous tag, then docker compose up -d pslens again. The old image is still in the local Docker cache (unless you ran docker image prune in between).
Air-gapped upgrade
# On a machine with internet:docker pull ghcr.io/cedarhillsgroup/pslens:v1.5
docker save ghcr.io/cedarhillsgroup/pslens:v1.5 | gzip > pslens-v1.5.tar.gz
# Transfer the .tar.gz to the target host, then:docker load < pslens-v1.5.tar.gz
docker compose up -d pslens
Cedar Hills Group’s breaking-change contract
Stable across minor versions: env-var names (PSLENS_DB_{NAME}_PASSWORD, PSLENS_MASTER_KEY), volume mount paths (/data, /app/config.yaml), and the data on disk.
Documented in CHANGELOG.md: any config schema change. Schema changes happen on major version bumps.
Automatic: NATS KV bucket schema migrations run on first start of a new version.
Before a major-version upgrade: always take a backup of the pslens_data volume (see Backups above). If something goes wrong, you can restore the volume and roll the image back to the previous tag.
Restrict hosted psLens instance access strictly to authorized corporate IP addresses and CIDR subnets.
IP & CIDR Allowlist
psLens supports network-level IP address and CIDR subnet restrictions. When enabled, incoming HTTP requests from IP addresses outside the allowlist are immediately blocked with an HTTP 403 Forbidden response before any session authentication or application routing takes place.
Configuration
Add the security.ipAllowlist block to your config.yaml:
When psLens runs behind a reverse proxy, load balancer, or cloud provider (e.g. Fly.io, Cloudflare, AWS Application Load Balancer), client requests terminate at the proxy. Setting trustForwardHeaders: true enables client IP inspection in the following precedence:
Fly-Client-IP (Fly.io edge proxy)
CF-Connecting-IP (Cloudflare CDN)
X-Real-IP (Nginx / standard reverse proxies)
X-Forwarded-For (First IP in comma-separated proxy list)
RemoteAddr (Direct TCP connection socket)
Health Check Probes Exemption
The /healthz endpoint is always exempt from IP filtering. This ensures infrastructure health checks (Kubernetes liveness/readiness probes, Fly.io health monitors, AWS target groups) continue to report accurate instance health without needing proxy IP whitelisting.
Dynamic Updates
When configuration is managed via NATS KV / settings, IP allowlist changes take effect immediately on subsequent requests without requiring server restarts.
1.7 - SSO & OIDC Discovery
Set up native Single Sign-On (SSO) using OpenID Connect discovery for Microsoft Entra ID, Okta, Google Workspace, Keycloak, or Auth0.
Single Sign-On (SSO) with OpenID Connect
psLens supports native Single Sign-On (SSO) via OpenID Connect (OIDC). Instead of manually entering authorization and token endpoints in YAML files, psLens provides an automated discovery tool at /settings/auth that queries /.well-known/openid-configuration directly from your Identity Provider.
Setting Up Single Sign-On in psLens
Navigate to Settings → Authentication & SSO (/settings/auth).
Set the login method to Native OIDC / Single Sign-On.
Choose your Identity Provider preset or enter the Issuer URL:
Microsoft Entra ID (Azure AD):https://login.microsoftonline.com/{TENANT_ID}/v2.0
Click Discover Endpoints: psLens validates the connection and auto-detects endpoints, supported scopes, and token claim attributes.
In your Identity Provider’s App Registration console, register the exact Redirect URI displayed on the page:
https://your-pslens-domain.com/auth/callback
Paste the Client ID and Client Secret.
(Optional) Specify Allowed Groups (e.g. pslens-admins) to enforce role-based access control.
Click Save Authentication Settings. Changes take effect immediately without restarting psLens.
Supported Group Claims & RBAC
When verifying OIDC tokens, psLens extracts group memberships from the ID token claim defined in groupClaim (defaulting to groups or roles). If allowedGroups is configured, only users belonging to at least one listed group will be granted access upon successful authentication.
2 - System Overview
The health overview of all connected databases and active alerts.
System Overview
The home screen of psLens (System Overview) gives you a quick health overview of all your connected PeopleSoft databases, with a focus on anything that currently needs attention.
The psLens dashboard showing database connection status and active alerts
What You See on the Dashboard
Alert Summary
The top section of the dashboard shows active alerts grouped by database. Each alert card tells you:
What type of issue was found (for example, long-running processes or IB errors)
How many items were found in this check
When the check last ran
A link to the relevant monitor page for more detail
Alerts are color-coded by severity:
Color
Severity
Meaning
Red
Critical
Immediate attention recommended
Yellow
Warning
Should be investigated
Blue
Info
Low priority, worth noting
If there are no active alerts, the dashboard shows an “all clear” state.
Database Cards and Health Scores
For each active database connection, the dashboard renders a database card with four operational monitoring categories. Each category displays a visual 0–100 circular health ring, a health tier label, and key operational metrics:
Status Tier
Score Range
Color
Icon
Meaning
Healthy
90 – 100
Green
Operations normal; no critical issues or high error rates.
Degraded
60 – 89
Yellow
Moderate errors, stalled queues, or active warnings detected.
Critical
0 – 59
Red
Severe issues, active critical alerts, or blocked queues.
Each score begins at 100 points and applies bounded deductions based on real-time database queries and active alert states:
1. Process Scheduler Health Score
Evaluates Process Scheduler queue health, blocked jobs, and recent execution failures:
Active Critical Process Alerts: -25 points per active alert (capped at 50 points total).
Active Warning Process Alerts: -10 points per active alert (capped at 20 points total).
Currently Blocked Processes: -15 points per process currently in Blocked status (RunStatus 14, capped at 40 points total).
Process Errors Today: -2 points per process ending in Error (3), Not Successful (10), or Warning (13) since midnight (capped at 20 points total).
2. Integration Broker Health Score
Evaluates messaging throughput, stalled contracts, and synchronous/asynchronous transaction failures:
Active Critical IB Alerts: -25 points per active alert (capped at 50 points total).
Active Warning IB Alerts: -10 points per active alert (capped at 20 points total).
IB Errors & Timeouts Today: -2 points per failed or timed-out message since midnight (capped at 30 points total).
IB Working / Stalled Items Today: -2 points per message in New or Working status since midnight (capped at 15 points total).
3. User Logins (24h) Health Score
Evaluates authentication activity and failed sign-on attempts over the rolling 24-hour window:
Active Failed Logins Alert: -30 points if the failed_logins critical alert is currently firing.
Unique Users with Failed Logins (last 24h): -1 point per unique operator ID with failed login attempts recorded in PSPTLOGINAUDIT (capped at 30 points total).
4. Active Alerts Health Score
Evaluates the overall system alert posture across all enabled alert checkers:
Active Critical Alerts: -25 points per active critical alert across any checker (capped at 60 points total).
Active Warning Alerts: -10 points per active warning alert across any checker (capped at 30 points total).
Active Info Alerts: -2 points per active informational alert (capped at 10 points total).
Note on Muted Alerts: Alerts that are currently muted (suppressed) in psLens are excluded from health score deductions so maintenance windows or known issues do not artificially lower the score.
Database Connection Status
The dashboard also shows whether psLens can connect to each configured database. A database that is unreachable will still show in the list but will be marked as disconnected. Alerts for a disconnected database won’t run until the connection is restored.
How Alerts and Health Scores Are Refreshed
The dashboard uses a live connection to the psLens server. Alert results are updated automatically on the page as new check results arrive — you do not need to manually refresh.
Alert checks run on a background schedule (default: every 5 minutes). The timestamp on each alert card shows when that specific check last completed.
Navigating from the Dashboard
Each alert item on the dashboard has a direct link to the relevant page in psLens. For example:
A long-running process alert links to the Process Monitor entry for that process instance
An IB operation error alert links to the IB Monitor entry for that operation
A process error alert links to the Process Monitor entry for that process
Dismissing Alerts
Alert results are automatically cleared when the underlying issue resolves. For example, if a long-running process finishes, its alert disappears from the dashboard on the next check cycle. There is no manual dismiss — the alerts always reflect the current state of the system.
Alert Configuration
Alerts are configured in config.yaml. You can enable or disable individual alert types, adjust thresholds, and exclude specific processes or operations. See Configuration and Alerts for details.
3 - Monitor
Real-time operations monitoring dashboards for the Process Scheduler and Integration Broker.
Monitor
psLens provides two operational monitoring dashboards to keep track of the background activity and integration health of your PeopleSoft environments in real time.
Process Monitor — Monitor running, queued, and recently completed Process Scheduler requests.
Process Heatmap — Analyze historical Process Scheduler density and peak utilization windows.
IB Monitor — Track real-time message traffic, publication contracts, and subscription contracts flowing through the PeopleSoft Integration Broker.
3.1 - Process Heatmap
The Process Heatmap plots historical Process Scheduler activity as a day-of-week by hour-of-day grid, so you can see when the scheduler is busy.
Process Heatmap
The Process Heatmap plots historical Process Scheduler activity as a day-of-week by hour-of-day grid, so you can see when the scheduler is busy. Use it to find peak hours, scheduler idle windows, and times when a specific job actually runs.
The Process Heatmap dashboard visualizes hourly processing density to highlight peak scheduling windows.
Key Features
Density Visualization:
Each cell represents a specific hour of a specific day (e.g., Monday at 2:00 PM). The cell color ranges from light (low volume) to dark/vibrant (high volume).
Interactive Filters:
Database: Switch between your configured databases to compare load across PROD, TEST, or DEV.
Lookback Window: Select the historical date range to include in the calculation (e.g., Last 7 Days, Last 30 Days, or Last 90 Days).
Process Type / Name: Filter the heatmap to specific process types (e.g., Application Engines, SQR Reports) or individual process definitions to see when a specific job runs most frequently.
Hourly Breakdown:
Hovering over any cell reveals the exact number of processes that started, ran, or completed within that specific hour.
Use Cases
Batch Window Planning:
When scheduling a new, resource-intensive batch process, use the heatmap to find the quietest hours (lightest cells) to avoid system slowdowns or resource conflicts.
Peak Utilization Audit:
Identify when the Process Scheduler experiences maximum concurrency. If the grid is consistently dark during specific hours, it may explain CPU spikes or queue delays.
Scheduler Drift and Efficiency:
Check whether the overnight job actually ran overnight, or slipped into the workday.
3.2 - Process Monitor
The Process Monitor shows process requests that have run or are currently running.
Process Monitor
URL:/processmonitor
The Process Monitor shows process requests that have run or are currently running. This is the main operational view for the Process Scheduler — open it to see what is running, queued, or recently failed.
Process Monitor with search filters, timeline visualization, statistics, and process request details
What You Can Do
View Active and Queued Jobs: See running process requests (Initiated and Processing status) and queued or recently completed requests.
Filter and Search: Filter by process name, user, status, date range, and start delay threshold.
Monitor Start Delays and Queue Lag: View start delays (the difference between scheduled and actual begin times) highlighted directly in the results table. Filter the view to only show delayed processes, view aggregate start delay statistics, and see queue wait times plotted visually as warning-colored bars preceding process execution on the timeline.
Drill Into Details: Click a process instance to see its full details: status, run dates, server, output, and log information.
Timeline visualization with color-coded execution bars, date range statistics, top processes, and top operators
Process request results with clickable links to process instances, definitions, operators, and recurrences
When It’s Useful
Checking whether a scheduled process ran successfully.
Investigating a process failure (the detail view shows status codes and timing).
Seeing what is currently running on a server.
Responding to a Long-Running Processes alert from the dashboard.
Process Status Reference
Status
Meaning
Queued
Waiting to be picked up by a Process Scheduler server
Initiated
Server has picked up the request and is starting the process
Processing
Process is actively running
Success
Process completed successfully
Error
Process ended with an error condition
Not Successful
Process ran but reported a non-success result
Unable to Post
Output could not be delivered
Cancelled
Process was cancelled before it completed
Alerts for Process Scheduler
Two alert types monitor the Process Scheduler automatically:
Long-Running Processes — Flags processes that have been running longer than the configured threshold.
Process Errors — Finds processes that have failed within the lookback window.
When these alerts fire, the dashboard shows them with direct links to the relevant Process Monitor entries.
3.3 - IB Monitor
The IB Monitor shows the real-time status of PeopleSoft Integration Broker message traffic.
IB Monitor
URL:/ibmonitor
The IB Monitor shows the real-time status of PeopleSoft Integration Broker message traffic. Open it when an integration is failing or messages aren’t moving.
Integration Broker Monitor with status filters, time range selection, and operation/contract tabs
Browse and audit PeopleSoft security configuration: permission lists, roles, and users.
Security
psLens browses PeopleSoft security read-only: permission lists, roles, and users. Use it to audit access without writing SQL against PSOPRDEFN, PSROLEUSER, and PSAUTHITEM. Changes still have to be made in PeopleSoft.
Permission Lists — The granular access settings that define menu, component, and page authorizations.
Roles — Collections of permission lists assigned to users.
Users — User/operator accounts and their associated roles.
User → Roles → Permission Lists → Menus/Components/Functions
When investigating access, work from the bottom up:
Start with the permission list that grants the specific access you’re concerned about.
Find which roles include that permission list.
Find which users have those roles.
Or work from the top down:
Find the user whose access you want to understand.
Look at their roles.
Drill into each role to see its permission lists.
User detail pages link out to each role. Role pages link to permission lists and back to assigned users. You can follow an access chain in three clicks without writing a join.
Permission List detail view with properties, menu authorizations, and related data options
4.1 - Permission Lists
Permission lists (PSCLASSDEFN, sometimes called classes) are the lowest-level grantable security object.
Permission Lists
URL:/permissionlists
Permission lists (PSCLASSDEFN, sometimes called classes) are the lowest-level grantable security object. Every menu, component, page, and function authorization attaches to one.
Walkthrough: Exploring Permission Lists in psLens
Permission list detail page with the core definition and the access relationships needed for audit work
What You Can Do
View Full Definitions: See description, last modified information, and general settings.
View Authorizations: See which menus and components the permission list authorizes.
Compare Permission Lists (Security Diff Tool): Compare two permission lists across environments (e.g. DEV vs PROD) or within the same database at /permissionlists/compare (accessible from the Security > Compare Permission Lists sidebar menu or search header), analyzing deltas across signon windows, components, action masks, web libraries, service operations, CIs, process groups, and query access groups in a continuous-scroll layout with sticky navigation.
View Assigned Roles: See which roles include this permission list.
Sign-on Settings: View allowed sign-on times and other access constraints.
When It’s Useful
Auditing what access a particular permission list grants before assigning it.
Comparing security configurations between environments to identify permission drift.
Incident response: what could a compromised permission list have touched.
Roles (PSROLEDEFN) are named bundles of permission lists. Users get roles, not permission lists directly.
Roles
URL:/roles
Roles (PSROLEDEFN) are named bundles of permission lists. Users get roles, not permission lists directly.
Walkthrough: Exploring Roles in psLens
Role detail page with the permission lists, users, and aggregate access needed to understand what the role actually grants
What You Can Do
View Included Permission Lists: See the list of permission lists assigned to the role.
View Assigned Users: See which users are assigned this role.
Compare Roles (Cross-Database Diff Tool): Compare two role definitions across databases (or within the same environment) at /roles/compare (accessible from the Security > Compare Roles sidebar menu or search header). Diffs assigned permission lists, assigned users (with dynamic assignment flags), effective aggregate page/menu, web library, service operation, CI, process group, and query access groups, plus process notifications/distributions. Features continuous-scroll layout with sticky navigation, summary metrics, and Markdown export.
View Authorizations: See the aggregated Tools Access, Service Operations, Component Interfaces, Component & Page Access, Query Tree Tables, and Web Libraries granted by the permission lists assigned to the role.
Metadata Inspection: See the role’s description and last modified information.
When It’s Useful
Understanding what an unfamiliar role grants.
Checking whether a role contains permission lists that are unexpectedly broad.
Finding all users who have a particular role.
4.3 - Users
Users (PSOPRDEFN, historically called operators) are login accounts.
Users
URL:/users
Users (PSOPRDEFN, historically called operators) are login accounts. Each carries a set of roles, a primary permission list, a row-security permission list, and a process profile. Search supports both OPRID and name.
User detail page with the roles, permission lists, account metadata, and recurring jobs needed to review a user’s effective access
What You Can Do
View Assigned Roles: See the roles assigned to a user.
Compare User Profiles (Cross-Database Diff Tool): Compare two user accounts across databases (e.g. DEV vs PROD) or within the same database at /users/compare (accessible from the Security > Compare Users sidebar menu or search header). Analyzes field-by-field profile attributes, user ID aliases (PSOPRALIAS), directly assigned roles, effective permission lists, effective components & pages, web libraries, CIs, service operations, process groups, query access groups, email accounts, portal favorites, and system special-use bindings in a continuous-scroll layout with sticky navigation and Markdown export.
Core Security Attributes: See primary permission list, row security permission list, and process profile.
Account Metadata: View account status (active/inactive), last login, and email address.
Password Settings: See password-related settings (whether a password is set, when it expires).
Recurring Jobs: Check which unique batch processes the user has run on a recurrence schedule.
When It’s Useful
Checking what access a specific user has.
Reviewing user accounts during security audits.
Finding accounts that are inactive but still have broad role assignments.
Investigating who has access to a sensitive area of the system.
4.4 - Campus Solutions Security
Audit Campus Solutions row-level security grants across user defaults, academic structure, 3C groups, and administrative domain tables.
Campus Solutions Security
Campus Solutions row-level security governs application-level data access for academic institutions, careers, programs, plans, and student administrative domains. Unlike PeopleTools row-security permission lists (PSCLASSDEFN assigned via ROWSECCLASS), Campus Solutions security grants granular row-level data authorizations per user ID (OPRID) across 19 application tables.
Campus Solutions Security panel on the User detail page with the sidebar toggle enabled
What It Inspects
psLens queries the underlying Campus Solutions security tables to display effective user authorizations inline on the User detail page (/users/{oprid}):
User Defaults (OPR_DEF_TBL_CS, OPR_DEFAULT_TBL): User-level default parameters for Academic Institution, Academic Career, Academic Program, Academic Plan, Term, Aid Year, Business Unit, SetID, Campus, Admission Application Center, and Recruiter Center.
3C Group Security (OPR_GRP_3C_TBL): Administrative access for Checklists, Comments, and Communications 3C security groups.
Student & Administrative Domain Security: Authorizations for Student Groups (SCRTY_TBL_STGP), Service Indicators (SCRTY_TBL_SRVC), Milestones (SCRTY_TBL_MLSTN), Campus (SCC_STY_TBL_CMP), Admissions Actions (SCRTY_ADM_ACTN), Program Actions (SCRTY_PROG_ACTN), Application Centers (SCRTY_APPL_CTR), Recruiting Centers (SCRTY_RECR_CTR), Test Loads (SAD_TEST_SCTY), Transcripts (SCRTY_TSCRPT, SSR_SCRTY_TSRPT), and Advisement Reports (SAA_SCRTY_AARPT).
Access & Export Paths
User Detail Page Toggle: Turn on the Campus Solutions Security switch under Related Data on any user detail page (/users/{oprid}) to fetch and render CS security grants inline.
Full User Access Report: Includes Campus Solutions row-level security tables when generating on-demand or scheduled user access reports.
Markdown Export: Incorporates all active Campus Solutions user defaults and security table grants into the user definition Markdown export (/users/{oprid}/export).
When It’s Useful
Auditing what student data, academic structures, or administrative centers an advisor, registrar staff member, or admissions officer can access.
Verifying user default values (OPR_DEF_TBL_CS) when troubleshooting transaction failures or missing prompt list entries in PIA.
Reviewing effective user access during security audits without querying 19 separate security tables in SQL.
5 - Objects
Search and explore PeopleSoft metadata objects: fields, records, pages, components, queries, Integration Broker nodes, batch processes, and more.
Objects
Object Relationships — Structural guide and Mermaid diagrams illustrating how PeopleSoft fields, records, pages, components, menus, portal CREFs, and security definitions interrelate.
psLens lets you search and explore the core PeopleSoft metadata objects that define how the application is built. Every object type has the same two-step flow: a search page where you find what you’re looking for, and a detail page that consolidates everything psLens knows about that object across the database.
Useful when you need to look up an object without firing up App Designer.
Searching for records by name with results displayed as cards
Search and Navigation
How Search Works
All metadata pages share the same search behavior:
Type at least a partial name in the search box.
Results appear automatically after a short pause (no need to press Enter).
Results are paginated — scroll down to load more.
Click any result card to open the detail view.
Search auto-matches as starts with — typing PS finds PSCLASSDEFN, PSMENUITEM, and so on. For more control, include % yourself: %SECURITY (ends with), %PERS% (contains), or just % to list every row. The per-object pages below note when a specific search box uses different behavior (for example, SQL Object search runs against the SQL text body, not just the name).
Cross-Object Navigation
The detail page for each object type follows a consistent layout: main properties on the left, and a right-side Related Data sidebar with toggles that fetch additional information on demand. Toggling a panel ON fires a request, and the result loads inline. Each toggle runs a single query against the underlying tables (PSPRSMDEFN ancestors, PSPCMPROG references, etc.) and renders the result in place. The pattern is the same across every object type.
Where it makes sense, every linked reference (a record name, a field name, a component, a project) is clickable and navigates to that object’s own detail page, so you can chase a question across the application metadata in a few clicks.
Exporting Object Definitions
Every PeopleSoft object detail page in psLens supports exporting its full definition as a Markdown file. Look for the Export as Markdown card on the detail page. This is useful for documentation, code reviews, or sharing object details outside of psLens — and the structured Markdown format is ideal as input to AI tools like ChatGPT or Claude.
The export preserves object structure, related data, and code in a format that works in docs, code review, and AI workflows
Each detail page consolidates the object definition, related data, and export path in one browser view
Deep Links to PIA
Every detail page surfaces a link out to the corresponding App Designer or PIA navigation in PeopleSoft, so you can jump from a psLens view straight into the live environment when you need to make a change.
See Metadata Browsing Live
The object docs show the surface area. A live walkthrough is where the value becomes obvious: how quickly a user can move from a name search to the exact record, page, component, service, or process definition they need.
Relationships and database table mappings between PeopleSoft fields, records, pages, components, menus, portal CREFs, Component Interfaces, Integration Broker, Application Engine, Query Security Trees, BI Publisher, Fluid UI, Related Content, File Layouts, Application Data Sets, and security definitions.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Overview
This page documents the relationships between core PeopleSoft metadata objects—fields, records, pages, components, menus, portal content references, Component Interfaces, Integration Broker definitions, Application Engine programs, Query Security Trees, BI Publisher reporting, Fluid UI, Related Content, File Layouts, Application Data Sets, and security definitions—and their underlying PeopleTools database tables.
PeopleSoft metadata is structured as an object hierarchy where granular data definitions build upward into visual pages, transaction components, menu structures, and portal navigation links. Security grants wrap around components, menus, Component Interfaces, web services, and portal content references to determine runtime user authorization.
Core Application Metadata Stack
The core application metadata stack consists of six object types:
Fields (PSDBFIELD): Define atomic data attributes including field name, data type, length, decimal precision, and label definitions (PSDBFLDLABL).
Records (PSRECDEFN, PSRECFIELD): Group fields into logical record definitions mapped to physical SQL tables (RECTYPE = 0), SQL views (RECTYPE = 1), derived work buffers (RECTYPE = 2), subrecords (RECTYPE = 3), dynamic views (RECTYPE = 5), query views (RECTYPE = 6), or temporary tables (RECTYPE = 7).
Pages (PSPNLDEFN, PSPNLFIELD): Define user interface screens containing visual controls (edit boxes, drop-down lists, check boxes, scroll areas, grids) bound to specific record fields.
Components (PSPNLGRPDEFN, PSPNLGROUP): Group one or more pages into a complete online business transaction. Every component relies on a primary search record (SEARCHRECNAME) to drive key selection and search dialogs.
Menus (PSMENUDEFN, PSMENUITEM): Organize components into logical menu bars (BARNAME) and menu items (ITEMNAME).
Portal Content References / CREFs (PSPRSMDEFN): Define navigation nodes, URLs, content providers (PORTAL_CNTPRV_NAM), and parent folders in the portal registry tree.
Security in PeopleSoft governs access to components, menu items, Component Interfaces, web services, and portal content references through five security layers:
User Accounts (PSOPRDEFN): Represent individual user accounts containing symbolic IDs, default local nodes, user class settings, and assigned roles.
User Roles (PSROLEUSER, PSROLEDEFN): Assign role definitions to users.
Permission Lists (PSROLECLASS, PSCLASSDEFN): Map permission list definitions to roles.
Menu & Component Authorizations (PSAUTHITEM): Authorize specific actions (Get, Add, Update/Display, Update/Display All, Correction) granted by permission lists for menu items and components.
Portal Permissions (PSPRSMPERM): Grant permission lists (PORTAL_PERMTYPE = 'P') or roles (PORTAL_PERMTYPE = 'R') access to portal folders and content references.
flowchart TD
User["User ID (PSOPRDEFN)"] -->|Assigned Roles| RoleUser["User Role Assignment (PSROLEUSER)"]
RoleUser -->|Maps to| Role["Role Definition (PSROLEDEFN)"]
Role -->|Includes Classes| RoleClass["Role Class Grant (PSROLECLASS)"]
RoleClass -->|Maps to| PermList["Permission List (PSCLASSDEFN)"]
PermList -->|Grants Actions| AuthItem["Authorized Item (PSAUTHITEM)"]
AuthItem -->|Target Menu & Item| MenuItemSec["Menu Item (PSMENUITEM)"]
MenuItemSec -->|Target Component| ComponentSec["Component (PSPNLGRPDEFN)"]
PermList -->|CREF Grant| PortalPerm["Portal Permission (PSPRSMPERM)"]
Role -->|CREF Grant| PortalPerm
PortalPerm -->|Authorizes Access| CREFSec["Portal Content Reference (PSPRSMDEFN)"]
Component Interface (CI) Architecture & Security
Component Interfaces expose online components (PSPNLGRPDEFN) for external API invocation, Excel-to-CI batch loads, and web service integrations:
CI Definitions (PSBCDEFN): Define Component Interface metadata, pointing to a target underlying component (PNLGRPNAME, MARKET) and primary search record.
CI Properties & Keys (PSBCITEM): Map exposed Component Interface properties, collections, methods, and parameters to page controls and record fields on the underlying component.
CI Security Grants (PSAUTHBUSCOMP): Authorize permission lists (CLASSID) to execute specific Component Interface actions (AUTHORIZEDACTIONS bitmask: Get, Create, Save).
Integration Broker (IB) Architecture & Web Services Security
Integration Broker manages synchronous and asynchronous messaging, REST and SOAP web services, routings, handlers, and external message nodes:
Services (PSSERVICE): Logical groupings of related service operations.
Service Operations (PSOPERATION): Individual operations defining operation type (Asynchronous One-Way, Asynchronous Read-Sub, Synchronous, REST), message body definitions, and default versions.
Operation Versions (PSOPRVERDFN): Versioned definitions of service operations mapping request and response messages.
Routings (PSIBRTNGDEFN): Directional communication rules mapping sender nodes to receiver nodes, specifying transformations and transport connectors.
Handlers (PSOPRHDLR): Code execution units (Application Classes or App Engines) that process incoming or outgoing service operation messages.
Message Nodes (PSMSGNODEDEFN): External system or local environment connection targets.
Queues (PSQUEUEDEFN): Asynchronous execution queues governing message sequencing and concurrency.
Web Service Security (PSAUTHWS): Authorizes permission lists (CLASSID) to execute specific Service Operations (IB_OPERATIONNAME) within a Service (IB_SERVICE_NAME).
Query Security Trees & BI Publisher (XMLP) Pipeline
PeopleSoft Query definitions interface with Query Security Trees for record authorization, and feed data into BI Publisher templates for document generation:
Query Access Trees (PSTREEDEFN, PSTREENODE, PSTREELEAF): Hierarchical record structures organizing records into query access groups. Permission lists (PSCLASSDEFN) are granted access to specific tree nodes.
Query Definitions (PSQRYDEFN, PSQRYRECORD): Queries selecting record data filtered by query tree security grants.
Connected Queries (PSCONQRSDEFN, PSCONQRSMAP): Hierarchical structures linking multiple queries into a single nested XML payload.
BI Publisher Data Sources (PSXPDATASRC): Data source definitions wrapping PS Queries, Connected Queries, or XML files.
Report Definitions (PSXPRPTDEFN, PSXPTMPLDEFN): Report definitions linking data sources to RTF, PDF, or Excel templates (PSXPTMPLFILEDEF).
Fluid UI definitions and Related Content services deliver responsive navigation tiles and contextual sidebar panels:
Fluid Components (FLUIDMODE = 1): Components designed for responsive layout across desktop and mobile devices.
Portal Tile Attributes (PSPRSMSYSATTRVL): System attribute key/value pairs attaching Fluid tile properties (ALLOW_NAVBAR_TILES, PORTAL_HIDE_FROM_NAV) to content references (PSPRSMDEFN).
Related Content Services (PSPTCSSRVDEFN): Service definitions specifying target components, iScripts, or external URLs for contextual display.
Related Content Configurations (PSPTCS_SRVCFG, PSPTCS_MAPFLDS): Configuration mappings linking target related content services to specific host component fields and keys.
PeopleCode programs bind to metadata definitions through key schemes stored in PSPCMPROG, PSPCMTXT, and PSPCMNAME. The OBJECTID1 column in PSPCMPROG identifies the parent object type that owns the code:
Record PeopleCode (OBJECTID1 = 1): Attached to record fields. Stores events like FieldChange, RowInit, SaveEdit, and FieldFormula.
Menu PeopleCode (OBJECTID1 = 3): Attached to menu items for ItemSelected events.
Page PeopleCode (OBJECTID1 = 9): Attached to pages for page activate events.
Component PeopleCode (OBJECTID1 = 10): Attached to components at the component level (OBJECTID3 = 12), component record level (OBJECTID3 = 1), or component record-field level (OBJECTID3 = 1 with OBJECTID4 = 2).
Component Interface PeopleCode (OBJECTID1 = 74): Attached to Component Interface properties and methods.
Application Package PeopleCode (OBJECTID1 = 104): Attached to Application Package classes and methods.
The PSPCMNAME table stores every object reference parsed from PeopleCode programs, enabling bidirectional cross-referencing between source code and metadata definitions.
Process Scheduler definitions and PeopleSoft Query definitions interface with records and components:
Process Definitions (PRCSDEFN): Map batch processes (Application Engines, SQR, COBOL, BI Publisher) to parent process types (PRCSTYPE) and target components (PRCSDEFNPNL). Process groups (PRCSDEFNGRP) control user authorization to run processes from specific components.
PeopleSoft Queries (PSQRYDEFN): Query definitions reference record definitions (PSQRYRECORD) and selected fields (PSQRYFIELD). Access to record data within Query Manager is governed by Query Security Trees (PSTREENODE), which are granted to permission lists (PSCLASSDEFN).
flowchart TD
PrcsDefn["Process Definition (PRCSDEFN)"] -->|Runs from Component| PrcsPnl["Process Component (PRCSDEFNPNL)"]
PrcsPnl -->|Target Component| CompPrcs["Component (PSPNLGRPDEFN)"]
PrcsDefn -->|Grouped in| PrcsGrp["Process Group (PRCSDEFNGRP)"]
QueryDefn["Query Definition (PSQRYDEFN)"] -->|Selects Records| QueryRec["Query Record (PSQRYRECORD)"]
QueryRec -->|Points to| RecordQry["Record Definition (PSRECDEFN)"]
RecordQry -->|Tree Access Controlled by| QueryTree["Query Tree Node (PSTREENODE)"]
PermListQry["Permission List (PSCLASSDEFN)"] -->|Grants Tree Access| QueryTree
PeopleTools Table Reference
The table below lists the primary PeopleTools database tables and primary key structures for major metadata and security objects.
When a user accesses an online component, Component Interface, web service, or portal content reference, PeopleSoft evaluates authorization through a multi-tier resolution path:
Top-Down User Authorization Evaluation
The runtime engine identifies the user’s OPRID in PSOPRDEFN.
PSROLEUSER fetches all roles assigned to OPRID.
PSROLECLASS collects all permission lists (CLASSID) mapped to those roles.
PSAUTHITEM verifies if any collected permission list grants authorized actions for the requested MENUNAME, BARNAME, and ITEMNAME.
PSAUTHBUSCOMP checks whether the user’s permission lists authorize Component Interface actions for a requested BCNAME.
PSAUTHWS checks whether the user’s permission lists authorize execution of a requested Service (IB_SERVICE_NAME) and Operation (IB_OPERATIONNAME).
PSPRSMPERM checks whether the user’s permission lists or roles authorize access to the target portal content reference (PORTAL_OBJNAME).
Bottom-Up Security Audit Path
To audit which users hold access to a specific component, CI, or web service:
Components: Identify the menu item (PSMENUITEM) pointing to PNLGRPNAME, query PSAUTHITEM for permission lists (CLASSID), query PSROLECLASS for roles, and query PSROLEUSER for assigned users.
Component Interfaces: Query PSAUTHBUSCOMP for permission lists with non-zero AUTHORIZEDACTIONS on BCNAME, then resolve roles (PSROLECLASS) and users (PSROLEUSER).
Integration Broker Web Services: Query PSAUTHWS for permission lists authorized for IB_SERVICE_NAME and IB_OPERATIONNAME, then resolve roles (PSROLECLASS) and users (PSROLEUSER).
5.2 - Projects
Browse and inspect App Designer project definitions (PSPROJECTDEFN) and their constituent metadata items.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Projects are PeopleSoft’s primary mechanism for grouping metadata objects together for migration between environments (e.g., from Development to Testing to Production). Every project definition is stored in PSPROJECTDEFN, and the items contained within a project are registered in PSPROJECTITEM.
psLens allows you to search and inspect project definitions directly, showing you the exact list of objects included in a project and letting you compare project items across different database environments.
Object Relationships
Projects bundle application metadata for lifecycle management and environment migration:
Groups Metadata Objects: Projects (PSPROJECTDEFN) contain project items (PSPROJECTITEM) referencing records, fields, pages, components, PeopleCode, and other definitions.
How psLens Improves Project Inspection
In Application Designer, inspecting projects requires opening individual project files, expanding object trees, and manually cross-referencing upgrade action flags prior to migration.
psLens displays project properties, paginated item inventories categorized by object type, migration health flags for non-standard actions, and cross-database environment comparison on a single screen.
Search Page
URL: /projects?db={database}
The Project Search page lets you locate projects by name (using a prefix match).
Basic Search: Type a partial name (e.g., HR or PT) to search. Search matches as starts with. You can use the % wildcard for more complex queries: %UPGRADE% finds any project containing “UPGRADE”, or % alone lists all projects.
Advanced Filters:
Operator ID: Filter projects last updated by a specific operator (user).
Customized Only: Filter to show only projects marked as customized.
Date Range: Filter projects based on their last updated date.
Detail Page
URL: /projects/{PROJECTNAME}?db={database}
Project detail for CHG_LENS_DEMO_WONKY: properties and item list
The Project Detail page shows:
Project Properties: Shows metadata about the project itself, such as the description, version, object owner, release, release label, update flags, and the user who last updated it.
Project Items: Displays a paginated list of all objects contained within the project, grouped and sorted by object type (e.g., Records, Fields, Pages, Components, PeopleCode).
Flagging non-standard project items
Migration & Health Flags: psLens automatically flags non-standard project items in red (as shown above). This highlights things that can cause issues with migrations, such as upgrade flags and actions (e.g., Delete actions or items with Take set to No). This gives you a quick check on the state of your project before migrating.
Compare to Database: If you have multiple databases configured in psLens, you can select another database from the card on the page to run a project comparison.
Export as Markdown: Export the entire project definition and its items list to a markdown file, which is ideal for change logs, migration documentation, or code reviews.
5.3 - Project Import
Import and compare PeopleSoft XML project files against the target database to review object states and perform PeopleCode/SQL diffs.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Project Import lets you upload an XML export file of a PeopleSoft project (the .xml files exported from App Designer via Tools -> Copy Project -> To File).
This lets you inspect the contents of a project file (including embedded PeopleCode, SQL, and HTML definitions) and compare it against any of the configured databases before actually migrating or importing the project into the environment.
Object Relationships
Project Import previews external project files against database metadata:
Compares XML Items to Database: Project Import parses project XML files to compare embedded items against live database definitions (PSPROJECTITEM).
How psLens Improves Project Import Analysis
In Application Designer, comparing an exported XML project file against a target environment requires logging into the target database and executing a project copy or compare operation.
psLens allows developers to drag-and-drop XML project files to inspect embedded PeopleCode, SQL, and HTML definitions offline, running content-hash diffs against target databases before migrating.
Uploading a Project XML
URL: /project-import
To import a project:
Go to the Project Import page.
Click the file upload box or drag-and-drop your PeopleSoft project XML file (up to 25MB).
The server will parse the XML and add the project to your local imports history list.
Project XML View
Once imported, you are presented with the Project XML View:
Metadata Summary: Shows the source database where the project was exported, export date, export Operator ID, and file stats.
Flat Items List: A single flat table listing every object in the project, categorized by type (Record, Field, Component, etc.).
Source Code View: Items that contain code (PeopleCode, SQL, or HTML) are marked with an icon. Clicking on these items will expand them inline to show the source code directly in your browser.
Database Comparison
You can compare the imported XML project against any of your active databases:
Select the target database from the dropdown in the comparison card.
Click Compare.
psLens runs a comparison check for each object:
PeopleCode: Performed via content hashing (ignoring line endings and trailing whitespace) to determine if the code is identical or different, since timestamps are often unreliable across migrations.
Other Objects: Performed via the LASTUPDDTTM timestamp on the target database table.
Compare Statuses
Same: The object in the XML file is identical to the one in the target database.
Different: The code contents differ between the XML and the database.
DB Newer: The object in the database has a newer timestamp than the one in the XML.
DB Older: The object in the database has an older timestamp than the one in the XML.
Not in DB: The object does not exist in the target database.
No DB Lookup: The object type is not supported for automatic database comparison.
5.4 - Definitions
Browse PeopleSoft data, interface, and code definitions: records, fields, pages, components, and more.
Definitions
psLens provides read-only exploration and cross-referencing for core PeopleSoft application definitions.
5.4.1 - Fields
Browse PeopleSoft field definitions with cross-references to records, pages, PeopleCode, component interfaces, queries, and projects.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Fields (PSDBFIELD) are the fundamental, individual data elements in PeopleSoft—like an employee ID, first name, date of birth, or monetary amount. Think of a field as an individual column in a spreadsheet or a single entry box on a form. Every database table column and page control across PeopleSoft is built on top of a field definition. psLens reads field definitions from PSDBFIELD (and field labels from PSDBFLDLABL) and stitches them together with the rest of the metadata so you can see, in one place, everywhere a given field is used.
Object Relationships
Fields form the lowest-level data layer in the PeopleSoft object hierarchy:
Included in Records: Fields (PSDBFIELD) are grouped into record definitions (PSRECFIELD) to form physical database tables, SQL views, and derived work buffers.
Bound to Page Controls: Fields are bound to user interface controls (PSPNLFIELD) on pages to view or edit data.
Exposed in Component Interfaces: Fields map to Component Interface properties (PSBCITEM) for programmatic API integrations.
Referenced in Queries & PeopleCode: Fields are selected in PeopleSoft Queries (PSQRYFIELD) and referenced in PeopleCode logic across the application.
How psLens Improves Field Inspection
In Application Designer, assembling a complete picture of a field’s usage requires opening the field definition for properties and labels, right-clicking to run Find Object References for record usage, executing a separate Find In search across PeopleCode, manually running SQL against PSPNLFIELD and PSBCITEM to find page and CI usage, running Query Manager searches across databases, and inspecting containing App Designer projects one at a time for migration history.
psLens surfaces field properties, label definitions, containing records, page bindings, Component Interface properties, PeopleCode call sites, and query references on a single screen with one-click drilldowns.
Search Page
URL: /fields?db={database}
Field search results for OPR%
Type a partial field name to find matching definitions. Search auto-matches as starts with — EMPLID finds EMPLID, EMPLID_TBL, EMPLID_PNL, etc. Include % yourself for more control: %NAME (ends with), %DESCR% (contains), or just % to list every row. Each result card shows the field type and length, the long-name description, and the last-updated timestamp so you can spot recently modified objects at a glance. The Advanced Filters panel lets you narrow by field type, last-updated date, or owner. Recently viewed fields are surfaced just above the results.
Detail Page
URL: /fields/{FIELDNAME}?db={database}
Field detail page for OPRID — default view, no panels expanded
The main pane shows the Field Properties card (type, length, format, description, object owner, last-updated metadata) and a Field Labels card with every long/short name pair defined in PSDBFLDLABL, including which one is the default label. The Export button in the top right downloads the full definition as Markdown. The Related Data sidebar holds six toggles that fetch additional context on demand.
Related Data Panels
Toggle any panel on to load it inline beneath the main content. Each panel returns the count of objects found and a sortable list with deep-links into the corresponding psLens detail pages, so you can chase a field reference into the record, page, or PeopleCode program that uses it without losing your place.
Records
Every record that includes this field, with type (Table/View) and Edit Table indicator
Lists every record where the field appears, with record type, the position number within the record, key-field indicator, and whether the field is configured with an Edit Table prompt. Sourced from PSRECFIELD / PSRECFIELDDB.
Included in Projects
App Designer projects that include this field
Shows every App Designer project (PSPROJECTITEM) that contains this field as a project item. Useful for tracing which customization or release introduced or modified the field.
PeopleCode References
PeopleCode programs that reference this field
Lists PeopleCode programs that mention the field: record PeopleCode, component PeopleCode, application package methods, and more. Each result links to the parent object’s detail page so you can drill into the program.
Pages
Pages with field controls bound to this field
Lists pages (PSPNLFIELD) where a control on the page is bound to this field, with the record context. Useful for impact analysis when changing a field’s type or length.
Component Interfaces
Component Interfaces that expose this field as a property
Lists Component Interfaces that expose this field as a CI property. The integration surface area for the field. Sourced from PSBCITEM.
Queries
PeopleSoft Queries that reference this field
Lists PeopleSoft Queries (PSQRYFIELD) that reference this field in a SELECT, WHERE, or ORDER BY. Useful for security and audit work: “who has reports built on this column?”
5.4.2 - Records
Browse PeopleSoft record (table) definitions with fields, indexes, related pages, components, PeopleCode, and live data preview.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Records are PeopleSoft’s table/view definitions — every database table, SQL view, derived/work record, and dynamic view is registered in PSRECDEFN. psLens reads the record definition plus its field list from PSRECFIELD and stitches it together with everywhere the record is referenced in pages, components, PeopleCode, queries, projects, and trees. The Records page has 12 related-data panels covering pages, components, PeopleCode, queries, trees, prompt-table back-references, AE statements, COBOL SQL statements, project membership, and a live row sample.
Object Relationships
Records connect underlying field definitions to user interfaces and security structures:
Contains Fields: Records group individual field definitions (PSDBFIELD) into ordered record fields (PSRECFIELD).
Bound to Pages: Fields on a record are bound to controls (PSPNLFIELD) on page definitions (PSPNLDEFN).
Primary Search for Components: Records act as primary search records (SEARCHRECNAME) driving component key selection dialogs.
Defined by SQL Objects: View-type records (RECTYPE = 1) derive their SELECT SQL definitions from SQL Objects (PSSQLDEFN).
How psLens Improves Record Inspection
A complete impact assessment for a record change in Application Designer requires opening the record definition for properties, fields, and events, running Find Object References to find pages using it, walking found pages to identify parent components, executing Find In searches across PeopleCode, manually querying PSAESTMTDEFN, PSQRYRECORD, and PSTREENODE for AE, query, and tree usage, checking prompt-table back-references, and opening SQL clients to sample rows.
psLens consolidates record schema fields, page bindings, component trees, PeopleCode events, query usage, prompt-table relationships, AE/COBOL SQL statements, project membership, and a live row sample into one page.
Search Page
URL: /records?db={database}
Record search results for PSREC% — note the record type pill (Table/View) and field count on each card
Search auto-matches as starts with — typing JOB finds JOB, JOB_DATA, JOBCODE, etc. For more control, include % yourself: %DATA (ends with), %PERS% (contains), or just % to list every row. Each card shows record type, field count, the descriptive long name, and last-updated metadata. The Advanced Filters panel lets you filter by record type (Table, View, Derived/Work, Subrecord, Dynamic View, Query View, Temp Table), object owner, and last-updated date.
Detail Page
URL: /records/{RECNAME}?db={database}
Record detail page for PSRECDEFN — default view with properties, field list, and the Related Data sidebar
The main pane shows Record Properties (type, owner, audit options, system table flag, description, audit timestamps) and a full Record Fields table with each field’s type, length, key indicators, default value, and Edit Table prompt — every detail you’d otherwise open App Designer to confirm. The Export button downloads the full record definition as Markdown. The Related Data sidebar holds 12 toggles — the broadest set of any object type — covering every place this record is referenced.
Related Data Panels
Pages Using This Record
Pages that bind a control to this record
Lists pages with controls bound to this record (PSPNLFIELD join on RECNAME). Useful for impact analysis when changing the record schema.
Components Using This Record
Components whose pages reference this record
Lists every component containing a page bound to this record — gives you the user-facing transactions affected by the record.
PeopleCode Events
Record PeopleCode events defined on this record
Lists record-level PeopleCode events (FieldChange, RowInit, SaveEdit, etc.) attached to fields of this record. Sourced from PSPCMPROG.
Included in Projects
App Designer projects that include this record
Lists App Designer projects (PSPROJECTITEM) that include this record — useful for migration history and change tracking.
Used in App Engines
Application Engine programs that reference this record
Lists Application Engine programs whose SQL or PeopleCode steps reference this record. Sourced from PSAESTMTDEFN text scans.
Component Interfaces Using This Record
CIs whose underlying component is built on a page that uses this record
Lists Component Interfaces whose underlying component contains a page bound to this record — the integration surface area.
Record Data
Live sample data from the record itself
Pulls a live sample of rows from the record using the psoftQL API — first ~10 rows with every column. Lets you see what the data actually looks like without opening App Designer’s Run-In-Query or a separate SQL client.
PeopleCode References
Any PeopleCode program that mentions this record by name
Broader than “Events” — finds any PeopleCode anywhere in the database that mentions this record by name (component, page, app package, app engine, message, signon, FieldFormula, etc.).
Queries Using This Record
PeopleSoft Queries that include this record
Lists PeopleSoft Queries (PSQRYRECORD) that include this record in a FROM clause. Critical for audit work — “who is reporting from this table?”
Query Trees Using This Record
Query Tree nodes that expose this record to query authors
Lists Query Tree nodes (PSTREENODE) where this record appears — determines which query authors can build queries against it.
Used as Prompt Table
Other records whose fields use this record as an Edit/Prompt table
Lists fields on other records that point to this record as their Edit Table / Prompt Table — shows the lookup relationships that hang off this record.
COBOL SQL Statements
Lists stored COBOL SQL statements (SQLSTMT_TBL) that reference this record in their statement text, program name, or statement name. Displays the COBOL program (PGM_NAME), statement type (STMT_TYPE), statement name (STMT_NAME), and formatted SQL text.
5.4.3 - SQL Objects
Browse PeopleSoft SQL Object definitions — views, synonyms, and indexes — with source SQL and project membership.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
SQL Objects are the PeopleSoft application’s standalone SQL artifacts — view definitions and other named SQL fragments stored in PSSQLDEFN / PSSQLTEXTDEFN. Unlike a record’s automatically-generated DDL, these are SQL bodies the developer hand-wrote and PeopleSoft keeps versioned with the rest of the metadata. psLens pulls the source SQL plus the related record (when the SQL object is a view tied to a record definition) so you don’t switch into App Designer to read the SQL.
Object Relationships
SQL Objects define custom SQL statements for database views and code modules:
Defines Record Views: SQL Objects (PSSQLDEFN) contain the underlying SELECT statements that define SQL view records (RECTYPE = 1).
Called by PeopleCode & App Engines: Standalone SQL objects are executed in code via FetchSQL() or Application Engine SQL actions.
How psLens Improves SQL Object Inspection
Reading SQL Objects in Application Designer requires searching SQL definitions, opening the object editor, right-clicking to find backing records, and checking projects individually for migration history.
psLens presents syntax-highlighted SQL source code inline, with direct links to backing record definitions and project membership.
Search Page
URL: /sqlobjects?db={database}
SQL Object search results for PT%
Search auto-matches as starts with. Typing PT finds every SQL object whose ID begins with PT. Include % yourself for ends-with (%VW) or contains (%AUDIT%) patterns, or use % alone to list every row. Each result shows the object name, type, and last-updated info, useful when you’re tracing where a view body is defined or hunting for a delivered SQL fragment.
Detail Page
URL: /sqlobjects/{NAME}?db={database}
SQL Object detail page for PTACESRCHDVW
The main pane shows the object’s properties and the full Source SQL body, syntax-highlighted and copyable, so you can see what the view SELECTs without an App Designer round-trip. The sidebar has two related-data toggles.
All panels expanded: Source Record and Project membership
Related Data Panels
Source Record
Direct link into the matching record detail page
When the SQL object is the body of a view-type record, this panel links into the parent record’s detail page so you can see the field list and the rest of the record metadata in one click.
Included in Projects
App Designer projects that include this SQL object
Lists projects that contain this SQL object as a project item. Useful for tracing migration history of view DDL changes.
5.4.4 - File Layouts
Browse PeopleSoft File Layout definitions — segments, fields, file format attributes, projects, and PeopleCode references.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
File Layout definitions (PSFLDDEFN) map structured flat files, CSVs, fixed-position files, and XML documents to PeopleSoft rowsets and record structures. PeopleTools Object Type 31 definitions store file format specifications in PSFLDDEFN, segment hierarchies in PSFLDSEGDEFN, and field attributes in PSFLDFIELDDEFN. Batch processes and PeopleCode programs query these definitions at runtime to parse inbound files or render outbound data extracts.
psLens pulls the file layout properties, segment hierarchy tree, mapped records, field positional attributes, owning App Designer projects, and referencing PeopleCode programs into a single browser view.
Object Relationships
File Layouts translate external files into PeopleSoft record structures:
Maps File Segments to Records: File Layouts (PSFLDDEFN) contain segment hierarchies (PSFLDSEGDEFN) that map file lines to underlying target records (RECNAME_FILE).
Maps File Fields to Record Fields: File fields (PSFLDFIELDDEFN) map positional or delimited file data to specific record fields.
Invoked in PeopleCode & App Engines: Batch programs instantiate File Layouts (GetFileLayout) to parse or generate flat files.
How psLens Improves File Layout Inspection
In Application Designer, inspecting File Layouts requires expanding segment nodes in the tree control, clicking into individual field properties, and running Find In PeopleCode searches for referencing scripts.
psLens presents layout format properties, segment hierarchies, field positional attributes, project membership, and referencing PeopleCode programs in a single view.
Search Page
URL: /filelayouts?db={database}
Search: Search by File Layout name or description (prefix match). Wildcard % search is supported (for example, %BANK% to find banking layout definitions or % to list all rows).
Filters: Filter search results by last updated operator (LastUpdOprid), last updated date range (DateFrom / DateTo), or customized definitions (CustomizedOnly).
Metadata Cards: Each result card displays the file layout name, description, file format type (CSV, Fixed, or XML), segment count, and last updated operator and timestamp.
Detail Page
URL: /filelayouts/{FLNAME}?db={database}
File Layout detail page for ISIR25OP showing definition hierarchy tree and header properties
The Detail Page consolidates the definition attributes, segment hierarchy, field specifications, and cross-object references:
File Layout Properties: Displays description, file format type (CSV, Fixed Position, XML), record delimiter, field qualifier, space stripping behavior, Excel formatting flags, segment count, and modification audit metadata (LASTUPDDTTM, LASTUPDOPRID).
Segment & Field Hierarchy: Renders a tree of segments (PSFLDSEGDEFN) and fields (PSFLDFIELDDEFN). For each segment, psLens displays its parent segment, segment ID prefix, mapped record (RECNAME_FILE), and field count. For each field, psLens lists the field name, start position, length, decimal precision, date format mask, and date separator.
Export as Markdown: Generates a structured Markdown export (/filelayouts/{FLNAME}/export) containing an ASCII segment hierarchy tree, complete field lists, project membership, and referencing PeopleCode programs.
Related Data Panels
Included in Projects
Queries PSPROJECTITEM where OBJECTTYPE = 31 to display Application Designer projects containing this File Layout definition.
PeopleCode References
Queries PSPCMNAME to list all PeopleCode programs (Application Engine steps, Component PeopleCode, Record PeopleCode, or Application Package methods) that reference the File Layout name in code statements.
5.4.5 - Pages
Browse PeopleSoft page definitions with field controls, source records, subpages, components, and PeopleCode.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Pages are the visual screens users interact with in PeopleSoft: the panel definitions from PSPNLDEFN and the per-control bindings from PSPNLFIELD. psLens shows the full control list (every field, label, group box, and subpage on the page), the underlying records each control reads from, and the rest of the metadata graph hanging off the page: which components include it, which PeopleCode is attached, which projects contain it.
Object Relationships
Pages bridge individual record fields to complete application transactions:
Binds Record Fields: Pages (PSPNLDEFN) contain visual controls (PSPNLFIELD) bound to fields (FIELDNAME) on underlying records (RECNAME).
Grouped in Components: One or more pages are assembled into a component definition (PSPNLGROUP) to create a complete transaction.
Includes Subpages: Pages embed reusable subpages and secondary pages to modularize user interface design.
How psLens Improves Page Inspection
Investigating page definitions in Application Designer requires opening the page layout, double-clicking individual controls to verify record and field bindings, querying PSPNLGROUP to find parent components, checking page properties for Activate PeopleCode, and walking owning projects for migration history.
psLens presents the full control inventory, distinct underlying records, embedded subpages, containing components, Activate PeopleCode, and project membership in a single view with everything one click away.
Search Page
URL: /pages?db={database}
Page search results for USER_%
Wildcard % search supported. Each result card shows the page type (Standard Page, Subpage, Secondary Page, or Search Record) so you can spot reusable subpages versus standalone screens at a glance. The Advanced Filters panel lets you exclude subpages or limit to standard pages only.
Detail Page
URL: /pages/{PAGENAME}?db={database}
Page detail for USERPROFILEPAGE — default view
The main pane shows Page Properties (type, size, style, audit metadata) and the full Page Fields/Controls table with each control’s record/field binding, label, occurs level, and field type. The sidebar has 6 related-data toggles.
All panels expanded on a Secondary Page
Related Data Panels
Page Fields/Controls
Every control on the page with its field, record, and label
The control inventory: every field control on the page with its PSPNLFIELD row attributes. Each record/field reference deep-links into the matching psLens detail page.
Records Used on Page
Distinct records referenced by any control on the page
The de-duplicated list of records this page reads from. Clicking a record opens its detail page so you can confirm the schema, sample data, or check what else uses it.
Subpages Included
Subpages embedded inside this page
Lists every subpage embedded inside this page. Useful when a control’s data seems to come from somewhere “magic” (it’s almost always a subpage doing the work).
Components Using Page
Components whose item list includes this page
Lists the components that include this page. Answers “which transactions show this screen to a user?”
PeopleCode
Page-level PeopleCode (Activate event) attached to this page
Page Activate PeopleCode. The only event type that lives directly on a page object.
Included in Projects
App Designer projects that include this page
App Designer projects containing this page as a project item.
5.4.6 - Components
Browse PeopleSoft component definitions with pages, menus, portal paths, CIs, records, and PeopleCode in one view.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Components (called panel groups in older PeopleTools versions) are the user-facing transactions of a PeopleSoft application: a search page plus an ordered set of detail pages that share a single save action. psLens reads PSPNLGROUP / PSPNLGRPDEFN and links the component up to its menus, portal navigation paths, exposing component interfaces, the underlying record hierarchy, and the full PeopleCode event tree.
Object Relationships
Components unite visual pages, database records, security grants, and navigation:
Groups Pages: Components (PSPNLGRPDEFN) assemble ordered lists of pages (PSPNLGROUP) into a unified transaction with shared state.
Driven by Search Records: Components rely on a primary search record (SEARCHRECNAME) to execute key lookups and search dialogs.
Linked to Menus: Components are assigned to menu items (PSMENUITEM) inside classic menus (PSMENUDEFN).
Targeted by CREFs & CIs: Portal Content References (PSPRSMDEFN) expose components to users, and Component Interfaces (PSBCDEFN) expose them to API code.
How psLens Improves Component Inspection
Tracing component metadata in Application Designer and PIA requires opening the component item list, walking page tabs to confirm record bindings, running Find In Menus for classic navigation links, navigating the Portal Registry browser for CREF breadcrumbs, searching for exposing Component Interfaces, and opening event PeopleCode across multiple tabs.
psLens combines component properties, page lists, classic menu links, portal registry paths, exposing Component Interfaces, scroll record hierarchies, component event PeopleCode, and project membership onto a single screen.
Search Page
URL: /components?db={database}
Component search results for USER%
Wildcard % search supported. Each result card shows the component market and use type (Classic, Fluid, Both). The Advanced Filters panel filters by market or component type.
Detail Page
URL: /components/{COMPONENT}?db={database}
Component detail page for USERMAINT
The main pane shows Component Properties (market, search record, add search record, item description, add/update modes, search PeopleCode flags) and the Component Item List with every page in the component, its labeling, and the hide/display-only flags. The sidebar has 7 related-data toggles.
Related Data Panels
Pages in Component
The ordered list of pages that make up this component
The page list with each page deep-linked into its own detail page.
Menus Using Component
Classic menus that link to this component
Every classic menu (PSMENUITEM) that contains a navigation entry for this component. Important for security work since menu/component pairs drive Permission List authorizations.
Portal Navigation Paths
Every breadcrumb path that leads a user to this component in the portal registry
The full set of portal registry paths (PSPRSMDEFN ancestor walk) that lead a user to this component. Useful for “where is this transaction in the menu?” questions.
Component Interfaces
Component Interfaces that expose this component as an integration surface
The CIs (PSBCDEFN) that wrap this component as an integration surface. If you have CIs here, programmatic access exists.
Record Level Hierarchy
The component’s scroll/record hierarchy across its pages
The scroll/record hierarchy across the pages. Shows the parent-child relationships of records as the component sees them at runtime.
PeopleCode
Component-level PeopleCode events
Component-level PeopleCode events (SearchInit, SearchSave, PreBuild, PostBuild, SavePreChange, SavePostChange, Workflow, etc.) and Component Record/Component Record Field PeopleCode.
Included in Projects
App Designer projects that include this component
App Designer projects containing this component as a project item.
5.4.7 - Component Interfaces
Browse PeopleSoft Component Interface definitions with items, methods, PeopleCode, and consistency checks.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Component Interfaces (CIs) are PeopleSoft’s programmatic façade over a component. They expose component properties as get/set properties and component events as callable methods, so integration code can drive the same business logic the UI uses. psLens reads PSBCDEFN for the CI header, PSBCITEM for the property/key list, and PSBCMETHODS for the methods. It also runs two consistency checks against the underlying component to catch the most common breakage: properties that no longer map to a valid record field, and required fields the CI doesn’t expose.
Object Relationships
Component Interfaces expose interactive transaction components for programmatic API access:
Wraps Components: Component Interfaces (PSBCDEFN) target an underlying component (PNLGRPNAME, MARKET) to expose its validation logic.
Maps Properties to Record Fields: CI items (PSBCITEM) bind exposed API properties to specific record fields (PSRECFIELD) on the component.
Secured by Permission Lists: Permission lists (PSAUTHBUSCOMP) grant action-level permissions (Get, Create, Save) on Component Interfaces.
How psLens Improves Component Interface Inspection
Evaluating Component Interfaces in Application Designer requires opening the CI item tree, cross-referencing record fields on the underlying component, manually scanning for missing required fields, and running Find In PeopleCode for calling programs.
psLens automates consistency checks—flagging invalid property bindings and missing required component fields—while displaying methods, properties, referencing PeopleCode, and project membership in one place.
Search Page
URL: /componentinterfaces?db={database}
Component Interface search results for USER%
Wildcard % search supported. Each result card shows the underlying component and CI description.
Detail Page
URL: /componentinterfaces/{CINAME}?db={database}
Component Interface detail page for USER_PROFILE
The main pane shows Component Interface Properties (underlying component, market, security access, owner) plus the items list. The sidebar has 6 related-data toggles, including two consistency-check panels unique to CIs.
Related Data Panels
Items
Every CI property with key flag, record/field binding, and standard/custom indicator
Every CI property (PSBCITEM): its record/field binding, key indicator, and whether it’s a standard or custom-named property.
CI Methods
Standard and user-defined methods on the CI
Standard methods (Get, Find, Create, Save, Cancel) plus any user-defined methods. Each method links into the matching PeopleCode.
Invalid Properties Check
Items that no longer match a valid record field on the underlying component
A consistency check. Flags CI items that no longer match a valid record field on the underlying component — the most common failure mode after a record schema change.
Missing Fields
Required fields on the underlying component that the CI does not expose
A consistency check. Flags fields on the underlying component that are required (key fields, search keys, required-input fields) but are not exposed as CI properties. Helps spot where a CI cannot drive a transaction to completion.
PeopleCode References
PeopleCode programs anywhere in the database that instantiate this CI
PeopleCode programs anywhere in the database that mention this CI by name. Useful for finding the App Engine, Service Operation handler, or other CI program that drives this interface.
Included in Projects
App Designer projects that include this CI
App Designer projects that include this CI.
5.4.8 - Menus
Browse PeopleSoft classic menu definitions with bars, items, and the components they navigate to.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Menus are PeopleSoft’s classic navigation containers. Each menu (PSMENUDEFN) holds a set of bars, each bar a set of items (PSMENUITEM), and each item points to a component the user can launch. Even in a Fluid-dominant world, classic menus matter for security: Permission List authorizations are granted on menu/component pairs, so understanding which menu owns a component is fundamental to access analysis.
Object Relationships
Menus organize business transactions into structured navigation and security access paths:
Points to Components: Menu items (PSMENUITEM) inside a menu (PSMENUDEFN) specify the target component (PNLGRPNAME) and market (MARKET).
Secured by Permission Lists: Permission lists (PSAUTHITEM) authorize user access to specific menu item and component combinations.
Referenced by Portal CREFs: Portal content references (PSPRSMDEFN) use menu and component URI segments to populate navigation trees.
How psLens Improves Menu Inspection
In Application Designer, inspecting classic menus requires opening the menu tree, double-clicking individual items to confirm target component and market properties, and right-clicking items to navigate to component definitions.
psLens displays the complete bar and item hierarchy on a single screen with direct links to target components, making it straightforward to audit security pairs and navigation structures.
Search Page
URL: /menus?db={database}
Menu search results for PROCESS%
Wildcard % search supported. Each card shows the menu type (Standard or Pop-up) and the descriptive long name.
Detail Page
URL: /menus/{MENUNAME}?db={database}
Menu detail page for PROCESSMONITOR
The main pane shows Menu Properties (type, owner, audit metadata). The sidebar has 2 related-data toggles.
All panels expanded — short page since menus are simple structures
Related Data Panels
Menu Items
Every bar and item in the menu with the target component
Every bar and item in the menu, with the component (and market) each item launches. Each component is deep-linked into its own psLens detail page, letting you walk straight from a menu entry into the transaction it triggers.
Included in Projects
App Designer projects that include this menu
App Designer projects that include this menu.
5.4.9 - Content References
Browse PeopleSoft Portal Registry Content References (CREFs) with navigation paths, attributes, and permission lists.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Content References (CREFs) are entries in the PeopleSoft Portal Registry — the data structure that drives the menu tree, breadcrumbs, and navigation collections users see in PIA. Each CREF is identified by a portal/object name pair stored in PSPRSMDEFN and can be either a folder (a navigation container) or a content reference (a launchable target, usually a component, but also iScripts, external URLs, and homepage pagelets). psLens shows the CREF’s URI target, the full ancestor walk back to the portal root, every system and custom attribute, and the permission lists that have been granted access.
Object Relationships
Portal Content References link user navigation elements to target application objects:
Targets Components & External URLs: CREFs (PSPRSMDEFN) map portal links to components (PSPNLGRPDEFN), iScripts, or external web addresses.
Organized in Portal Folders: CREFs are arranged hierarchically inside parent folder nodes within the portal registry tree.
Secured by Permission Lists & Roles: Permission lists and roles (PSPRSMPERM) grant user authorization to view CREFs and portal folders.
How psLens Improves Content Reference Inspection
In PIA, analyzing a Portal Content Reference requires navigating down multi-level folder trees in Structure & Content, switching between administration and permission tabs, and repeatedly editing parent folders to trace breadcrumbs.
psLens displays the complete portal entry—destination URI, full ancestor breadcrumb path, custom/system attributes, and permission list grants—on a single screen.
Search Page
URL: /crefs?db={database}
CREF search results for %USER%
Search by CREF name or label, with optional filters for portal (EMPLOYEE, CUSTOMER, MOBILE, etc.) and type (CREF vs Folder). Each result card shows the portal, the parent folder path, and the target object name.
Detail Page
URL: /crefs/{PORTAL}/{OBJECTNAME}?db={database}
CREF detail page for EOPP_USER_PREFS_GBL
The main pane shows Properties (portal, parent folder, type, security author, label, description) and the URI / Target card with the destination URL. For component CREFs this is the menu/component path; for iScripts, the iScript URL; for external CREFs, the literal URL. The sidebar has 4 related-data toggles.
All panels expanded — under 2100px tall
Related Data Panels
Navigation Path
The breadcrumb walk from the portal root down to this CREF
The full ancestor chain from the portal root down to this CREF. Every folder in the navigation path is clickable so you can hop up the tree to a parent folder.
Custom Attributes
Per-CREF custom attribute name/value pairs from PSPRSMATTRVAL
Per-CREF custom attribute name/value pairs from PSPRSMATTRVAL. Used by Fluid navigation collections, search categories, badges, and other portal features.
System Attributes
System attributes from PSPRSMSYSATTRVL with friendly labels
System attributes from PSPRSMSYSATTRVL with friendly labels (e.g., PORTAL_LABEL, PORTAL_OBJTYPE_DESC, PTPP_* personalization keys). These configure how the CREF behaves at runtime.
Permissions
Permission lists with grant access to this CREF
Permission lists (PSPRSMPERM) that have been granted access to this CREF — the security side of “who can see this in the menu?”.
5.4.10 - Message Catalogs
Browse PeopleSoft Message Catalog entries — message set/number pairs with text, severity, and usage analysis.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
The Message Catalog is PeopleSoft’s centralized store of user-facing text. Every MsgGet() call, error dialog, warning, and translated label resolves to a message set + message number pair stored in PSMSGCATDEFN. psLens lets you browse messages by set number, jump directly to a specific set/number, or search by message text. Each message gets a dedicated detail page with its severity, text, explanation, and a usage analysis that finds where it is referenced in PeopleCode and SQL.
Object Relationships
Message Catalogs standardize application message strings across components and scripts:
Referenced in PeopleCode & SQL: Message Catalog entries (PSMSGCATDEFN) are called by MsgGet() and MsgGetText() in PeopleCode to display formatted messages.
How psLens Improves Message Catalog Inspection
In PIA, searching Message Catalog entries requires navigating Utilities → Administration → Message Catalog, while tracking down where a message is invoked requires running separate Find In PeopleCode searches.
psLens allows instant jumping to Set/Number pairs, surfaces recently modified messages, and automatically performs global usage analysis across all PeopleCode and SQL statements.
Search Page
URL: /messagecatalogs?db={database}
Browsing all messages in set 18
The search page has three entry points: enter a Set Number to see every message in the set, enter free text to Search Message Text, or punch in a specific Set/Number pair to jump straight to that message. The page also surfaces the highest set numbers in use (handy for picking the next free set when creating customizations) and the most recently modified messages.
The detail page has no sidebar toggles; everything loads inline. The main pane shows Message Properties (set, number, severity, last-updated), the full Message Text (with %1, %2 substitution markers preserved), and the Description / Explanation body text developers see when investigating a message.
Full message page including usage analysis
Usage Analysis
Where this message is referenced in PeopleCode and SQL
The Usage Analysis card automatically scans every PeopleCode program and SQL object in the database for textual references to this set/number pair: MsgGet(18, 1, ...), MsgGetText(18, 1, ...), SQLExec("...18, 1..."), and so on. Each hit links to the parent object’s detail page. Lets you find every MsgGet / MsgGetText / SQLExec call site for the set/number pair before editing the text.
5.4.11 - Application Packages
Browse PeopleSoft Application Package class hierarchies with methods, properties, service operation usage, and PeopleCode references.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Application Packages are PeopleSoft’s object-oriented PeopleCode container — packages hold sub-packages and classes, classes hold methods and properties. They are the standard way to write reusable PeopleCode in PeopleSoft applications. psLens walks the package tree (PSPACKAGEDEFN, PSPACKAGEITEM, PSPCMPROG) and shows the full class hierarchy plus a reverse index of where the package is used: by service operation handlers, by other PeopleCode, and in which projects.
Object Relationships
Application Packages organize reusable application logic across PeopleSoft objects:
Executes via Handlers & PeopleCode: Classes define methods and properties called by Integration Broker operation handlers (PSOPRHDLR), App Engine steps, and event PeopleCode.
How psLens Improves Application Package Inspection
In Application Designer, inspecting application packages requires manually expanding sub-packages and class nodes, opening individual classes to view methods and properties, running Find In PeopleCode for import statements, and opening Integration Broker service operations one by one to find handler classes.
psLens exposes the fully expanded recursive package tree, caller call sites, IB service operation handlers, and project membership on a single screen.
Search Page
URL: /apppackages?db={database}
App Package search results for PT_PAGE%
Wildcard % search supported. Each result card shows the package name and the top-level class names inside it.
Detail Page
URL: /apppackages/{PACKAGENAME}?db={database}
App Package detail page for PT_PAGE_UTILS
The main pane shows Package Properties (owner, last-updated, source path) and the full Package Structure, a recursive tree of sub-packages and classes with methods, properties, and visibility markers. The sidebar has 3 related-data toggles.
Related Data Panels
Package Structure
The recursive package/class/method tree
The recursive package tree showing every sub-package, class, method, and property. The equivalent of expanding every node in App Designer’s package browser at once. Methods link into their PeopleCode source.
Projects Containing This Package
App Designer projects that include this package
App Designer projects that include this package as a project item.
Service Operations Using This Package
Integration Broker service operation handlers using this package
Integration Broker service operations whose handler is implemented in this package. Lists the IB endpoints that route through this code.
PeopleCode References
PeopleCode programs anywhere in the database that import or instantiate this package
PeopleCode programs anywhere in the database that import or instantiate classes from this package — the impact view before refactoring.
5.4.12 - URL Definitions
Browse PeopleSoft URL definitions — named URL strings used in PeopleCode, file attachments, and integrations.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
URL definitions are PeopleSoft’s centralized store of named URL strings. Instead of hard-coding https://example.com/... inside PeopleCode, developers define a URL object (PSURLDEFN) and reference it by name with GetURL("MY_URL"). This keeps environment-specific endpoints (file servers, integration partners, image hosts) out of the code. psLens lets you browse the catalog so you can see every URL the application uses in one place.
Object Relationships
URL Definitions centralize external endpoint strings for application code:
Referenced in PeopleCode: URL definitions (PSURLDEFN) are resolved dynamically in PeopleCode via GetURL() calls for attachments, redirects, and integrations.
How psLens Improves URL Definition Inspection
In Application Designer, searching URL definitions requires opening File → Open → URL Definition and clicking into individual items to inspect values.
psLens makes the URL catalog searchable with resolved URL endpoint values and owning project membership displayed inline.
Search Page
URL: /urls?db={database}
URL search results for PT_%
Wildcard % search supported. Each card shows the URL name plus the resolved URL value so you can scan the catalog at a glance.
Detail Page
URL: /urls/{URLNAME}?db={database}
URL detail page for PTFPCONFIG
The main pane shows URL Properties (the URL itself, description, comments, audit metadata). The sidebar has one related-data toggle.
Full URL detail page with Projects panel expanded
Related Data Panels
Included in Projects
App Designer projects that include this URL definition
App Designer projects that include this URL. Useful for understanding which feature or customization introduced the URL.
5.4.13 - HTML Definitions
Browse PeopleSoft HTML definitions — HTML, JavaScript, and template fragments used in pages, emails, and reports.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
HTML definitions are PeopleSoft’s catalog of HTML fragments, JavaScript snippets, and template bodies stored in PSCONTDEFN. Anything a page or report needs to embed — a JavaScript helper, an email body template, a custom Fluid grid layout — is normally stored as a named HTML object and pulled into PeopleCode with GetHTMLText(). psLens shows the full content of the definition so you can read what the application is actually injecting at runtime.
Object Relationships
HTML Definitions provide reusable markup and script templates:
Embedded in Pages: HTML definitions (PSCONTDEFN) store HTML/JS fragments bound to HTML area controls on page definitions.
Loaded via PeopleCode: Programs invoke GetHTMLText() to retrieve and interpolate dynamic values into HTML templates.
How psLens Improves HTML Definition Inspection
In Application Designer, inspecting HTML definitions requires opening individual objects through File → Open → HTML and loading each item into separate editor windows.
psLens makes the entire HTML definition catalog instantly searchable with syntax-highlighted content and project membership presented inline.
Search Page
URL: /htmldefs?db={database}
HTML Definition search results for PT_%
Wildcard % search supported. Each card shows the HTML object’s name and last-updated metadata.
Detail Page
URL: /htmldefs/{NAME}?db={database}
HTML Definition detail page for PTADSDYNGRID_SCRIPT
The main pane shows HTML Definition Properties (description, audit metadata) and the full HTML Content body, syntax-highlighted. The sidebar has one related-data toggle.
Full detail page with the Projects panel expanded
Related Data Panels
Included in Projects
App Designer projects that include this HTML definition
App Designer projects that include this HTML object.
5.4.14 - Style Sheets
Browse PeopleSoft style sheet (CSS) definitions with full inline source and project membership.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Style sheet definitions are PeopleSoft’s stored CSS objects (PSSTYLEDEFN) — the cascading style sheets that drive Classic and Fluid UI rendering. Tools, themes, branding overrides, and per-page substyle sheets all live here. psLens shows the full CSS body so you can read what rules a specific style sheet contributes without extracting it through App Designer or scraping rendered HTML.
Object Relationships
Style Sheets format user interface rendering across pages and themes:
Attached to Pages & Themes: Style Sheets (PSSTYLEDEFN) define CSS rules attached to page definitions, components, and portal branding themes.
How psLens Improves Style Sheet Inspection
In Application Designer, reviewing style sheets requires opening individual objects through File → Open → Style Sheet and examining CSS rules in separate tab windows.
psLens renders searchable, syntax-highlighted CSS source code directly in the browser alongside owning project membership.
Search Page
URL: /styledefs?db={database}
Style Sheet search results for PT_%
Wildcard % search supported. Each card shows the style sheet name and last-updated metadata.
Detail Page
URL: /styledefs/{NAME}?db={database}
Style Sheet detail page for PTAI_ACTIONS_CSS
The main pane shows Style Sheet Definition Properties (description, audit metadata) and the full CSS Content body, syntax-highlighted. The sidebar has one related-data toggle.
Related Data Panels
Included in Projects
App Designer projects that include this style sheet
App Designer projects that include this style sheet.
5.4.15 - Change Control & Object Locks
Inspect PeopleTools Change Control configuration and active definition checkout locks across all PeopleSoft objects.
PeopleTools Change Control & Object Locks
In PeopleSoft development environments, PeopleTools Change Control prevents simultaneous modifications to application metadata objects by allowing developers to check out and lock definitions (e.g. Records, Pages, Components, PeopleCode, App Engines, Component Interfaces).
psLens automatically inspects system-wide Change Control configuration (PSCHGCTLDEF) and active checkout locks (PSCHGCTLLOCK) whenever you view definition metadata or related project associations.
How psLens Displays Object Lock Status
When inspecting any PeopleSoft definition in psLens (such as a Record, Page, Component, or Field), the Included in Projects panel surfaces Change Control state in real-time:
Locked Objects: If a developer has checked out the object in Application Designer, psLens displays a prominent lock banner showing:
Operator ID (OPRID): The developer holding the active lock.
Lock Timestamp: When the object was checked out.
Associated Project: Direct link to the project (PSPROJECTDEFN) under which the definition is locked.
Developer Comments: Any check-out justification comments provided.
Unlocked Objects: When Change Control is enabled in the database and no active lock exists, psLens displays a green status badge confirming the object is available for checkout.
Change Control Disabled: If Change Control is disabled system-wide in the environment, psLens cleanly renders project associations without lock overhead.
Supported Object Types
Change Control and lock tracking is supported across all major PeopleSoft metadata definitions:
Explore PeopleSoft query and reporting definitions: PSQuery and Query Trees.
Reporting Definitions
Browse and inspect PeopleSoft reporting objects, queries, and security query trees.
5.5.1 - Queries
Browse PeopleSoft Queries with record/field usage, query trees, security access, and ownership.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Queries are PeopleSoft’s end-user reporting tool — saved SQL queries that users run from the PSQUERY interface, with optional prompts, output formats, and scheduled distribution. Each query is stored in PSQRYDEFN and broken out across PSQRYRECORD, PSQRYFIELD, and other tables for the records and fields it touches. psLens consolidates the query header, the records used, the field list, project membership, and (via the related-data toggles) the query tree placement and security access.
Object Relationships
Queries assemble records and fields into end-user reporting SQL:
Selects Records & Fields: Queries (PSQRYDEFN) join record definitions (PSQRYRECORD) and select specific fields (PSQRYFIELD).
Governed by Query Access Trees: Authorization to query underlying records is controlled by Query Access Trees (PSTREENODE) granted to permission lists.
Feeds BI Publisher Reports: Queries act as data sources (PSXPDATASRC) for BI Publisher report definitions.
How psLens Improves Query Inspection
In Query Manager, inspecting a query requires clicking across Records, Fields, and Properties tabs, while query tree access must be checked via separate SQL queries.
psLens consolidates query properties, FROM clause records, SELECT/ORDER BY fields, query tree security placement, and project membership into a single view.
Search Page
URL: /queries?db={database}
Query search results for PT_%
Search auto-matches as starts with. Typing PT_ finds every query whose name begins with PT_. Include % yourself for ends-with (%_VW) or contains (%AUDIT%) patterns, or use % alone to list every row. Each card shows the query type (Public, Private, Archive, User), owner, and last-updated metadata. The Advanced Filters panel lets you filter by query type or owner.
Detail Page
URL: /queries/{QRYNAME}?db={database}
Query detail page for PTCPQFIELD_VW
The main pane shows Query Properties (type, owner, description, last-run metadata, version), Records Used (every record in the FROM list), and Fields (the SELECT and ORDER BY columns). The sidebar has 3 related-data toggles.
Full query detail page with all panels
Related Data Panels
Records Used
Every record in the query’s FROM clause
The list of records used by the query (PSQRYRECORD). Each record name deep-links into its own detail page so you can audit what the query reads.
Fields
The fields the query SELECTs, with record context and order
The SELECT field list (PSQRYFIELD) with record and field references, each link-resolved.
Included in Projects
App Designer projects that include this query
App Designer projects containing this query as a project item.
5.5.2 - Query Trees
Browse PeopleSoft Query Access Trees with record hierarchies and the permission lists that grant access.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Query Access Trees are the security backbone of PeopleSoft Query — hierarchical groupings of records (PSTREEDEFN / PSTREENODE) that determine which records a Query author can build queries against. A permission list grants access to one or more access groups within a tree, and the Query Manager UI only lists records that fall under the granted nodes. psLens shows the tree’s full record hierarchy and the permission lists that authorize it, combining what you’d otherwise need to assemble from Tree Manager and Permission List security separately.
Object Relationships
Query Access Trees regulate reporting access to database records:
Groups Records Hierarchically: Query Trees (PSTREEDEFN) arrange record definitions into nested access group nodes (PSTREENODE).
Secured by Permission Lists: Permission lists are granted access to specific tree nodes to authorize users to query member records.
How psLens Improves Query Tree Inspection
Auditing Query Access Trees in PIA requires expanding tree nodes branch by branch in Tree Manager, while checking permission list profiles separately to determine authorized users.
psLens presents the complete record hierarchy alongside permission lists, assigned roles, and authorized active/locked users in a single view.
Search Page
URL: /querytrees?db={database}
Query Tree search results
Search auto-matches as starts with. Typing EOQF finds every tree whose name begins with EOQF. Include % yourself for ends-with or contains patterns, or use % alone to list every query tree in the database.
Detail Page
URL: /querytrees/{TREE_NAME}?db={database}
Query Tree detail page for EOQF_QUERY_TREE
The main pane shows Tree Properties (status, version, audit metadata) and the full Tree Hierarchy, a recursive view of every node in the tree with the record name it grants access to. The sidebar has one related-data toggle.
Full Query Tree page with the Permission Lists panel expanded
Related Data Panels
Tree Hierarchy
The full record hierarchy of the tree, with each record linked to its detail page
The recursive node-by-node breakdown of the tree. Each record link jumps into the record’s detail page so you can see what data the tree grants query access to.
Permission Lists
Permission lists with access to nodes in this tree
Permission lists that have been granted access to nodes in this tree.
Roles
Roles that grant access to nodes in the tree, derived from the permission lists associated with each role.
Users
Users who can access the query tree, detailing their status (Active or Locked), role, permission list, and access group grant level. Grants are annotated as Tree-level if they target the root node of the tree, and Node-level for sub-nodes.
5.6 - Integration Broker
Explore PeopleSoft Integration Broker definitions: nodes, services, service operations, messages, and queues.
Integration Broker Definitions
Browse and inspect PeopleSoft integration objects and routing topology.
5.6.1 - Nodes
Browse PeopleSoft Integration Broker nodes — external systems, partner databases, and internal services that exchange IB messages.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Nodes are the network endpoints of the PeopleSoft Integration Broker. Each external system, partner database, or other PeopleSoft environment that sends or receives messages is represented as a node (PSMSGNODEDEFN). The node carries connection settings (connector type, target URL, authentication mode) and is the unit referenced by every routing rule. psLens shows the node configuration, every routing that involves this node, the service operations granted to its default user, and an inventory of URI text configured against it.
Object Relationships
Nodes represent integration targets and security identities in Integration Broker:
Endpoints for Routings: Nodes (PSMSGNODEDEFN) are configured as senders or receivers in Routing definitions (PSIBRTNGDEFN).
Binds User Authorization: Nodes link to default user accounts (OPRID) that dictate execution rights for incoming service operation requests.
How psLens Improves Integration Node Inspection
Reviewing Integration Broker nodes in PIA requires stepping through Connectors, Portal, WS Security, and Routings tabs, while searching Service Operations permissions separately for default node users.
psLens surfaces node properties, password security flags, routing traffic, default user service operation permissions, and URI text in a unified view.
Search Page
URL: /nodes?db={database}
Node search results for PSFT%
Wildcard % search supported. Each card shows the node type (Local, External, Hub), the node’s active flag, the default user ID, and the descriptive name. Enough at a glance to spot inactive nodes or nodes pointing at unexpected user accounts.
Detail Page
URL: /nodes/{NODENAME}?db={database}
Node detail page for PSFT_CS
The main pane shows Node Properties: node type, connector ID, default user, authentication option, password-set indicator, contact, and audit metadata. The password-set indicator is the security view: a node with authentication required but no password set is a flag worth investigating (see the Nodes with No Password report). The sidebar has 4 related-data toggles.
Related Data Panels
Routings
Every routing rule that involves this node (sender or receiver)
Every routing rule (PSIBRTNGDEFN) where this node appears as sender or receiver, with the service operation, direction, and status. Lists the message traffic that flows through this node.
User’s Service Operations
Service operations the node’s default user has permission to invoke
The service operations the node’s default user has been granted permission to invoke. Important for security audits, since a node’s default user can be granted service operations that the human OPRID would never get.
URI Text
URI text entries configured against the node
The URI text entries configured against the node (PSIBNODEURITEXT). The per-node URL fragments used in REST-style integrations.
Included in Projects
App Designer projects that include this node
App Designer projects that include the node definition.
5.6.2 - Services
Browse PeopleSoft Integration Broker services — logical groupings of related service operations.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
A Service is the high-level container in the Integration Broker hierarchy: a logical grouping of related Service Operations (PSSERVICEDEFN). For example, a STUDENT_ENROLLMENT service might contain GET_ENROLLMENT, ADD_ENROLLMENT, and DROP_ENROLLMENT operations. The service itself carries metadata (description, owner, WSDL namespace) and acts as the access point for browsing operations together.
Object Relationships
Services organize Integration Broker message contracts into logical domain groups:
Groups Service Operations: Services (PSSERVICE) act as parent containers grouping individual Service Operations (PSOPERATION).
How psLens Improves Service Inspection
In PIA, inspecting Integration Broker services requires navigating Integration Setup → Services and clicking through individual operation tabs to view member endpoints.
psLens displays service metadata alongside all contained service operations on a single screen with one-click drilldowns into detailed operation contracts.
Search Page
URL: /services?db={database}
Service search results for PT_%
Wildcard % search supported. Each card shows the service name, alias, and description.
Detail Page
URL: /services/{SERVICE}?db={database}
Service detail page for PTCS_SECURITY
The main pane shows Service Properties (name, alias, namespace, owner, description, audit metadata). The sidebar has one related-data toggle.
Full service page with Service Operations panel expanded
Related Data Panels
Service Operations
Every service operation belonging to the service
Every service operation belonging to the service, each link-resolved into its own detail page. The starting point for understanding what messages the service can exchange.
5.6.3 - Service Operations
Browse PeopleSoft Integration Broker service operations with versions, handlers, routings, security grants, and IB transaction history.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
A Service Operation is the actual message-exchange contract — the unit that defines what message type is sent, in which direction (async or sync), through which routings, and handled by which PeopleCode. Each operation belongs to a service and is stored in PSOPERATION with related metadata in PSOPRDESC, PSOPRROUTING, PSOPRHANDLER, and the security tables. psLens consolidates the full operation — versions, routings, handlers, caller nodes, security access from three angles, and live IB transaction history — into one page.
Object Relationships
Service Operations form the central communication contracts in Integration Broker:
Belongs to Services: Operations (PSOPERATION) are grouped under parent Service definitions (PSSERVICE).
Carries Message Schemas: Operations define request and response payload structures using Message definitions (PSMSGDEFN).
Routed via Nodes: Operations use Routing definitions (PSIBRTNGDEFN) to direct messages between sender and receiver Nodes (PSMSGNODEDEFN).
Processed by Handlers: Operations invoke Application Class or App Engine handlers (PSOPRHDLR) upon message arrival or dispatch.
Secured by Permission Lists: Permission lists (PSAUTHWS) authorize execution of Service Operations.
How psLens Improves Service Operation Inspection
Auditing Integration Broker service operations in PIA requires opening operation definitions, switching between Handlers and Routings tabs, searching permission list Web Services security, cross-referencing role membership, and checking Asynchronous Monitor logs separately.
psLens consolidates operation versions, routings, handlers, three security access views (permission lists, roles, users), caller nodes, project membership, and live transaction history onto a single screen.
Search Page
URL: /serviceoperations?db={database}
Service Operation search results for PT_%
Wildcard % search supported. Each card shows the operation type (Async, Sync, One Way), default version, and active flag.
Detail Page
URL: /serviceoperations/{OPERATION}?db={database}
Service Operation detail page for PTBR_BRANDING_DEFINITIONS
The main pane shows Operation Properties plus four always-visible cards: Versions (every operation version with default flag and message type), Routings (every routing definition with sender/receiver nodes and direction), Handlers (handler PeopleCode and class implementations), and HTTP Request Template (the template body for HTTP-style transactions). The sidebar has 6 related-data toggles, including three security access lenses, project membership, and a live IB transaction history feed.
Related Data Panels
Permission Lists with Access
Permission lists that grant access to this operation
Permission lists with Full Access or Web Library Access to this operation. The security baseline for which permission lists let a user invoke this operation.
Roles with Access
Roles that contain a permission list granting access to this operation
The roles that contain any of the granting permission lists — saves you from having to walk Permission List → Role mapping manually.
Users with Access
Users whose roles ultimately grant access to this operation
The users whose role membership ultimately grants them access to call this operation, with an optional toggle to include or exclude locked accounts. The end-of-chain answer for who can call this endpoint.
Caller Nodes
Nodes whose default user has access to invoke this operation
Inverts the lens to the integration side: lists nodes whose default user has been granted access to invoke this operation — useful for confirming which external systems can call the endpoint.
Included in Projects
Application Designer projects containing this Service Operation (PSPROJECTITEM.OBJECTTYPE = 80). Shows project name, description, and object owner ID.
IB Transaction History
Recent runtime invocations of the service operation
Recent runtime invocations from PSIBLOGHDR — timestamps, status, transaction ID. The link from “what is configured” to “what is actually happening.” Lets you confirm an operation is being called (or spot that it never is).
5.6.4 - Application Services
Browse PeopleSoft Application Services Framework (ASF) definitions — REST APIs backed by application classes, with their operations, URI templates, parameters, result states, header properties, and security.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
An Application Service is an Application Services Framework (ASF) definition, stored in PSIBAPPLDEFN. It exposes a REST API backed by application classes, without the hand-built service operations that classic Integration Broker requires. psLens consolidates the service’s operations, URI templates and REST methods, method parameters, result-state-to-HTTP-status mappings, header properties, and security grants onto one page.
Object Relationships
Application Services define REST API boundaries over Application Classes:
Exposes REST URIs & Operations: Application Services (PSIBAPPLDEFN) define REST operations (PSIBAPPLOPR) and URI templates (PSIBAPPURI) mapped to HTTP methods.
Secured by Permission Lists: Permission lists (PSAUTHAS) authorize access to specific Application Services.
How psLens Improves Application Service Inspection
In PIA, inspecting Application Services Framework (ASF) REST APIs requires switching across operation, URI, parameter, and result-state tabs, then checking Web Services security for each permission list separately.
psLens combines the complete REST API surface—operations, URI templates, HTTP methods, parameters, result state mappings, and security grants—on a single page.
Search Page
URL: /appservices?db={database}
Wildcard % search supported. Search runs against the ASF definitions in PSIBAPPLDEFN. Each result card links to the application service detail page.
Detail Page
URL: /appservices/{APPLNAME}?db={database}
The main pane shows the service properties and an always-visible Operations & REST Surface card: each operation’s handler application class, plus a table of its URI templates with the REST methods (GET, POST, PUT, DELETE) mapped to each. The sidebar has four related-data toggles.
Related Data Panels
Parameters
Method parameters for the service’s operations, read from PSIBPARAM and the related base/template parameter tables.
Result States
The mapping from operation result states to HTTP status codes (PSIBAPPLSTATES) — what status a caller receives for each outcome.
Header Properties
Header properties configured for the service (PSIBAPPLHDRPROP).
Security
Permission lists that grant access to the application service, read from PSAUTHAS. The answer to which permission lists let a user call this REST API.
Tables Used
PSIBAPPLDEFN — application service (ASF) definitions
PSIBAPPLSTATES — result-state to HTTP-status mappings
PSIBAPPLHDRPROP — header properties
PSAUTHAS — application service authorization per permission list
PSSERVICEOPR — service operations within the service
5.6.5 - Messages
Browse PeopleSoft Integration Broker message definitions — the payload schemas referenced by service operations.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
A Message definition is the payload schema that a Service Operation carries. It defines the structure of the XML or JSON document exchanged between systems. Messages can be rowset-based (mapped to PeopleSoft records), nonrowset-based (free-form XML/JSON), container, or document. psLens reads PSMSGDEFN and the version-specific details from PSMSGSCHEMA, then surfaces the service operations that reference each message and the projects that own them.
Object Relationships
Messages define the data payload structures exchanged by Integration Broker endpoints:
Payload Schemas for Service Operations: Messages (PSMSGDEFN) act as request and response payload schemas for Service Operations (PSOPERATION).
Mapped to Records: Rowset-based messages map directly to underlying record definitions (PSRECDEFN).
How psLens Improves Integration Message Inspection
In PIA, inspecting Integration Broker messages requires opening message definitions, switching versions, and manually searching service operation registries to locate payload references.
psLens displays message version schemas, mapped record structures, referencing service operations, and project membership side by side.
Search Page
URL: /msgdefns?db={database}
Message search results for PT_%
Wildcard % search supported. Each card shows the message type and version.
Detail Page
URL: /msgdefns/{MESSAGE}?db={database}
Message detail page for PTCS_ACCESSIN
The main pane shows Message Properties (alias, owner, description, audit metadata) and a per-version card listing each message version with its type (Nonrowset-Based, Rowset-Based, Container, Document) and the schema details. The sidebar has 2 related-data toggles.
Full message detail page with both panels expanded
Related Data Panels
Service Operations Using This Message
Service operations that reference this message as request or response payload
Service operations that reference this message as a request or response payload.
Projects Containing This Message
App Designer projects that include this message
App Designer projects containing this message as a project item.
5.6.6 - Queues
Browse PeopleSoft Integration Broker queues — async ordering containers that group related service operations.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
A Queue is an Integration Broker ordering construct. Async service operations attached to the same queue process serially in the order they arrived, while operations on different queues can run in parallel. Queues are also the unit where IB pauses (“Pause” status) when an administrator stops message processing for maintenance. Each queue is stored in PSQUEUEDEFN with a status (Run, Pause) and a partitioning configuration.
Object Relationships
Queues manage message processing order and concurrency for Integration Broker:
Orders Service Operations: Queues (PSQUEUEDEFN) group asynchronous Service Operations (PSOPERATION) to enforce sequential or parallel execution flow.
How psLens Improves Integration Queue Inspection
In PIA, queue configuration lives under PeopleTools → Integration Broker → Integration Setup → Queues, and locating dependent service operations requires walking each operation separately.
psLens shows queue run/pause status and all dependent service operations on a single page, helping administrators instantly spot paused queues and stalled integrations.
Search Page
URL: /queues?db={database}
Queue search results for PT_%
Wildcard % search supported. Each card shows the queue’s run/pause status, the fast way to spot a paused queue causing a stalled integration.
Detail Page
URL: /queues/{QUEUE}?db={database}
Queue detail page for PTAF_APPROVALS
The main pane shows Queue Properties (status, partitioning method, archive flag, owner, description) and a Service Operations Using This Queue card. Queues are simple objects — there are no sidebar toggles.
Full queue detail page
Service Operations Using This Queue
Service operations bound to this queue
The list of service operations bound to this queue. Together with the IB Monitor, this shows what stops processing when the queue is paused.
5.7 - Batch Processing
Explore Process Scheduler definitions: Application Engine programs, process definitions, jobs, recurrences, and servers.
Batch Processing Definitions
Browse and inspect PeopleSoft batch and Process Scheduler definitions.
5.7.1 - App Engines
Browse PeopleSoft Application Engine program structures, sections, steps, actions, and source code.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Application Engines (AE) are PeopleSoft’s batch processing framework. Unlike traditional COBOL or SQR programs, Application Engine programs are defined in PeopleSoft metadata tables (such as PSAEAPPLDEFN, PSAESECTDEFN, PSAESTEPDEFN, and PSAESTMTDEFN) and executed by the psae batch executable. They are commonly used for data processing, background calculations, integrations, and ETL processes.
psLens allows you to search and browse the structure of Application Engine programs, inspect their sections, steps, and actions, and view the associated SQL and PeopleCode source code without opening App Designer.
Object Relationships
Application Engines structure batch execution across database tables and code modules:
Scheduled via Process Definitions: App Engines are mapped to Process Definitions (PRCSDEFN) for scheduling and execution in Process Scheduler.
How psLens Improves Application Engine Inspection
In Application Designer, reviewing an Application Engine program requires opening individual section and step nodes, clicking into actions, and switching windows to inspect SQL statements or PeopleCode scripts.
psLens presents the full section/step/action hierarchy with inline, syntax-highlighted SQL and PeopleCode source code viewable without opening Application Designer.
Search Page
URL: /appengines?db={database}
Search: Search for Application Engines by program name (prefix match). Type PSAE to find all AEs starting with PSAE. Use % as a wildcard if needed (e.g., %PRCS% to find programs containing PRCS).
Metadata Card: Each search result card shows the program description, owner ID, and last modified operator/timestamp.
Detail Page
URL: /appengines/{APPLID}?db={database}
The Detail Page exposes the internal structure of the Application Engine program:
Program Properties: Shows description, owner ID, program type (Standard, Upgrade, Import, Daemon), active status, disable restart setting, and modification details.
Sections & Steps Tree: Lists all sections (e.g., MAIN) and steps defined in the program.
Actions View: For each step, psLens shows the actions it executes (SQL, PeopleCode, Call Section, Log Message, XSLT, Do Select, Do Until, Do While, Do When).
Source Code Viewer: Steps that run SQL or PeopleCode actions can be expanded to view the actual code inline.
Export as Markdown: Reconstructs the entire Application Engine structure, including all sections, steps, actions, and embedded code, into a single structured Markdown file.
5.7.2 - Process Definitions
Browse PeopleSoft Process Scheduler process definitions with configuration, output options, execution statistics, and schedule variance.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Process definitions (PRCSDEFN) specify the batch programs, reports, and scripts executable via PeopleSoft Process Scheduler. They map a logical process name to an underlying program type (SQR, Application Engine, COBOL, XML Publisher) and define command-line parameters, run control components, and default output options.
psLens pulls the process definition properties, execution statistics, recurrence schedule variance, run control record mappings, and project membership into a single browser view.
Object Relationships
Process Definitions configure batch program execution within Process Scheduler:
Executes Batch Programs: Process Definitions (PRCSDEFN) map to underlying executable objects such as App Engines (PSAEAPPLDEFN), SQRs, or COBOL programs.
Mapped to Run Control Components: Process Definitions link to run control components (PRCSDEFNPNL) that store parameters in header/detail records.
Bundled in Process Jobs: Process Definitions can be grouped together into Process Jobs (PSPRCSJOBDEFN).
How psLens Improves Process Definition Inspection
In Application Designer or Process Scheduler setup, reviewing a process definition requires navigating separate tabs for parameters, locations, and output destinations, while execution metrics require running custom SQL against PSPRCSRQST.
psLens combines definition properties, historical statistics, recurrence schedule variance, run control record mappings, and project membership into a single view.
Search Page
URL: /processdefinitions?db={database}
Process Definition search results for pt showing Application Engine processes
Search: Search by process name (prefix match) or wildcard % patterns (for example, %AUDIT% or %).
Filters: Filter process definitions by process type (e.g., Application Engine, SQR Report), component, or modification metadata.
The Detail Page displays process configuration, historical metrics, and schedule variance:
Configuration & Properties: Displays execution details including command-line parameters, target server name, API awareness, run control component, and priority.
Output Settings: Shows output type (Web, File, Printer) and output format (PDF, CSV, HTML).
Execution Statistics
Execution Statistics panel summarizing run history, success rates, top operators, and servers
psLens analyzes historical process request data (PSPRCSRQST) to present statistics on:
Total runs, average execution duration, and first/last run timestamps.
Run status breakdown (percentage of successful versus failed or queued runs).
Top operators and servers executing the process.
Recurrence History & Schedule Variance
Recurrence Run History & Schedule Variance panel highlighting schedule latency and instance run logs
For processes executed via recurrence schedules (RECURNAME <> ' '), psLens calculates schedule latency:
Start Delay Variance (BEGINDTTM - RUNDTTM): Compares target scheduled run times against actual execution start times.
Summary Metrics: Displays Total Recurring Runs, Average Start Delay, Maximum Start Delay (with instance ID), and On-Time Rate percentage.
Delay Breakdown & Historical Log: Categorizes runs into On Time (≤ 1m), Minor Delay (1-5m), and Significant Delay (> 5m) with instance-level status badges.
Related Data Panels
Run Control Records & Jobs
Run Control Records panel showing mapped component PRCSMULTI and header record PRCSSAMPLEREC
Run Control Records: Identifies the run control component (PRCSMULTI) and mapped header/detail tables (PRCSSAMPLEREC) used to store process parameters.
Jobs: Displays Process Job definitions (PSPRCSJOBDEFN) that include this process as a job item.
Included in Projects
Queries PSPROJECTITEM where OBJECTTYPE = 20 to display Application Designer projects containing this Process Definition.
5.7.3 - Process Jobs
Browse PeopleSoft Process Scheduler job definitions and inspect their sequence of execution.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Process Jobs (also called Job Definitions) are groups of one or more process definitions (or other jobs) bundled together to run as a single scheduled unit. A job executes its constituent processes in a defined sequence or in parallel, depending on the job definition.
psLens allows you to browse job definitions, inspect the list of items inside each job, and check their execution sequence.
Object Relationships
Process Jobs organize multiple batch tasks into structured execution pipelines:
Bundles Process Definitions: Process Jobs (PSPRCSJOBDEFN) group multiple Process Definitions (PRCSDEFN) or nested sub-jobs into a single run request.
Scheduled via Recurrences: Process Jobs can attach to Recurrences (RECURNAME) for automated repeating execution.
How psLens Improves Process Job Inspection
In Process Scheduler setup, reviewing job definitions requires clicking through nested job item tabs and manually checking process sequence numbers.
psLens displays job properties, nested process definitions, execution sequence numbers, and run modes in a clean, unified view.
Search Page
URL: /processjobs?db={database}
Search: Search for job definitions by job name (prefix match).
Metadata Card: Results display the job description, owner, and modification timestamps.
Detail Page
URL: /processjobs/{JOBNAME}?db={database}
The Detail Page displays:
Job Properties: Basic settings, such as description, run control validation, and server settings.
Job Items & Sequence: A table showing all processes and sub-jobs nested within this job, including:
Run order/sequence number.
Process Type and Process Name.
Description.
Run mode (e.g., Serial, Parallel).
Export as Markdown: Export the job definition and its sequence table to a markdown document.
5.7.4 - Recurrences
Browse PeopleSoft Process Scheduler recurrence schedules and check their next execution times.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Recurrences define repeating schedule patterns used by the PeopleSoft Process Scheduler. Whenever a process or job is scheduled to run on a repeating schedule (e.g., daily, weekly, hourly), it is linked to a recurrence definition.
psLens allows you to search and view recurrence patterns to understand when a scheduled task is slated to run next and how frequently it triggers.
Object Relationships
Recurrences drive automated scheduling for batch requests:
Schedules Processes & Jobs: Recurrence definitions (RECURNAME) attach to Process Definitions (PRCSDEFN) or Process Jobs (PSPRCSJOBDEFN) to automate recurring execution.
How psLens Improves Recurrence Schedule Inspection
In PIA, inspecting process recurrences requires opening schedule setup windows and calculating future execution times manually.
psLens displays recurrence frequency parameters, active run windows, and next-run predictions on a single screen.
Search Page
URL: /recurrences?db={database}
Search: Search recurrence definitions by name (prefix match).
Metadata Card: Shows the description, owner, and modification timestamps.
Detail Page
URL: /recurrences/{RECURNAME}?db={database}
The Detail Page displays:
Recurrence Pattern Details: Shows recurrence settings such as:
Frequency (Daily, Weekly, Monthly, Hourly).
Run times (e.g., Daily at 12:00 AM, or every 5 minutes).
Selection of specific days of the week or month.
Start and end dates/times.
Next Run Prediction: Displays when the recurrence is next due to execute.
Export as Markdown: Export the recurrence schedule parameters as a markdown file.
5.7.5 - Server Definitions
Browse PeopleSoft Process Scheduler Server Definitions, monitor live running tasks, and inspect daemon settings.
Tailored Operational Context
Target Database:—
Context Type:—
Alert Severity:—
Triggered Time:—
Firing Context:—
Server Definitions represent the Process Scheduler Servers that are defined inside PeopleSoft. These servers execute the batch processes (like Application Engines, SQRs, etc.) and manage scheduling recurrences and daemon processes.
psLens allows you to search and browse server definitions to see how a server is configured, check its live heartbeat status, see active running processes, review what process classes and categories it is authorized to run, check operational schedules, and view its notification routing.
Object Relationships
Server Definitions act as the execution engines for batch processing:
Executes Process Requests: Server Definitions (PSSERVERDEFN) execute Process Definitions (PRCSDEFN) and Process Jobs (PSPRCSJOBDEFN) assigned to their queues.
Monitors System Status: Server instances update live heartbeat and CPU metrics in PSSERVERSTAT.
How psLens Improves Server Definition Inspection
Monitoring Process Scheduler servers in PIA requires switching between Process Monitor server status pages, daemon configuration windows, and process category assignments.
psLens consolidates real-time server heartbeats, active running processes, CPU/memory metrics, daemon settings, authorized process categories, and status notification lists into a single view.
Search Page
URL: /servers?db={database}
Search: Search for server definitions by name (prefix match, e.g., PRCS%).
Metadata Card: Shows the description, operating system, daemon status, and modification timestamps.
Detail Page
URL: /servers/{SERVERNAME}?db={database}
The Detail Page displays:
Server Status: Shows real-time heartbeat and diagnostics from PSSERVERSTAT including:
Current status (Running, Down, Suspended, Overloaded, etc.) with relative “time ago” timestamps.
CPU and Memory utilization.
Free disk space and thresholds.
AE/OE Server counts.
Active Running Processes: Live grid of active processes (Initiated, Processing, Running) currently executing on the server from PSPRCSRQST.
Server Definition Properties: Displays configuration metrics like version, sleep time, heartbeat frequency, max concurrent API aware/unaware tasks, distribution node details, CPU/Memory threshold configs, and load balancing/redistribution option choices.
Server Daemon Details: Shows daemon configuration:
Enabled state, daemon group, sleep time, recycle counts.
Active daemon process instance (with direct link to its Process Monitor view).
Process Categories: Authorized process categories with priority and max concurrent execution counts.
Process Types: Specific process types the server is configured to run, categorized by operating system, priority, and concurrent limits.
Server Operation Times: Scheduled operation windows when the server is active (24/7 or day/time ranges).
Status Notifications: List of users and roles notified upon server status changes (e.g., when the server goes down or encounters an error), displaying active status flags as checkboxes.
Export as Markdown: Export the entire server definition structure and live status/child tables as a markdown file.
6 - Tools
Additional developer and operational utilities in psLens.
Tools
Developer and operational utilities that span multiple features and object types in psLens:
Global Search — Quick, keyboard-driven navigation across all PeopleSoft metadata and security definitions.
Deep Linking — Permanent shareable URLs, cross-object navigation, and structured markdown exports.
DMS Viewer — Inspect, query, and generate SQL INSERT statements from PeopleSoft Data Mover .dat files.
Compare Reports — Inspect, analyze, and export PeopleSoft Application Designer binary compare reports (.idx and .prt files).
Markdown Viewer — Open, inspect, format, and print or export PeopleSoft markdown downloads and documents.
6.1 - Global Search
Global Search Icon: Click the search magnifying glass icon in the top navigation bar from any page within the psLens interface.
Global Search
Global Search is a cross-object navigation tool in psLens. Rather than navigating to individual object search pages (like Fields, Components, or Users), Global Search allows you to search across all PeopleSoft metadata and security definitions simultaneously from a single search modal.
Walkthrough: Using Global Search to quickly locate and navigate to PeopleSoft objects
How to Access Global Search
Global Search Icon: Click the search magnifying glass icon in the top navigation bar from any page within the psLens interface.
Keyboard Shortcut: Press Ctrl + K (Windows/Linux) or Cmd + K (Mac OS) to trigger the search modal instantly.
Search Coverage
Global Search queries the selected database in real time to return matches across multiple object categories:
Object Type
Fields Searched
Fields
Field Name (FIELDNAME), Short/Long Descriptions
Records
Record Name (RECNAME), Record Description
Pages
Page Name (PNLNAME), Page Description
Components
Component Name (PNLGRPNAME), Description
Menus
Menu Name (MENUNAME)
Permission Lists
Class ID (CLASSID), Description
Roles
Role Name (ROLENAME), Description
Users
OPRID, User Description
Process Definitions
Process Name (PRCSNAME), Description
SQL Objects
SQL Object Name (SQLID)
Application Packages
Package Root (PACKAGEROOT)
Application Engines
App Engine Name (AE_APPLID)
Key Features
Categorized Results:
Results are grouped dynamically by object type, allowing you to quickly scan through Records, Fields, or Users matching your query.
Deep Linking:
Clicking any search result takes you directly to that object’s detail page in the active database.
Multi-Database Support:
The search queries the active database selected in your nav bar. You can quickly switch databases from the top navigation to search the same term in a different environment.
6.2 - Deep Linking
Every PeopleSoft object in psLens has a permanent, shareable URL.
Shareable URLs
Every PeopleSoft object in psLens has a permanent, shareable URL. Copy the address bar, paste it into a ticket or Slack, and anyone with psLens access lands on the same object in the same database.
PeopleSoft’s native URLs are session-bound and cannot be shared or bookmarked reliably. psLens URLs can.
URL Structure
All object URLs follow the same pattern:
/resource/{identifier}?db={database}
resource — the object type (e.g., records, fields, permissionlists)
identifier — the object name as it appears in PeopleSoft (e.g., JOB, EMPLID, HCDPALL0100)
db — the configured database name, so the link is unambiguous about which environment it points to
Linkable Object Types
psLens provides direct URLs for over 25 PeopleSoft object types:
Category
Objects
Security
Permission Lists, Roles, Users
Objects
Projects, Project Import, Fields, Records, SQL Objects, Pages, Components, Component Interfaces, Menus, Content References (CREFs), Message Catalogs, Application Packages, URLs, HTML Definitions, Style Sheets, Queries, Query Trees, Nodes, Services, Service Operations, Messages, Queues, Application Engines, Process Definitions, Process Jobs, Recurrences
Every object listed above can be linked to directly. For example:
/records/JOB?db=PROD — the JOB record definition in your PROD database
/crefs/EMPLOYEE/PT_PORTAL_ROOT?db=PROD — a content reference (CREF) in the EMPLOYEE portal in PROD
/permissionlists/HCDPALL0100?db=DEV — a permission list in DEV
/serviceoperations/USER_PROFILE.v1?db=PROD — a service operation in PROD
Cross-Object Navigation
Detail pages link to related objects. When you view a record, the fields listed on that page link to their own detail pages. When you view a component, the pages within it are clickable. When you view a permission list, the roles that include it are linked.
This means you can navigate through the PeopleSoft object graph by clicking — from a record to its fields, from a field to the records that use it, from a component to its pages, and so on. Breadcrumbs at the top of each detail page show where you are in the hierarchy.
On Component detail pages, the portal navigation path shows clickable breadcrumb segments — each segment links to the CREF (Content Reference) definition for that folder or component, allowing you to navigate the portal registry hierarchy directly. The portal name itself links to browse all CREFs in that portal.
Clickable PeopleCode References
When viewing PeopleCode source code in psLens, references to Application Classes and Declared Functions are clickable.
An Application Class reference (e.g. PT_BRANDING:BrandingElement) links directly to the corresponding Application Package page.
A declared external function (e.g., Declare Function Get_Schedule PeopleCode RECORD.FIELD Event) links directly to the record field event containing the function definition.
Deep Links with Pre-Expanded Sections
Some detail pages support query parameters that pre-expand specific sections. This is useful when you want to share a link that shows exactly the information someone needs to see.
This link opens the JOB record in PROD with the PeopleCode section expanded and the EMPLID.FieldChange event visible — one click to the exact code your colleague needs to review.
Practical Use Cases
Audit and Compliance
In an audit workpaper, paste the psLens URL instead of a screenshot. The reviewer clicks through to the live object with no ambiguity about which permission list, which role, which version.
Reference the exact permission list, role, or user profile in an audit finding
Cite the exact URL in the finding; six months later the reviewer can re-open it
Eliminate the “which screen was that?” problem when revisiting findings months later
Incident Response and Troubleshooting
Instead of typing “open App Designer, find project XXXX, look at record YYYY,” paste a link into Slack or your incident channel. Everyone on the call arrives at the same view instantly.
Share the exact service operation that is failing
Link to the process definition that is stuck
Point teammates to the specific record or component under investigation
Change Management
When documenting changes in ServiceNow, Jira, or any ticketing system, include psLens links to the objects affected by the change.
Link to the project definition to show exactly what objects are included in a release
Reference specific components or records in change request descriptions
Build runbooks with clickable links instead of navigation instructions
Security Reviews
Security administrators can share direct links to the objects under review, making it easy for reviewers to verify configurations without navigating there themselves.
Link to permission lists with show_components=true to show what access they grant
Share user profile links showing role assignments
Reference exact objects in security audit reports and remediation tickets
Team Collaboration
A business analyst on the change call doesn’t need App Designer open. Paste the link, they see the record.
Markdown Export
Every PeopleSoft object detail page in psLens can export its full definition as a Markdown file. This exported file can be attached to documentation, included in a wiki, or stored alongside change records. Combined with deep links, you get both a static snapshot and a live reference back to psLens.
Look for the Export as Markdown card in the right-hand sidebar of any object detail page — records, fields, pages, components, menus, application packages, app engines, component interfaces, SQL objects, URLs, HTML and stylesheet definitions, projects, queries, query trees, message catalogs, CREFs, nodes, services, service operations, messages, queues, permission lists, roles, users, process definitions, process jobs, and recurrences.
Recursive PeopleCode Resolution
For objects containing PeopleCode (such as records, components, application packages, and app engines), the export card includes a Recursively resolve imports toggle. When enabled, psLens parses the source code for Application Class imports and external function declarations. It recursively retrieves the source code of those referenced classes and functions from the database and appends them to a dedicated references section in the exported document.
6.3 - DMS Viewer
Upload, inspect, and extract data from PeopleSoft Data Mover (.dat) export files.
What It Is
PeopleSoft Data Mover is commonly used to export data from tables to proprietary .dat binary files for backup, migration, or archiving.
The DMS Viewer in psLens allows you to upload and inspect these binary Data Mover .dat files directly in your web browser. You can inspect table counts, view schema columns, browse exported rows, and generate SQL INSERT statements for individual rows without launching Data Mover or running an import.
Uploading a DMS File
URL: /dms-viewer
To parse a DMS file:
Go to the DMS Viewer page.
Select or drag-and-drop your .dat file (up to 50MB) into the upload area.
The server will parse the binary file structure and display its metadata.
File View
After parsing, the DMS file metadata is shown:
DMS File Metadata: Source database name, Data Mover export version, base language, export start timestamp, table count, and total row count.
Tables list: An index showing all tables exported in the .dat file along with the number of rows exported for each table. Clicking any table name opens its detail view.
Table detail and Row Browser
Inside a table’s view, you can browse its columns and rows:
Columns list: Shows the fields/columns defined for the table in the export.
Row Grid: Displays the exported rows in a paginated table (100 rows per page).
SQL INSERT Generator: Click the Generate SQL action on any row. psLens will reconstruct a standard SQL INSERT statement for that specific row’s data and display it in a copyable text area. Use this to grab a single config row out of a DAT file without running a full import.
6.4 - Compare Reports
Upload, inspect, and analyze PeopleSoft Application Designer binary compare reports (.idx and .prt files).
What It Is
PeopleSoft Application Designer creates compare reports as binary .idx and .prt file pairs when running comparisons between databases.
The Compare Reports tool in psLens lets you upload these reports as a .zip archive or multi-file bundle to inspect definition differences, PeopleCode line diffs, and export summaries without Application Designer.
Uploading Compare Reports
URL: /compare-reports
You can upload compare reports in two formats:
ZIP Archive (Option A): Upload a single .zip file containing the .idx and .prt files produced by Application Designer.
Multiple Files (Option B): Select or drag and drop multiple .idx and .prt files into the upload form.
Compare Run Summary
Once uploaded, the tool extracts run metadata from the .idx files and summarizes the comparison:
Header Metadata: Project name, source database name, target database name, PeopleTools release, and comparison run date.
Changed Object Counts: Total count of modified definitions across all report types.
Definition Types Index: A table of all compared definition types (Records, Pages, Components, Routings, Application Packages, PeopleCode, etc.) with row counts and diff indicators.
Definition and PeopleCode Diff Views
Clicking any report in the overview opens its comparison details:
17-Column Definition Reports: Displays definition keys, action (Copy, Delete, None), upgrade flag (Yes, No), source status, target status, and a table comparing attribute values between source and target databases.
PeopleCode Reports (Upg58): Displays application package, class, and method names, a unified line-by-line diff, and a side-by-side comparison table highlighting changed lines.
Exports
Markdown Summary: Click Export Markdown to download a summary report containing all definition and code differences.
CSV Export: Click Export CSV on any definition report detail page to download attribute diff rows.
6.5 - Markdown Viewer
Open, inspect, format, and export PeopleSoft markdown files.
The Markdown Viewer renders PeopleSoft markdown export files (.md, .markdown, .txt) directly in the browser with full table formatting, syntax-highlighted code fences, and callout blocks.
Overview
psLens allows exporting any PeopleSoft object definition (records, pages, components, roles, permission lists, app engines, queries) and report run to markdown. When users download these files, they can view and inspect them without external markdown editors or desktop utilities.
The viewer is available at /markdown-viewer or through the Tools section in the sidebar.
Loading Markdown Files
The tool supports three input methods:
Drag and Drop: Drop any .md, .markdown, or .txt file onto the upload zone.
File Browser: Click Select File to choose a file from your computer.
Paste Content: Paste raw markdown text into the content area and click Render Markdown.
File uploads are processed in-memory and are bounded to 25MB per file.
Document Features
When a document is loaded, the viewer displays:
Document Statistics: Filename, word count, estimated reading time, file size, and table counts.
Rendered View: GitHub-flavored markdown with styled tables, task lists, and PeopleSoft-specific callout admonitions (NOTE, TIP, IMPORTANT, WARNING, CAUTION).
Code Highlighting: Syntax-highlighted code fences for PeopleCode, SQL, HTML, XML, and CSS blocks.
View Toggle: Switch between the formatted rendered view and raw source text.
Clipboard Copy: One-click copy for the entire raw markdown text.
Print and PDF Export: Browser printing strips application navigation and sidebar elements, producing a clean document for PDF generation or physical printing.
Open Another: Reset the view to open or paste another file.
7 - Model Context Protocol (MCP) & Agent Skills
Embedded Model Context Protocol server and Agent Skills for connecting Google Antigravity, VS Code, Claude Code, and Claude Desktop directly to PeopleSoft intelligence.
Embedded MCP Server
psLens includes an embedded Model Context Protocol (MCP) Server running directly inside the Go server process over Streamable HTTP and HTTP+SSE. It enables LLMs and coding assistants (such as Google Antigravity, VS Code, Claude Desktop, and Claude Code CLI) to inspect, analyze, triage, and compare PeopleSoft environments in real time with zero local daemon installation.
Skill Discovery Index:
psLens implements the open Agent Skills Discovery specification (v0.2.0):
GET /.well-known/agent-skills/index.json
Authentication & Personal Access Tokens
Access to the psLens MCP endpoints (/mcp and /mcp/sse) is secured via cryptographically generated Personal Access Tokens:
Navigate to Tools → AI & Agents (/settings/mcp) in psLens.
Click Generate New Token.
Choose a label (e.g. Google Antigravity, VS Code (MacBook)) and expiration period (30 days, 90 days, 1 year, or never).
Copy the raw secret key (psl_mcp_...). The secret is hashed with SHA-256 and stored in the internal NATS KV store; it is only displayed once upon generation.
Query-string tokens (?token=...) are not accepted: URLs end up in access logs and proxies, and the SSE transport’s endpoint event strips the query string, so query-based auth cannot survive the handshake anyway.
Operational Auditing & Activity Tracking
All MCP tool calls executed by connected AI clients are recorded to an embedded NATS JetStream Stream (mcp-audit) with automatic 30-day retention and a 500 MB disk storage cap.
Administrators can view recent operations, caller tokens, executed tools, target databases, execution durations, and error details directly in the Live MCP Operations Audit Log table at /settings/mcp.
Connecting Your AI Assistants
1. Google Antigravity
Add psLens to your global Antigravity configuration ~/.gemini/config/mcp_config.json or workspace configuration .gemini/mcp_config.json:
Add psLens to your workspace configuration at .vscode/mcp.json. VS Code requires the top-level servers key (not mcpServers) and a type field, and connects over Streamable HTTP at /mcp:
Extension-based MCP managers (Cline, Roo Code) use their own configuration with a top-level mcpServers key. For those, select transport SSE, set the endpoint to https://{{yourorg}}.pslens.com/mcp/sse, and add header Authorization: Bearer psl_mcp_YOUR_TOKEN_HERE.
3. Claude Desktop
Claude Desktop’s configuration file only supports local (stdio) servers — a url entry is silently ignored. Connect through the mcp-remote bridge instead (requires Node.js). Add to your configuration file:
Restart Claude Desktop after saving. Claude Desktop’s Settings → Connectors can add a remote server by URL, but it cannot send a bearer token header, so the bridge is required for psLens tokens.
4. Claude Code CLI
Add psLens with a single command in your terminal:
The psLens MCP surface is structured into 20 tools (18 domain tools + 2 developer tools) with strict payload sizing contracts:
Safe Tool Annotations: All inspection, audit, and triage tools include MCP annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false), eliminating permission popups in Claude Desktop and Cursor.
Envelope Sizing Tiering:
Summary: Small token footprints (~200 tokens) for exploration and high-volume operations.
Structured: Medium token footprints (~1,500 tokens) for focused object inspection.
Full: Markdown / detailed responses (~4,000 tokens) when complete field or code context is required.
Subrecord Expansion: get_record_schema and batch_records_summary flatten nested subrecords by default into an effective field list.
Batch Record Introspection: batch_records_summary resolves up to 25 record schemas in parallel in a single round trip, avoiding multi-turn join query loops.
Credential Protection: get_table_sample_and_count automatically strips sensitive password, hash, and token columns from table row samples.
Client-Safe Output Size: Results larger than 80,000 characters are cut with an explicit [TRUNCATED by psLens ...] marker so the client does not reject the response.
Run any built-in psLens security, IB, or batch audit report on demand with markdown findings
Full (~4,000 tokens)
Passive Resources
Agents can passively subscribe to or read structured context feeds:
pslens://databases: Configured PeopleSoft databases, connection health, and production status.
pslens://catalog/object-types: Catalog of supported PeopleSoft metadata families and search conventions.
pslens://env/summary: Real-time summary of connected environments and active alert counts.
pslens://alerts/active: Live list of all currently firing alert incidents across all monitored environments.
pslens://system/health/{db}: Real-time health sensor telemetry, Process Scheduler status, and IB health for the specified database.
pslens://whitelist/{db}: Whitelisted tables allowed for SWS introspection in a given database.
Workflow Prompts
The MCP server exposes guided multi-step prompts for incident response, development, and proactive monitoring:
proactive_system_monitor: Autonomous monitoring agent sequence inspecting system health telemetry, Process Scheduler status, Integration Broker status, and active alerts.
post_migration_verification: Runs object difference verification, recurrence consistency checks, and IB routing health tests after a project migration.
incident_triage: Automated diagnostic sequence for on-call administrators during production alerts or performance spikes.
user_security_audit: Deep-dive security audit for a specific user ID.
impact_analysis: Calculates upstream and downstream blast radius before modifying a record, field, or component.
event_mapping_impact_analysis: Custom Event Mapping business logic analysis and injected Application Class review before PUM image upgrades.
dms_migration_generator: Guided workflow for generating, linting, and validating Data Mover export/import scripts.
PeopleTools 8.63 Native MCP vs. psLens MCP
PeopleTools 8.63 introduces native Model Context Protocol (MCP) server support directly into the PeopleSoft platform. While both implementations use the open MCP standard, they serve different layers and operational needs:
Capability
PeopleTools 8.63 Native MCP
psLens Embedded MCP Server
Target Audience
End users, functional analysts, developers in App Designer
psLens security and audit reports for PeopleSoft: full access analysis, node password checks, web service access reviews, and more.
Security and Audit Reports
Alerts fire in real time. Reports run on demand against a selected database and produce a Markdown document with findings, evidence, and links back into psLens. Run them before an upgrade, after a migration, or whenever someone asks for proof.
Reports run in the background, render in the browser, and export as Markdown for audit trails and follow-up
How Reports Work
Go to the Reports page and choose a report to run
Select the database you want to analyze
The report runs in the background — you can navigate away and come back
When the report finishes, results are displayed as formatted output in the browser
You can also download the results as a Markdown (.md) file
Reports run asynchronously, so they don’t block the UI and you won’t lose your work if the report takes a few minutes. Progress is shown while the report runs.
Report results are stored for 90 days. You can go back and review previous runs from the Reports page.
Running a Report
Navigate to Reports in the left sidebar
Click Run New Report
Select the report type from the dropdown
Choose the database to run against
Adjust any parameters (such as threshold values) if needed
Click Run
The report appears in your report history as “Running.” Refresh or wait on the page — results appear automatically when the report completes.
Scheduling Reports
In addition to running reports on-demand, you can schedule reports to execute automatically at recurring intervals. Scheduled reports can target specific databases and send notifications when they complete.
How to Schedule a Report
Navigate to Reports and click Run New Report.
Locate the report you want to schedule and click the Schedule button.
In the configuration modal:
Target Databases: Select one or more active databases to target.
Schedule Interval: Choose from Daily, Weekly, or Monthly.
Time of Day: Specify the execution time in server local time (e.g., 02:00 or 14:30).
Notification Deliveries: Toggle Email or Webhook notifications on completion, then select an existing target from the dropdown or input a custom target.
Click Save Schedule. You will be automatically redirected to the Active Schedules page where your new schedule is listed.
Managing Active Schedules
Navigate to Active Schedules in the left sidebar. Here you can:
View: See all scheduled report parameters, target databases, and delivery endpoints.
Edit: Click Edit to modify the recurrence interval, time, targets, or databases.
Cancel: Click Cancel to disable and delete the schedule override.
Downloading Reports
On any completed report’s results page, click Download as Markdown to save the full report output as a .md file. Markdown files are plain text and can be opened in any text editor, rendered on GitHub, or converted to other formats.
If you want to inspect the artifact before installing anything, start with Sample Report Output.
Report Categories
Browse reports by category:
Security — Permission list analysis, password audits, user access reviews
We are open for product feedback. Each report here is a module in the psLens report framework, and the 26 reports were added one module at a time, so new reports are usually quick to incorporate. If your audit or operations work needs a report psLens does not ship, tell us. psLens is onboarding design partners, and partner requests set the build order.
See Reports in Action
The report catalog tells you what each report reads and what it returns. A live walkthrough shows the important part: how teams run them, how long they take, and how the output fits into audits, migrations, and operational reviews.
Security audit reports for PeopleSoft: permission list analysis, password audits, user access reviews, and more.
Eight reports against PSOPRDEFN, PSCLASSDEFN, PSROLECLASS, PSAUTHITEM, and PSMSGNODEDEFN. They answer: who has too much, who has stale credentials, and which IB nodes will let any caller in.
Lists users with special PeopleTools access (Application Designer, Data Mover, Object Security, Query, Import Manager), traced through permission lists and roles
Identifies permission lists granting access to dangerous capabilities such as SOAP-to-CI, WSDL generation, user profile management, and node configuration
Identifies users with native passwords in PSOPRDEFN when using Single Sign-On
8.1.1 - Full Access Permission Lists
This report identifies PeopleSoft permission lists that have an unusually high number of menu authorizations.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies PeopleSoft permission lists that have an unusually high number of menu authorizations. Permission lists with 50+ menu authorizations are usually “superuser” lists that grew organically. Find them so you can audit who has them.
What It Detects
Permission lists where the total count of menu authorizations meets or exceeds a configurable threshold (default: 50).
Menu authorizations are entries in PSAUTHITEM that match real menus in PSMENUITEM via a parent-child join. This excludes special permissions like APPLICATION_DESIGNER, DATA_MOVER, QUERY, and WEBLIB entries.
Tables Queried
PSCLASSDEFN — Permission List Definitions
The primary record for PeopleSoft permission lists (also called “classes”).
Field
Description
CLASSID
Permission list name (primary key)
CLASSDEFNDESC
Description of the permission list
LASTUPDOPRID
Last operator who modified this permission list
LASTUPDDTTM
Timestamp of last modification
PSAUTHITEM — Menu Authorization Entries
Each row represents a menu/bar/item combination that a permission list is authorized to access.
Field
Description
CLASSID
Permission list (foreign key to PSCLASSDEFN)
MENUNAME
Menu name
BARNAME
Menu bar name
BARITEMNAME
Menu bar item name
DISPLAYONLY
Whether access is display-only
AUTHORIZEDACTIONS
Bitmask of authorized actions
PSMENUITEM — Menu Item Details
Used via a parent-child join with PSAUTHITEM to validate that authorization entries correspond to real menu items. Only PSAUTHITEM entries matching a PSMENUITEM record are counted.
Field
Description
MENUNAME
Menu name (join key)
BARNAME
Menu bar name (join key)
ITEMNAME
Item name (joins to BARITEMNAME)
PNLGRPNAME
Component name
MARKET
Market code
ITEMLABEL
Display label
Data Flow
1. Fetch ALL permission lists from PSCLASSDEFN
via SearchPermissionLists (batches of 300)
|
v
2. For EACH permission list:
Query PSAUTHITEM joined with PSMENUITEM
via GetMenuAuthorizations (pages of 100)
Count total matching entries
|
v
3. Filter: keep only permission lists where
menu auth count >= minMenuCount (default 50)
|
v
4. Sort results by menu auth count (descending)
|
v
5. Generate Markdown report with summary table
Report Output
The generated report contains:
Header with database name, generation timestamp, and threshold value
Summary showing total permission lists analyzed and count flagged
Flagged Permission Lists table with columns:
Permission List (CLASSID)
Description (truncated to 50 characters)
Menu Auth Count
Last Updated By (operator ID)
Last Updated (timestamp)
Recommendations section with remediation guidance
Parameters
Parameter
Default
Description
minMenuCount
50
Minimum number of menu authorizations to flag a permission list
Interpreting Results
High counts (200+): These permission lists likely grant access to a very large portion of the application. They are often “admin” or “superuser” lists and should be reviewed to ensure they are only assigned to appropriate roles.
Moderate counts (50-200): May indicate permission lists that have grown over time. Consider whether they can be split into more focused lists.
Last Updated By: If the operator is not a known security administrator, investigate whether the change was authorized.
Recommendations
Review flagged permission lists for excessive access
Consider splitting broad permission lists into more focused, role-specific lists
Verify that the “Last Updated By” operator is authorized to make security changes
8.1.2 - Nodes with No Password
This report identifies active PeopleSoft message nodes that have no authentication configured or have authentication enabled but no passwords set.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies active PeopleSoft message nodes that have no authentication configured or have authentication enabled but no passwords set. Anything on the network can post messages to these nodes.
What It Detects
The report categorizes problem nodes into three severity levels:
CRITICAL — Active Nodes with No Authentication
Active nodes where AUTHOPTN = 'N' (None). Any external system can communicate with these nodes without providing any credentials.
WARNING — Active Nodes with Auth but No Passwords
Active nodes that have an authentication option configured (AUTHOPTN is P, C, or T) but neither the internal password (IBPASSWORD) nor external password (IBEXTERNALPWD) fields contain a value.
INFO — Inactive Nodes with No Authentication
Nodes that are currently inactive (ACTIVE_NODE = '0') but have no authentication. While not an immediate risk, these would become vulnerable if reactivated.
Table Queried
PSMSGNODEDEFN — Message Node Definitions
The primary record for PeopleSoft Integration Broker message nodes.
Field
Description
Values
MSGNODENAME
Node name (primary key)
ACTIVE_NODE
Whether the node is active
1 = Active, 0 = Inactive
AUTHOPTN
Authentication option
N = None, P = Password, C = Certificate, T = Token
IBPASSWORD
Internal password
Non-empty means password is set
IBEXTERNALPWD
External password
Non-empty means password is set
USERID
PeopleSoft user ID associated with the node
CONNID
Connector ID
e.g., HTTPTARGET, JMSTARGET
NODE_TYPE
Node type
DESCR
Description
LASTUPDOPRID
Last updated by operator
LASTUPDDTTM
Last updated timestamp
Data Flow
1. Fetch ALL message nodes from PSMSGNODEDEFN
via SearchNodes (batches of 300)
|
v
2. Categorize each node:
- Is it active? (ACTIVE_NODE == "1")
- What is its auth option? (AUTHOPTN)
- Does it have any password? (IBPASSWORD or IBEXTERNALPWD)
|
v
3. Sort into three buckets:
CRITICAL: Active + AuthOptn == "N"
WARNING: Active + AuthOptn != "N" + no passwords
INFO: Inactive + AuthOptn == "N"
|
v
4. Generate Markdown report grouped by severity
Categorization Logic
The report uses these helper methods on each node record:
Method
Logic
IsActive()
Returns true if ACTIVE_NODE == "1"
HasInternalPassword()
Returns true if IBPASSWORD is non-empty
HasExternalPassword()
Returns true if IBEXTERNALPWD is non-empty
HasAnyPassword()
Returns true if either internal or external password is set
Report Output
The generated report contains:
Header with database name and generation timestamp
Summary with total node counts, active count, and counts per severity category
CRITICAL section (if any): Table with node name, description, node type, connector, user ID, last updated by/when
WARNING section (if any): Table with node name, description, auth option label, internal/external password status (Set/Not Set), user ID, last updated
INFO section (if any): Table with inactive node name, description, node type, last updated by/when
Recommendations based on which severity categories have findings
Parameters
This report has no configurable parameters.
Interpreting Results
CRITICAL findings require immediate action. Active nodes with no authentication mean any system on the network can send messages without credentials.
WARNING findings should be investigated. Authentication is configured but credentials may not be properly set, rendering the authentication ineffective.
INFO findings are lower priority but represent latent risk. If these nodes are ever reactivated, they would immediately become vulnerable.
Authentication Option Reference
Value
Label
Description
N
None
No authentication required
P
Password
Password-based authentication
C
Certificate
Certificate-based authentication
T
Token
Token-based authentication
Recommendations
Immediately configure authentication on active nodes with AUTHOPTN='N'
Set AUTHOPTN to P (Password) or C (Certificate) and configure credentials
Set internal or external passwords on nodes that have auth enabled but no credentials
8.1.3 - Stale Password Audit
This report identifies unlocked PeopleSoft user accounts whose passwords have not been changed within a configurable number of days.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies unlocked PeopleSoft user accounts whose passwords have not been changed within a configurable number of days. External auditors will ask. SSO accounts are automatically excluded, so the list is users who still have a real PeopleSoft password.
What It Detects
The report categorizes stale password accounts into three severity levels based on how long the password has been unchanged:
CRITICAL — Password Not Changed in Over 1 Year
Unlocked accounts where the password has not been changed in over 365 days. These represent the highest risk and should be addressed immediately.
WARNING — Password Not Changed in Over 180 Days
Unlocked accounts where the password is between 180 and 365 days old.
INFO — Password Exceeds Configured Threshold
Unlocked accounts where the password exceeds the configured threshold (default 90 days) but is less than 180 days old.
The report also separately identifies:
No Password Change Date Recorded. Unlocked accounts with no recorded LASTPSWDCHANGE value (may be migrated or misconfigured)
SSO users (accounts with no PeopleSoft password set) are automatically excluded from this report.
Table Queried
PSOPRDEFN — Operator Definitions (User Accounts)
The primary record for PeopleSoft user accounts.
Field
Description
Values
OPRID
User ID (primary key)
OPRDEFNDESC
User description/name
LASTPSWDCHANGE
Date of last password change
Date format
LASTSIGNONDTTM
Date/time of last sign-on
Datetime format
ACCTLOCK
Account lock status
0 = Active, 1 = Locked
PTOPERPSWDV2
Password hash
Non-empty means password is set (SSO users have no password)
OPRCLASS
Primary permission list
Data Flow
1. Fetch ALL users from PSOPRDEFN
via SearchUsers (batches of 300)
|
v
2. Filter:
- Skip locked accounts (ACCTLOCK = 1)
- Skip SSO users (no password set)
|
v
3. Parse LASTPSWDCHANGE date and compute days since change
|
v
4. Categorize into severity buckets:
CRITICAL: > 365 days since password change
WARNING: > 180 days
INFO: > staleDays threshold (default 90)
Plus: No change date recorded
|
v
5. Sort each category by days since change (oldest first)
|
v
6. Generate Markdown report grouped by severity
Parameters
Parameter
Default
Description
staleDays
90
Number of days after which a password is considered stale
Report Output
The generated report contains:
Header with database name, generation timestamp, and threshold parameter
Summary with total user counts, unlocked count, and counts per severity category
CRITICAL section (if any): Table with user ID (linked), description, last password change date, days since change, last sign-on, permission list
WARNING section (if any): Same table format
INFO section (if any): Same table format
No Password Change Date section (if any): Table with user ID, description, last sign-on, permission list
Recommendations based on which categories have findings
Interpreting Results
CRITICAL findings require immediate action. Passwords unchanged for over a year are a significant security risk, especially if the accounts are actively used (check the Last Sign-on column).
WARNING findings should be scheduled for remediation. These accounts are approaching a year without a password change.
INFO findings indicate policy non-compliance. The accounts exceed your configured threshold but are not yet at the warning level.
No Password Change Date accounts are often migrated accounts. Verify they are legitimate and consider requiring a password reset.
SSO users (no PeopleSoft password set) are automatically excluded from this report.
Investigate accounts with no password change date — these may need manual password resets.
8.1.4 - User Full Access Report
This report generates a consolidated view of everything a single PeopleSoft user can access.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Report ID:security-user-accessCategory: Security
Parameters:oprid (required) — the PeopleSoft User ID to audit
Purpose
This report generates a consolidated view of everything a single PeopleSoft user can access. It expands all roles and permission lists to show the full scope of a user’s security profile in one document. This is useful for security audits, access reviews, onboarding/offboarding verification, and compliance reporting.
What It Covers
The report walks the full PeopleSoft security hierarchy for the specified user:
User Details. Account status, authentication method, direct permission list assignments
Roles. All roles assigned to the user (including dynamic roles)
Permission Lists. Unique permission lists derived from assigned roles, with a reverse map showing which roles grant each
PeopleTools Access. Client tool access (Application Designer, Data Mover, etc.)
Menu/Component Access. All menu authorizations grouped by menu, showing components and display-only status
Service Operations. All authorized Integration Broker service operations
Component Interfaces. All authorized component interfaces
Process Groups. Authorized process scheduler groups
Query Tree / Row-Level Security. Accessible records via query tree security
Tables Queried
Table
Purpose
PSOPRDEFN
User definition and account details
PSROLEUSER
User-to-role assignments
PSROLECLASS
Role-to-permission-list mapping
PSCLASSDEFN
Permission list definitions
PSAUTHITEM + PSMENUITEM
Menu/component authorizations
PSAUTHWS
Service operation authorizations
PSAUTHBUSCOMP
Component interface authorizations
PSAUTHPRCS
Process group authorizations
SCRTY_ACC_GRP
Query tree security access groups
PSTREENODE
Query tree node hierarchy
Data Flow
1. Fetch user details from PSOPRDEFN
|
v
2. Fetch all roles from PSROLEUSER
|
v
3. Batch-fetch permission lists for all roles
from PSROLECLASS
|
v
4. Collect unique permission list ClassIDs
|
v
5. For ALL unique ClassIDs, fetch:
- PeopleTools access (PSAUTHITEM special entries)
- Menu authorizations (PSAUTHITEM + PSMENUITEM)
- Service operation auths (PSAUTHWS)
- Component interface auths (PSAUTHBUSCOMP)
- Process group auths (PSAUTHPRCS)
- Query tree access groups (SCRTY_ACC_GRP)
|
v
6. For query trees: walk tree hierarchy to
resolve accessible leaf records
|
v
7. Generate consolidated Markdown report
How to Run
This report can be launched in two ways:
From the User Detail Page: Navigate to any user’s detail page and click the Run Full Access Report button in the right sidebar. The report automatically uses the current user and database.
From the Reports Page: Go to Reports > Run New Report > User Full Access Report. Click Go to Users to search for a user, then run it from the user’s detail page.
Report Output
The generated report contains:
Summary table with counts for each access category
User Details with account status, authentication, and direct permission lists
Roles table with dynamic assignment indicators
Permission Lists table showing which roles grant each permission list
PeopleTools Access table showing Yes/No for each client tool
Menu/Component Access grouped by menu name, with component links, labels, and display-only flags
Service Operations table with operation and permission list links
Component Interfaces table with interface and permission list links
Process Groups table listing authorized process groups
Query Tree tables showing accessible records with tree and access group context
All object names in the report are linked back to their detail pages in psLens for easy navigation.
Interpreting Results
Large number of roles: Users with many roles may have accumulated access over time. Review whether all roles are still needed.
Overlapping permission lists: Multiple roles may grant the same permission list. While not harmful, it can make access reviews harder.
PeopleTools access: Application Designer, Data Mover, and Object Security access should be limited to developers and security administrators.
Display-only flags: Components marked as display-only mean the user can view but not modify data through those pages.
Process groups: Verify that users only have access to process groups relevant to their job function.
8.1.5 - Dangerous Permissions Audit
This report identifies permission lists that grant access to dangerous capabilities in PeopleSoft.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies permission lists that grant access to dangerous capabilities in PeopleSoft. Each of the eight checks is a known attack path: SOAP-to-CI lets a permission-list holder call any Component Interface without a dedicated service operation, USERPROFILES lets them mint new accounts, IB_NODE lets them point a node at attacker-controlled infrastructure. Each category is assigned a severity level (CRITICAL or HIGH) to help prioritize remediation.
What It Checks
The report audits 8 categories of dangerous access:
CRITICAL Severity
Category
Menu/Bar Item
Risk
SOAP to CI (WEBLIB_SOAPTOCI)
MENUNAME = 'WEBLIB_SOAPTOCI'
Allows programmatic access to Component Interfaces via SOAP without dedicated service operations
User Profile Management
MENUNAME = 'MAINTAIN_SECURITY', bar items: USERPROFILES, USER_SAVEAS, USERMAINT_DIST (non-display-only)
Ability to create, modify, or delete user profiles — the highest-level security object
Node Configuration
MENUNAME = 'IB_CONFIGURE', bar item: IB_NODE (non-display-only)
Ability to define or modify Integration Broker nodes, including authentication credentials
HIGH Severity
Category
Menu/Bar Item
Risk
WSDL Generation (WEBLIB_MSGWSDL)
MENUNAME = 'WEBLIB_MSGWSDL'
Can expose the structure and endpoints of web services
Role Management
MENUNAME = 'MAINTAIN_SECURITY', bar items: ROLEMAINT, ROLESAVEAS (non-display-only)
Ability to create, modify, or delete roles, controlling permission assignments
Permission List Purge
MENUNAME = 'MAINTAIN_SECURITY', bar items: PURGE_PERMLIST, PURGE_ROLEDEFN, PURGE_USR_PROFILE (non-display-only)
Ability to purge permission lists, roles, or user profiles
URL Definitions Management
MENUNAME = 'MAINTAIN_SECURITY', bar item: URL_MAINTENANCE (non-display-only)
Ability to create or modify URL definitions for redirects or external integrations
Process Type Definitions
MENUNAME = 'PROCESSMONITOR', bar item: PRCSTYPE (non-display-only)
Ability to modify process type definitions controlling batch process execution
Table Queried
PSAUTHITEM — Authorization Items
Queried once per category with the specific WHERE clause for that check.
Field
Description
CLASSID
Permission list that has this access
MENUNAME
Menu name being authorized
BARITEMNAME
Menu bar item name
DISPLAYONLY
Display-only flag (0 = full access, 1 = display only)
PSROLECLASS — Role/Permission List Assignments
Queried per permission list found, via GetPermissionListRoles.
Field
Description
CLASSID
Permission list
ROLENAME
Role that includes this permission list
PSOPRALIASTYPE / PSOPRDEFN — User Counts
Queried in batch via GetUnlockedUserCountForRoles to count unlocked users per role.
Data Flow
1. For each of 8 dangerous capability categories:
|
v
2. Query PSAUTHITEM with category-specific WHERE clause
-> Extract unique permission lists (CLASSID)
|
v
3. For each permission list found:
-> Fetch assigned roles via PSROLECLASS
|
v
4. Batch query unlocked user counts for all roles
|
v
5. Sort findings by total unlocked user count (descending)
|
v
6. Generate per-category section with severity badge,
description, and permission list table
|
v
7. Generate summary and recommendations
Parameters
This report has no configurable parameters.
Report Output
The generated report contains:
Header with database name and generation timestamp
Per-category sections (8 total), each with:
Severity badge (CRITICAL or HIGH)
Description of the dangerous capability
Count of permission lists with this access
Table with: Permission List (linked), Roles, Unlocked User count
Or “No findings” if no permission lists have this access
Summary with total categories checked and total permission lists found
Recommendations for each category
Interpreting Results
CRITICAL findings should be reviewed immediately. SOAP-to-CI access, user profile management, and node configuration can all be used for privilege escalation or unauthorized data access.
HIGH findings should be scheduled for remediation. These capabilities are security-sensitive but may have legitimate use cases in limited quantities.
Permission lists with no roles assigned may be orphaned but should still be reviewed — they could be assigned in the future.
High unlocked user counts indicate broad exposure to the dangerous capability and should be prioritized for remediation.
Display-only access is excluded. The report only flags non-display-only (DISPLAYONLY = 0) access for menu-based checks, so findings represent actual write/execute capability.
Recommendations
Remove WEBLIB_SOAPTOCI access in production environments unless absolutely required for integration — use dedicated service operations instead
Restrict WSDL generation to development environments only; in production, serve static WSDL files
Limit user profile management to a small number of designated security administrators
Implement change management processes for role and permission list modifications
Restrict purge operations to emergency use only and require approval workflows
Audit node configuration access regularly, as nodes contain authentication credentials
8.1.6 - SOAP to CI Access Audit
‘SOAP to CI’ is a powerful tool that allows using excel or any web client to interact with PeopleSoft Component Interfaces via SOAP web services.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
“SOAP to CI” is a powerful tool that allows using excel or any web client to interact with PeopleSoft Component Interfaces via SOAP web services. However, this capability also introduces significant security risks if not properly controlled, as it can allow users to programmatically read or write data in the application database. The number of users with access to this WebLib should be tightly controlled and regularly audited.
The SOAP to Component Interface Access Audit report identifies all PeopleSoft users (OPRIDs) who have access to the SOAP-to-CI WebLib (WEBLIB_SOAPTOCI). This WebLib allows programmatic data loading into PeopleSoft using standard Component Interface Web Services (acting as the endpoint for Excel-to-CI and custom integrations like psDataLoader).
For each identified user, the report details:
The security paths (Roles and Permission Lists) granting WebLib access.
The specific Component Interfaces they are authorized to access and execute, and which Roles and Permission Lists grant that CI access.
This report is critical for security audits to ensure that only authorized integration accounts or administrators possess programmatic write access to the application database.
Tables Queried
PSAUTHITEM — WebLib Authorizations
Used to find permission lists that grant access to WEBLIB_SOAPTOCI.
Field
Description
Filter
CLASSID
Permission list name
MENUNAME
WebLib name
MENUNAME = 'WEBLIB_SOAPTOCI'
PSROLECLASS — Role to Permission List Mapping
Used to trace permission lists back to roles.
Field
Description
CLASSID
Permission list
ROLENAME
Role assigning the permission list
PSROLEUSER — User to Role Mapping
Used to identify users assigned to the roles that grant Weblib access, and to map all roles assigned to those users.
Field
Description
ROLEUSER
User ID (OPRID)
ROLENAME
Assigned role
PSOPRDEFN — Operator Definitions
Used to identify users who get direct access via their Primary Permission List (OPRCLASS), and to retrieve user account lock status and descriptions.
Used to trace all Component Interface authorizations for the permission lists assigned to the identified users.
Field
Description
CLASSID
Permission list
BCNAME
Component Interface name
BCMETHOD
Component Interface method
Data Flow
1. Query PSAUTHITEM to find all permission lists (CLASSID) authorizing WEBLIB_SOAPTOCI
|
v
2. Query PSROLECLASS to trace those permission lists back to Roles
|
v
3. Query PSROLEUSER and PSOPRDEFN to identify all users (OPRID) with:
- Assignment to those Roles
- Direct Primary Permission List (OPRCLASS) granting access
|
v
4. Fetch user details (description, lock status) for all identified users
|
v
5. Fetch all Roles and Permission Lists assigned to those users
|
v
6. Fetch all Component Interface (CI) authorizations (PSAUTHBUSCOMP) for those permission lists
|
v
7. For each user, map their SOAP-to-CI access paths and all authorized Component Interfaces
|
v
8. Sort users (active first, then by ID) and generate the Markdown report
Parameters
This report has no configurable parameters.
Report Output
The generated report contains:
Header with database name and generation timestamp.
Summary statistics (total users, active vs. locked, unique roles, unique permission lists).
WebLib Access Path Summary Table listing each Role-Permission List pair granting SOAP-to-CI access and the number of active users with that assignment.
User Access Details Section detailing each user:
User ID (linked to detail page) and Description.
Account lock status (Active/Unlocked vs. Locked 🔒).
A table of Accessible Component Interfaces detailing which Role and Permission List grants access to each specific Component Interface.
Remediation Recommendations to secure your environments.
Interpreting Results
Unlocked users with SOAP-to-CI access must be verified. Programmatic SOAP-to-CI access should be reserved for integration service accounts or system administrators. Standard business users should not have access to this WebLib.
Active users with no Component Interface access have WebLib access but cannot interact with any business objects. While they present less immediate risk, their WebLib access should still be revoked to adhere to the principle of least privilege.
Locked users are flagged with Locked 🔒. While they cannot authenticate, their security definitions should still be cleaned up if their access is no longer required.
Primary Permission List grants (indicated by Primary Permission List instead of a Role) should be avoided. Best practice is to assign Weblib access through Roles.
Recommendations
Restrict WEBLIB_SOAPTOCI: Remove this WebLib access from any roles assigned to standard business users. Ensure it is only assigned to dedicated integration/service accounts.
Implement Least Privilege for CIs: Verify that service accounts only have access to the specific Component Interfaces (CIs) required for their integration. Remove broad or administrative permission lists that grant access to unnecessary CIs.
Lock Stale Accounts: Ensure that any old, inactive, or deprecated integration accounts are explicitly locked in PSOPRDEFN.
8.1.7 - SSO Bypass Password Audit
This page documents the SSO Bypass Password Audit report, which identifies native PeopleSoft user passwords stored in the PSOPRDEFN table.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This page documents the SSO Bypass Password Audit report, which identifies native PeopleSoft user passwords stored in the PSOPRDEFN table.
Purpose
Environments using Single Sign-On (SSO) should not store native passwords in the PeopleSoft database. If PSOPRDEFN passwords exist, users can bypass SSO controls—including Multi-Factor Authentication (MFA)—by accessing PeopleSoft backdoor login paths (such as ?cmd=login query parameters or web service endpoints).
To prevent backdoor access, the fields OPERPSWD, PTOPERPSWDV2, and OPERPSWDSALT must be cleared to a single space, since PeopleSoft does not support database nulls.
Important: There are types of users that need to maintain their PeopleSoft password for various reasons that this report will flag.
Anyone who needs 2-tier PeopleTools Access
Developers
Administrators
Special Accounts
App Server Accounts
API User Accounts for External Integrations
SOAP-to-CI Users (maybe)
For any accounts that you know should have a password, you can enter rolename for accounts to avoid. One idea here is to create a new role like X_CAN_HAVE_PS_PASSWORD (replace X_ With your desired prefix) so you can clearly mark these special users and everyone else should have their passwords cleared.
What It Detects
The report checks the PSOPRDEFN table for any row where OPERPSWD, PTOPERPSWDV2, or OPERPSWDSALT is not a single space. Results are grouped into two sections based on account status:
Active Users with Local Passwords: High risk. These accounts can be logged into directly.
Locked Users with Local Passwords: Low risk. These accounts are locked, but their passwords should still be cleared.
Table Queried
PSOPRDEFN
The primary table containing PeopleSoft operator definitions.
Field
Description
Values
OPRID
User ID (primary key)
OPRDEFNDESC
User description
ACCTLOCK
Account lock status
1 = Locked, 0 = Active
LASTSIGNONDTTM
Last sign-on date and time
OPERPSWD
Legacy password hash
PTOPERPSWDV2
Password hash (V2)
OPERPSWDSALT
Password salt
PSROLEDEFN
Used to validate that the entered excluded roles are real roles.
PSROLEUSER
Used via a subquery to exclude users assigned to the specified excluded roles.
Data Flow
1. If excludeRoles is provided, validate each role against PSROLEDEFN
|
v
2. Query PSOPRDEFN for rows where OPERPSWD, PTOPERPSWDV2, or OPERPSWDSALT is not ' ' (filtering out users assigned to excluded roles via a PSROLEUSER subquery)
|
v
3. Segment users based on ACCTLOCK (0 = Active, 1 = Locked)
|
v
4. Compile a bulk SQL update script containing individual UPDATE statements for all affected users
Report Output
The report outputs:
A summary of active and locked users containing passwords.
Tables listing the user ID, description, last sign-on date, and active password fields.
A bulk remediation SQL script with individual update queries.
Parameters
excludeRoles: Comma-separated list of role names to exclude from the audit (optional). If specified, any user assigned to any of these roles is excluded from the report. The report validates that all entered role names exist in PSROLEDEFN.
8.1.8 - PeopleTools Access Audit
Special PeopleTools access (Application Designer, Data Mover, Object Security, Query, Import Manager, 2-Tier Client) is granted on the PeopleTools …
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Special PeopleTools access (Application Designer, Data Mover, Object Security, Query, Import Manager, 2-Tier Client) is granted on the PeopleTools tab of a permission list and recorded in PSAUTHITEM. This report lists every user who holds any of that access and the path that grants it: permission list to role to user.
What It Detects
For each PeopleTools application, the permission lists that grant it, the roles that carry those permission lists, and the users in those roles. Each grant is marked Full (edit) or Read-only based on PSAUTHITEM.DISPLAYONLY. Each user is marked Active or Locked from PSOPRDEFN.ACCTLOCK.
The tools tracked are the MENUNAME values PeopleSoft uses for standalone tools access:
PSROLECLASS — which roles include each permission list.
PSROLEUSER — which users hold each role.
PSOPRDEFN — account lock status (ACCTLOCK) and primary permission list (OPRCLASS).
PSOPROBJ — Definition Security grants: permission list to object group, with DISPLAYONLY (edit vs read-only).
PSOBJGROUP — object group membership (which definitions belong to a custom group).
Report Output
Four sections:
Summary — count of permission lists and distinct users per tool, plus the total number of users with any special access.
Access by Tool — each tool with its permission lists (Full or Read-only), descriptions, and the roles that carry them.
Access by User — every in-scope user with their account status, the tools they hold and at what level, a Def. Security column (can they edit definitions), and the permission lists and roles that grant them.
Definition Security (Object Security) — object group grants (PSOPROBJ): which permission lists can edit or read the definitions in each object group, and which users that reaches via primary permission list and roles.
Permission lists, roles, and users link back to their psLens detail pages.
Parameters
Parameter
Default
Description
activeOnly
false
When true, restrict the user sections to unlocked accounts only.
Interpreting Results
Full vs Read-only. Read-only Application Designer access can open and inspect definitions but not save changes. Full access can modify them. Treat Full access in a production database as the higher risk.
Locked users. Locked accounts still hold the grant. They appear so you can audit dormant access that would return if the account is unlocked. Set activeOnly = true to hide them.
Object Security. Access to the Object Security tool lets a user change Definition Security itself, which governs which definitions developers can edit.
Definition Security details
Holding Application Designer access lets a developer open the tool. What definitions they can edit is controlled by Definition Security object groups (PSOBJGROUP) linked to permission lists through PSOPROBJ. The DISPLAYONLY flag on that link is the difference between read-only and edit access.
The delivered PEOPLETOOLS object group holds the system definitions and is read-only by default. An Edit grant on it (DISPLAYONLY = 0) means the permission list can modify delivered PeopleTools objects in Application Designer — a high-privilege grant worth auditing.
The report applies these grants to users through both their primary permission list (PSOPRDEFN.OPRCLASS) and their roles, and labels which path reaches each user. Permission-list-level grants are reported exactly from PSOPROBJ; the user roster is the set reached through those permission lists.
8.2 - Integration Broker
Integration Broker reports for PeopleSoft: service operation audits, node security, routing analysis, and volume reporting.
Eight reports against the PSOPERATION, PSMSGNODEDEFN, PSIBRTNGDEFN, and IB log tables. Use them to find unauthenticated nodes, routings open to ~~ANY~~, sync ops running without logging, and dead operations no one bothered to deactivate.
Shows IB message volume for a date range broken down by async operations, pub/sub contracts, and logged sync operations
8.2.1 - Web Service Operation Access Audit
This report provides a consolidated view of which PeopleSoft service operations (web services) are accessible, through which permission lists and r…
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report provides a consolidated view of which PeopleSoft service operations (web services) are accessible, through which permission lists and roles, and how many active (unlocked) users have access through each role. It answers the question: “Who can call our web services and through what security chain?”
What It Captures
The report traces the full security chain for every service operation authorization:
Service Operation — The web service endpoint (from PSAUTHWS)
Permission List — The permission list granting access to that operation
Role — Each role that includes that permission list
Unlocked User Count — The number of users with that role whose accounts are not locked
Tables Queried
PSAUTHWS — Web Service Authorizations
Maps service operations to the permission lists that grant access.
Field
Description
IB_OPERATIONNAME
Service operation name (key)
CLASSID
Permission list granting access
PSROLECLASS — Role to Permission List Mapping
Maps roles to their assigned permission lists.
Field
Description
ROLENAME
Role name (key)
CLASSID
Permission list (key)
PSROLEUSER — Role to User Mapping
Maps roles to users, filtered to unlocked accounts only.
Field
Description
ROLENAME
Role name (key)
ROLEUSER
User OPRID (key)
PSOPRDEFN — User Definitions
Used as a subquery filter to count only unlocked users.
Field
Description
OPRID
User operator ID (key)
ACCTLOCK
Account lock status (0=unlocked, 1=locked)
Data Flow
1. Bulk fetch ALL PSAUTHWS records (paginated, batches of 300)
-> Build map: Service Operation -> Permission Lists
|
v
2. For each unique Permission List, query PSROLECLASS
-> Build map: Permission List -> Roles
|
v
3. For each unique Role, query PSROLEUSER
with subquery filter: ACCTLOCK = 0 on PSOPRDEFN
-> Build map: Role -> Unlocked User IDs
|
v
4. Group by service operation and sort by unique user count (descending)
-> Generate Markdown report
Report Output
The generated report contains:
Summary with counts of service operations, unique permission lists, and unique roles.
Access Details List grouped by service operation. Each section lists the service operation, its distinct unlocked user count, and a nested bulleted list of its granting permission lists, roles, and the actual active user IDs (truncated at 15).
Sorted by unique user count (descending) to highlight the most widely accessible operations.
Permission lists with no roles show “(No roles assigned)”.
Recommendations for security review.
Interpreting Results
High unlocked user counts on sensitive service operations indicate broad access that may violate least-privilege principles.
Permission lists with “(No roles assigned)” are assigned to service operations but not included in any role. They may be orphaned or misconfigured.
Roles with 0 unlocked users grant web service access but have no active users. They are candidates for cleanup.
Operations with multiple permission lists and roles have complex access chains that are difficult to audit manually.
Use Cases
Security audit — Identify which web services have the broadest user access
Least-privilege review — Find operations accessible to more users than expected
Cleanup — Identify permission lists or roles granting web service access with no active users
8.2.2 - IB Node Security Audit
This report audits Integration Broker node user accounts for security issues that go beyond authentication configuration (which is covered by the N…
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report audits Integration Broker node user accounts for security issues that go beyond authentication configuration (which is covered by the Nodes with No Password report). It checks for elevated user privileges on nodes, shared user accounts across multiple nodes, and nodes with no active routings.
What It Detects
CRITICAL — Anonymous Node User Analysis
Checks the ANONYMOUS node’s associated PeopleSoft user account. Flags as HIGH RISK if:
The user account is unlocked (can log into PIA directly)
The user has PeopleTools access (Application Designer, Data Mover, etc.)
The ANONYMOUS node handles unauthenticated IB traffic. Its user should have minimal privileges and a locked account.
WARNING — Shared Node Users
Identifies cases where the same PeopleSoft User ID (OPRID) is configured on multiple active nodes. Each node should have its own distinct service account for:
Audit trail — Knowing which node performed an action
Security isolation — Revoking one node’s access without affecting others
Least privilege — Tailoring permissions per node’s specific needs
WARNING — Active Nodes with No Active Routings
Finds active non-local nodes that have no active routings in PSIBRTNGDEFN. These nodes may be:
Leftover from decommissioned integrations
Candidates for deactivation to reduce attack surface
Covered only by wildcard (~~ANY~~) routings (reported separately)
WARNING — Node Users with PeopleTools Access
Identifies node service accounts whose permission lists grant access to PeopleTools clients (Application Designer, Data Mover, Query, etc.). Node accounts should never need development tool access.
Tables Queried
PSMSGNODEDEFN — Message Node Definitions
Field
Description
Values
MSGNODENAME
Node name (primary key)
ACTIVE_NODE
Whether the node is active
1 = Active, 0 = Inactive
LOCALNODE
Whether this is a local node
1 = Local, 0 = External
USERID
PeopleSoft user ID associated with the node
NODE_TYPE
Node type
PSIBRTNGDEFN — Routing Definitions
Field
Description
Values
SENDERNODENAME
Sending node name
Node name or ~~ANY~~
RECEIVERNODENAME
Receiving node name
EFF_STATUS
Effective status
A = Active, I = Inactive
PSOPRDEFN — User Definitions
Field
Description
Values
OPRID
User ID (primary key)
OPRCLASS
Primary permission list
ACCTLOCK
Account lock status
0 = Unlocked, 1 = Locked
PSAUTHITEM — Menu/Tools Authorizations
Used to check if a permission list grants PeopleTools client access (APPLICATION_DESIGNER, DATA_MOVER, etc.).
Data Flow
1. Fetch ALL message nodes from PSMSGNODEDEFN
(batches of 300)
|
v
2. Fetch ALL active routings from PSIBRTNGDEFN
Build set of node names with active routings
|
v
3. For each unique UserID on active nodes:
Look up user in PSOPRDEFN
|
v
4. For each unique permission list found:
Check PSAUTHITEM for PeopleTools access
|
v
5. Analyze and categorize findings:
- Anonymous node user privileges
- Shared node users (same OPRID on 2+ nodes)
- Active nodes not in routing coverage set
- Node users with PeopleTools access
|
v
6. Generate Markdown report grouped by severity
Interpreting Results
CRITICAL findings on the ANONYMOUS node indicate that unauthenticated IB traffic is processed under a user with elevated privileges. This is a significant security risk.
Shared node users increase blast radius if one account is compromised and make it harder to trace which node performed specific actions.
Nodes with no routings represent unnecessary attack surface. If a node isn’t routing any messages, it should be deactivated.
PeopleTools access on node accounts means a compromised integration could potentially be used to modify PeopleSoft objects.
Recommendations
Lock the ANONYMOUS node user account to prevent direct PIA login
Remove PeopleTools access from node service account permission lists
Create distinct service accounts for each Integration Broker node
Deactivate nodes with no active routings if they are no longer needed
8.2.3 - Active ANY to Local Node Routings
This report identifies Integration Broker routings where the sender node is ANY and the receiver is the default local node.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies Integration Broker routings where the sender node is ~~ANY~~ and the receiver is the default local node. The ~~ANY~~ sender is a wildcard that allows any external node to send messages to the local system for that routing’s operation, bypassing node-specific routing controls.
~~ANY~~ routings are sometimes intentional (e.g., for broadly available services), but if left active without review they let any external node send messages inbound. This report lists which operations are open to inbound messages from any node.
What It Detects
WARNING — Active ~~ANY~~ to Local Node Routings
Active routings in PSIBRTNGDEFN where:
SENDERNODENAME = '~~ANY~~'
RECEIVERNODENAME is the default local node
EFF_STATUS = 'A' (Active)
These routings are currently allowing any external node to send messages inbound.
Used to find inbound routings to the default local node.
Field
Description
Filter
ROUTINGDEFNNAME
Routing definition name
SENDERNODENAME
Sender node
Checked for ~~ANY~~
RECEIVERNODENAME
Receiver node
= {default local node}
EFF_STATUS
Effective status
A = Active, I = Inactive
EFFDT
Effective date
IB_OPERATIONNAME
Service operation name
DESCR
Description
Data Flow
1. Fetch ALL message nodes from PSMSGNODEDEFN
(batches of 300)
|
v
2. Filter for default local nodes:
LOCALNODE = 1 AND LOCALDEFAULTFLG = 'Y'
|
v
3. For each default local node, fetch inbound routings
from PSIBRTNGDEFN where RECEIVERNODENAME = node
|
v
4. Filter for active routings where SENDERNODENAME = '~~ANY~~'
|
v
5. Generate Markdown report with findings
Report Output
The generated report contains:
Header with database name and generation timestamp
Summary with total nodes scanned, default local node name(s), and count of active ~~ANY~~ routings
WARNING section (if any): Table of active ~~ANY~~ routings with routing name, receiver node, linked service operation, and description
Recommendations if active ~~ANY~~ routings are found
Interpreting Results
WARNING findings should be reviewed. Each active ~~ANY~~ routing means any external node can send messages for that operation to the local system. Determine whether this is intentional.
No findings means all inbound routings use explicit sender nodes, which is the most secure configuration.
Recommendations
Review each active ~~ANY~~ routing to determine if a wildcard sender is truly needed
Replace with explicit sender node routings where possible to restrict which nodes can send messages inbound
Deactivate unneeded ~~ANY~~ routings to reduce the attack surface
8.2.4 - Active Service Operations Report
This report lists all fully active service operations — those with at least one active version, at least one active routing, and at least one activ…
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report lists all fully active service operations — those with at least one active version, at least one active routing, and at least one active handler — along with their permission lists that grant access.
The report pulls all service operations with their child records (versions, handlers, routings) in a single paginated hierarchical query, then bulk-fetches PSAUTHWS to map each operation to its permission lists. Operations are filtered to those with at least one active version, routing, and handler before being written to the report. For a system with N service operations and A PSAUTHWS rows, expect roughly N/50 + A/300 API calls. A site with 500 operations and 2000 auth rows runs in about 17 calls.
Report Output
The generated report contains:
Header with database name and generation timestamp
Summary with total operations and count of active operations
Active handlers table (handler name, type, app class path)
Active routings table (routing name, sender, receiver, generated flag)
Permission lists table (linked to permission list detail pages)
Interpreting Results
Operations with no permission lists may be inaccessible or may rely on other authentication mechanisms
Operations with ~~ANY~~ sender routings accept messages from any external node. Review whether this is intentional
Operations with no active handlers may indicate stale configuration
Operations with many permission lists have broad access. Verify this is appropriate
Use Cases
IB inventory — Get a complete list of all active service operations and their configuration
Security review — Identify which operations are accessible and by whom
Cleanup — Find operations with no active handlers or routings that may be candidates for deactivation
8.2.5 - Active Service Operations with No Routings
This report identifies active service operations that have no active routing definitions.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies active service operations that have no active routing definitions. These operations have at least one active version but cannot process any messages because no routing is configured to direct traffic to or from them. Usually this means a half-finished setup or an operation that should have been deactivated when its routings were.
What It Detects
An operation is flagged when:
It has at least one active version (ACTIVE_FLAG = 'A' in PSOPRVERDFN)
It has zero active routings (EFF_STATUS = 'A' in PSIBRTNGDEFN)
The report also shows the count of inactive routings, which helps distinguish between operations that never had routings and those whose routings were intentionally deactivated.
1. Paginate through all PSOPERATION records
(batches of 300)
|
v
2. For each operation, fetch full details
(versions, routings)
|
v
3. Filter to operations with at least one
active version (ACTIVE_FLAG = 'A')
|
v
4. Exclude operations that have any active
routing (EFF_STATUS = 'A')
|
v
5. Generate summary table of flagged operations
Report Output
The generated report contains:
Summary with total operations, active operations, and count flagged with no routings
Flagged operations table with operation name (linked to detail page), service, type, active version count, inactive routing count, and description
Recommendations for remediation actions
Interpreting Results
Operations with zero total routings likely never had routings configured. These may be newly created or inherited operations that were never fully set up
Operations with inactive routings only suggest the routings were intentionally deactivated. Verify whether the operation itself should also be deactivated
Async operations without routings are especially notable since they rely on routings for subscription/publication contracts
Sync operations without routings cannot receive inbound requests
Recommendations
If the operation is needed: Create and activate routing definitions to enable message processing
If the operation is not needed: Inactivate all versions to keep the IB configuration clean
If routings exist but are inactive: Review whether deactivation was intentional or an oversight
8.2.6 - Unauthenticated Node Service Operations
This report identifies active nodes with no authentication configured (AUTHOPTN=‘N’) and then determines which fully-active service operations are …
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies active nodes with no authentication configured (AUTHOPTN='N') and then determines which fully-active service operations are reachable through those nodes. A service operation is considered fully active only when it meets all three criteria: an active version, an active routing, and an active handler.
Any operation reachable through one of these nodes can be invoked without credentials.
What It Captures
For each active node with no authentication:
Node metadata (name, description, user ID)
All fully-active service operations routed through that node
The routing that links the operation to the node
Operation type (REST/HTTP Post, Sync/Async)
Tables Queried
PSMSGNODEDEFN — Message Node Definitions
Paginated to discover all nodes. Filtered to active nodes with AUTHOPTN = 'N'.
1. Paginate through all PSMSGNODEDEFN records
-> Filter to active nodes with AUTHOPTN = 'N'
-> Build set of no-auth node names
|
v
2. Paginate through all PSOPERATION records
(batches of 300)
|
v
3. For each operation, fetch full details
(versions, handlers, routings)
|
v
4. Filter to "fully active" operations:
- At least one active version
- At least one active handler
- At least one active routing
|
v
5. Check if any active routing references
a no-auth node (as sender OR receiver)
|
v
6. Generate report grouped by node
Report Output
The generated report contains:
Header with database name and generation timestamp
Summary with counts of no-auth nodes, total operations checked, and matching operations
No-Auth Nodes table listing each unauthenticated node with its user ID and count of reachable operations
Per-node sections with a table of all service operations accessible through that node, including operation type and routing name
Recommendations for remediation
Interpreting Results
Nodes with many accessible operations are higher risk and should be prioritized for remediation
The User ID on each node indicates what PeopleSoft user context is used for operations through that node. Review its privileges
REST operations are typically more easily exploitable from external systems than HTTP Post (SOAP) operations
If no nodes are found with AUTHOPTN='N', the report exits early with a clean result
Recommendations
Configure authentication (AUTHOPTN = 'P' or 'C') on all active nodes
Set internal and/or external passwords on nodes that require password authentication
Review the PeopleSoft user ID associated with each no-auth node for excessive privileges
Consider deactivating routings that should not be accessible without authentication
This report identifies active synchronous service operations that have active routings where message detail logging is disabled.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report identifies active synchronous service operations that have active routings where message detail logging is disabled. When logging is off on a sync routing, transaction data is not recorded in the IB logs, making it impossible to troubleshoot failures or audit message traffic.
What It Detects
A routing is flagged when all three conditions are met:
The service operation is synchronous (RTNGTYPE = 'S' in PSOPERATION)
It has at least one active version (ACTIVE_FLAG = 'A' in PSOPRVERDFN)
An active routing (EFF_STATUS = 'A' in PSIBRTNGDEFN) has logging disabled (LOGMSGDTLFLG = '2')
Tables Queried
PSOPERATION — Service Operation Definitions
Paginated to discover all operations, filtered to synchronous only.
Message detail logging flag (0=Header, 1=Header+Detail, 2=No Logging)
Flagged when '2' (No Logging)
Data Flow
1. Paginate through all PSOPERATION records
(batches of 300)
|
v
2. For each operation, fetch full details
(versions, routings)
|
v
3. Filter to synchronous operations with at
least one active version
|
v
4. Check each active routing for LOGMSGDTLFLG
Flag routings where value is '2' (No Logging)
|
v
5. Generate table of flagged routings
Report Output
The generated report contains:
Summary with total operations, active sync operations, sync with active routings, and count of routings without logging
Flagged routings table with operation name (linked to detail page), service, routing name, sender node, receiver node, and description
Recommendations for enabling logging
Interpreting Results
High count of flagged routings may indicate a blanket policy of disabling logging. Consider enabling it at least for critical operations
Generated routings (auto-created by PeopleSoft) often have logging disabled by default. Review whether these carry important traffic
Custom routings without logging suggest an intentional decision that should be validated with the integration team
Recommendations
Enable logging: In PeopleTools > Integration Broker > Integration Setup > Routings, set the “Log Detail” flag to “Header Only” (0) or “Header & Detail” (1) for each flagged routing
Performance consideration: Header-only logging has trivial overhead. Header+Detail can balloon the IB log tables on high-volume routings — turn it on for the ones you actually want to troubleshoot
Review periodically: Logging may be intentionally disabled during high-volume batch processing. Re-enable after batch windows complete
8.2.8 - Daily IB Volume/Usage Report
This report shows Integration Broker message volume for a configurable date range. It breaks down traffic into four categories:
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report shows Integration Broker message volume for a configurable date range. It breaks down traffic into four categories:
Async Operations — publication headers (PSAPMSGPUBHDR), the top-level async message record
Publication Contracts — per-subscriber delivery records (PSAPMSGPUBCON)
Subscription Contracts — subscription handler execution records (PSAPMSGSUBCON)
Synchronous Operations — logged sync transactions (PSIBLOGHDR). Only operations with logging enabled appear here
Each category shows counts grouped by operation name and status (Done, Error, New, etc.), sorted by total volume descending.
Parameters
Parameter
Default
Description
from_date
Today (YYYY-MM-DD)
Start of the date range (inclusive)
to_date
Today (YYYY-MM-DD)
End of the date range (inclusive)
Leave both parameters blank to report on today’s traffic. Set a range such as from_date=2026-01-01 and to_date=2026-01-31 for a monthly view.
Tables Queried
PSAPMSGPUBHDR — Async Operation Headers
The master record for each async IB message (one row per publication).
Field
Description
Filter
IB_OPERATIONNAME
Service operation name
Grouped by
STATUSSTRING
Message status (DONE, ERROR, NEW, etc.)
Grouped by
CREATEDTTM
When the record was created
Date range filter
PSAPMSGPUBCON — Publication Contracts
One row per subscriber for each async publication.
Field
Description
Filter
IB_OPERATIONNAME
Service operation name
Grouped by
STATUSSTRING
Contract status
Grouped by
CREATEDTTM
When the record was created
Date range filter
PSAPMSGSUBCON — Subscription Contracts
One row per subscription handler execution.
Field
Description
Filter
IB_OPERATIONNAME
Service operation name
Grouped by
STATUSSTRING
Contract status
Grouped by
CREATEDTTM
When the record was created
Date range filter
PSIBLOGHDR — Sync Operation Log Headers
Logged synchronous transaction records. Only populated when message detail logging is enabled on the routing.
Field
Description
Filter
IB_OPERATIONNAME
Service operation name
Grouped by
STATUSSTRING
Transaction status
Grouped by
PUBLISHTIMESTAMP
When the transaction was processed
Date range filter
Data Flow
1. Fetch async operation summary (PSAPMSGPUBHDR)
GROUP BY IB_OPERATIONNAME, STATUSSTRING
|
v
2. Fetch publication contract summary (PSAPMSGPUBCON)
GROUP BY IB_OPERATIONNAME, STATUSSTRING
|
v
3. Fetch subscription contract summary (PSAPMSGSUBCON)
GROUP BY IB_OPERATIONNAME, STATUSSTRING
|
v
4. Fetch sync operation summary (PSIBLOGHDR)
GROUP BY IB_OPERATIONNAME, STATUSSTRING
|
v
5. Pivot each dataset into a per-operation table
with status columns, sorted by total descending
Report Output
The generated report contains:
Summary table with total message counts for each of the four categories
Async Operations table — one row per operation, columns for each status (Done, Error, New, etc.) plus Total
Publication Contracts table — same format
Subscription Contracts table — same format
Synchronous Operations table — same format, with a note that only logging-enabled operations appear
Interpreting Results
Async Operations
Done — successfully processed and delivered
Error — failed; check the IB Monitor for details
New — queued but not yet processed (may indicate a stuck dispatcher)
A high Error count relative to Done signals a systemic integration problem. A high New count with no decrease over time indicates the IB dispatcher may be stopped.
Publication vs Subscription Contracts
Each async publication spawns one publication contract (PSAPMSGPUBCON) per subscribing node
Compare day-over-day volumes — sudden drops may indicate a sending system stopped, not just low traffic
8.3 - Process Scheduler
Process Scheduler reports for PeopleSoft: recurring process exports, critical process monitoring, and batch schedule analysis.
Three reports against PSPRCSRQST and PRCSRECUR: monitor/alert on recurring schedules, diff a current schedule against a saved baseline, and verify named processes have actually run in the last N hours.
Compares the current batch schedule against a previously exported baseline to detect added, removed, or changed processes
8.3.1 - Recurring Processes Schedule Comparison
This report compares the current batch schedule against a previously exported baseline from the ‘Recurring Schedule & Drift Monitoring’ report.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Report ID:recurring-processes-compareCategory: Process Scheduler
Purpose
This report compares the current batch schedule against a previously exported baseline from the “Recurring Schedule & Drift Monitoring” report. It identifies processes that have been added, removed, or changed since the baseline was captured, helping you detect unintended schedule modifications after migrations, upgrades, or configuration changes.
How It Works
The report requires a baseline — a previously run “Recurring Schedule & Drift Monitoring” report. It parses the baseline report’s markdown table to extract the saved schedule, then fetches the current recurring processes from the database and compares the two sets.
Comparison Logic
Processes are matched by a composite key of:
Process Name (PRCSNAME)
Process Type (PRCSTYPE)
Operator ID (OPRID)
Recurrence Name (RECURNAME)
The report detects three types of differences:
Status
Meaning
+ Added
Process exists in current schedule but not in baseline
- Removed
Process was in baseline but is no longer queued
~ Changed
Process exists in both but the server assignment has changed
Table Queried
PSPRCSRQST — Process Request Table
Fetched via GetQueuedRecurringProcesses (batches of 300).
Field
Description
PRCSNAME
Process name
PRCSTYPE
Process type (e.g., SQR, Application Engine)
OPRID
Operator ID that owns the schedule
RUNCNTLID
Run control ID
RECURNAME
Recurrence name/schedule
SERVERNAMERUN
Assigned process scheduler server
RUNDTTM
Scheduled run date/time
The baseline data is parsed from the markdown table in the previous “Recurring Schedule & Drift Monitoring” report output — no additional database query is needed for the baseline.
Data Flow
1. Load baseline report output by Run ID
-> Parse markdown table to extract baseline processes
|
v
2. Fetch current recurring processes from PSPRCSRQST
via GetQueuedRecurringProcesses (batches of 300)
|
v
3. Build lookup maps for both baseline and current sets
using composite key: PrcsName|PrcsType|OpRid|RecurName
|
v
4. Compare sets to find:
- Removed: in baseline but not in current
- Added: in current but not in baseline
- Changed: in both but server assignment differs
|
v
5. Generate comparison report with summary and diff table
Parameters
Parameter
Required
Description
baseline_run_id
Yes
Select a previously completed “Recurring Schedule & Drift Monitoring” report to use as the baseline
Select the baseline from the dropdown list. If no baseline runs are found, you must first run the “Recurring Schedule & Drift Monitoring” report.
Report Output
The generated report contains:
Header with database name, generation timestamp, and baseline Run ID
Summary with baseline process count, current process count, and total differences found
Difference breakdown with counts of added, removed, and changed processes
Recommendations for handling each type of difference
If no differences are found, the report confirms that the current schedule matches the baseline.
Interpreting Results
Removed processes may indicate an intentional change or an accidental deletion during a migration. Verify with the batch schedule owner before dismissing.
Added processes should be documented and reviewed to ensure they follow naming and scheduling standards.
Changed processes (server assignment changes) are common after environment migrations and should be verified to ensure processes are running on the correct scheduler server.
A clean comparison (no differences) confirms that the batch schedule survived a migration or change window intact.
Recommendations
Export a baseline (“Recurring Schedule & Drift Monitoring”) before any major environment change (migration, refresh, upgrade)
Run this comparison report immediately after the change to verify the schedule
Investigate all removed processes — they may need to be re-created manually
For added processes, verify they were intentionally scheduled and follow your naming conventions
For server assignment changes, confirm the target scheduler server is appropriate for the process workload
8.3.2 - Recurring Schedule & Drift Monitoring
This report lists all currently queued recurring batch processes from the PeopleSoft Process Scheduler and acts as the source for schedule drift mo…
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Report ID:recurring-processesCategory: Process Scheduler
Purpose
This report lists all currently queued recurring batch processes from the PeopleSoft Process Scheduler and acts as the source for schedule drift monitoring. When scheduled with the On Change (on_change) notification mode, it automatically alerts on changes (added, removed, or server assignment changes) compared to a baseline run.
It captures the batch schedule configuration so it can be preserved for disaster recovery, environment migrations, or operational documentation.
The report answers: “What recurring processes are currently scheduled, who set them up, with what run control, on what recurrence, and on which server?”
What It Captures
For each queued process with a recurrence assigned:
OPRID. The operator who scheduled the process
RUNCNTLID. The run control ID used
RECURNAME. The recurrence definition controlling the schedule
SERVERNAMERUN. The Process Scheduler server assigned to run it
Process Name and Type. The process definition being executed
Additionally, the report fetches and displays the schedule details for each unique recurrence found (type, days, time window, repeat interval).
Tables Queried
PSPRCSRQST — Process Request Instances
The primary table for process scheduler requests.
Field
Description
Filter
PRCSINSTANCE
Unique process instance number
PRCSNAME
Process definition name
PRCSTYPE
Process type (SQR, AE, COBOL, etc)
OPRID
Operator who scheduled the process
RUNCNTLID
Run control ID
RUNSTATUS
Current run status
Filtered to 5 (Queued)
SERVERNAMERUN
Assigned server
RECURNAME
Recurrence name
Filtered to non-blank
RUNDTTM
Scheduled run date/time
PRCSRECUR — Recurrence Definitions
Looked up for each unique recurrence found to display schedule details.
Field
Description
RECURNAME
Recurrence name (primary key)
RECURDESCR
Description
RECURTYPE
Type: 2=Daily, 4=Weekly, 6=Monthly, 8=Custom
RUN{DAY} flags
Which days of the week to run
BEGINDTTM
Schedule start date/time
ENDDTTM
Schedule end date/time
REPEATRECURRENCE
Repeat interval value
REPEATUNIT
Repeat unit: 0=Minutes, 1=Hours
Data Flow
1. Query PSPRCSRQST where RECURNAME <> ' ' AND RUNSTATUS = 5
Paginate through all results (batches of 300)
|
v
2. Collect unique RECURNAME values
For each, fetch PRCSRECUR via GetRecurrenceByName
|
v
3. Generate Markdown report:
- Summary counts
- Main table of all queued recurring processes
- Recurrence schedule details section
Report Output
The generated report contains:
Header with database name and generation timestamp
Summary with total process count, unique recurrences, unique operators, unique servers
Process Table with Process Name, Type, OPRID, Run Control ID, Recurrence, Server, Run Date/Time
Recurrence Details for each unique recurrence: type, scheduled days, start/end dates, repeat interval, duration
Parameters
This report has no configurable parameters.
Interpreting Results
Each row represents a process request that is currently queued with a recurring schedule
The same process may appear multiple times if scheduled by different operators or with different run controls
If a server column shows “(any)”, the process can run on any available Process Scheduler server
The Recurrence Details section shows how often each schedule runs
Use Cases
Disaster Recovery. Document the batch schedule before a system outage so it can be recreated
Environment Migration. Capture batch schedules before refreshing or migrating an environment
Audit. Review who has scheduled recurring processes and on which servers
Operational Documentation. Maintain a record of the production batch schedule
8.3.3 - Process Run Check
This report verifies that a set of critical batch processes have run successfully within a configurable time window.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Report ID:process-run-checkCategory: Process Scheduler
Purpose
This report verifies that a set of critical batch processes have run successfully within a configurable time window. It checks each process for a recent successful completion and flags any that are missing or have not completed successfully.
The report answers: “Have my critical processes run successfully in the last N hours?”
Parameters
Parameter
Default
Description
processes
(none)
Comma-separated list of process names to check (e.g., PSXPIDX,PRCSJOBPURGE,PSRUNSTATS). Required. Maximum 50 processes.
hours
24
Time window in hours. The report checks for successful runs within this many hours from now.
PRCSNAME = '{name}', ordered by PRCSINSTANCE DESC, limit 1
Success check
PRCSNAME, PRCSINSTANCE, RUNSTATUS, BEGINDTTM
PRCSNAME = '{name}' AND RUNSTATUS = 9 AND BEGINDTTM >= cutoff, limit 1
Data Flow
1. Parse process names from comma-separated parameter
Calculate cutoff time (now - hours)
|
v
2. For each process name:
a. Query PSPRCSRQST for most recent run (any status)
b. Query PSPRCSRQST for most recent successful run (status=9) since cutoff
|
v
3. Sort results: failures first, then passes
|
v
4. Generate Markdown report:
- Summary with pass/fail counts
- Results table
- Recommendations for failures
Report Output
The generated report contains:
Header with database name, generation timestamp, and time window
Summary showing how many processes passed vs. failed
Results Table with columns: Status (PASS/FAIL), Process Name, Last Run Time, Last Run Status, Successful Run in Window
Recommendations section for any failing processes with details about their last run
Interpreting Results
PASS. The process had at least one successful run (RUNSTATUS=9) within the time window
FAIL. No successful run was found within the time window. This could mean:
The process ran but ended in error or another non-success status
The process has not run at all within the window
The process has never run (no history in PSPRCSRQST)
The “Last Run Time” and “Last Run Status” columns show the most recent run regardless of status, so you can see if it ran but failed
Use Cases
Morning Operations Check. Verify that overnight batch processes completed successfully before the business day starts
Critical Process Monitoring. Confirm that essential processes (search index builds, security syncs, integration processes) are running on schedule
Post-Maintenance Verification. After system maintenance, verify that all scheduled processes have resumed and are completing successfully
SLA Compliance. Document that required processes are running within expected timeframes
8.3.4 - Stalled Recurrences
This report identifies scheduled recurring processes that have completed a run recently but do not have a subsequent scheduled instance.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Report ID:stalled-recurrencesCategory: Process Scheduler
Purpose
This report identifies scheduled recurring processes that have completed a run recently but do not have a subsequent scheduled instance.
In PeopleSoft, recurring batch schedules are kept active by the Process Scheduler, which automatically schedules the next run when the current run starts or completes. However, issues like database refreshes, scheduler outages, cancellations, or errors can cause a schedule to stall without generating a future instance. This report lists all such stalled recurring processes to ensure they can be resumed.
The report answers: “Which of my recurring batch processes have stopped scheduling?”
Parameters
Parameter
Default
Description
lookback_days
14
The window in days. The report checks for recurring processes that completed their last run within this window but have no future runs.
Tables Queried
PSPRCSRQST — Process Request Instances
The report queries PSPRCSRQST to fetch historical and future instances that have a recurrence name assigned:
1. Calculate the lookback cutoff date based on 'lookback_days'
|
v
2. Query PSPRCSRQST for all requests with a recurrence name since the cutoff date
|
v
3. Group requests by (PRCSNAME, RUNCNTLID, OPRID, RECURNAME)
|
v
4. For each group:
- Identify active/pending instances (Queued, Blocked, Hold, Pending, Initiated, Processing, Posting, Restart)
- Identify completed instances (Success, Error, Cancelled, etc.)
- If there is at least one completed run, but ZERO active/pending runs:
- Mark the recurrence as stalled
- Find the latest completed instance
|
v
5. Generate the Markdown report:
- Summary count of stalled recurrences
- Table of stalled recurrences with last run status and links
- Troubleshooting recommendations
Report Output
The generated report contains:
Header displaying the database name, run ID, and lookback window.
Summary showing the count of stalled recurrences detected.
Results Table with columns: Process Name, Recurrence, User, Run Control, Last Instance, Last Status, and Last Run Date/Time.
Recommendations detailing the resolution steps.
Interpreting Results
If a recurrence is listed in the report, it has stopped running. Check the Last Status column:
Error / Not Successful / Unable to Post: The schedule stopped due to a process failure. The scheduler may not have been able to queue the next run, or the recurrence was stopped.
Success / Success with Warning / Cancelled: The process ran or was cancelled but did not reschedule. This could happen if the recurrence ended naturally (reached its end date), or if it was manually cancelled and not rescheduled.
Six reports against PSPROJECTDEFN, PSPROJECTITEM, PSPCMTXT, PSSQLTEXTDEFN, and the per-object definition tables. Use them to inventory customizations, compare a project across two databases, search code and SQL text strings, diff PeopleCode in an uploaded project file against a live database, find every reference to a Message Catalog entry, and identify target projects that are missing or newer before a database refresh.
For an uploaded project XML, emits per-object file source, database source, and a line-level diff for every PeopleCode program. LLM-friendly.
8.4.1 - Customized Objects Inventory
This report provides a complete inventory of all customized PeopleSoft objects across ten major object types.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report provides a complete inventory of all customized PeopleSoft objects across ten major object types. It answers the question: “What did we customize in this environment?”
Anything not stamped PPLSOFT is something you’ll have to defend during an upgrade.
Definition of “Customized”
An object is considered customized if its LASTUPDOPRID (last updated by operator) is notPPLSOFT. Objects delivered by Oracle PeopleSoft are stamped with PPLSOFT when installed. Any object modified by a customer operator will have a different value.
Object Types Covered
Object Type
PeopleSoft Table
psLens Detail Page
Records
PSRECDEFN
/records/{name}
Fields
PSDBFIELD
/fields/{name}
Pages
PSPNLDEFN
/pages/{name}
Components
PSPNLGRPDEFN
/components/{name}
Menus
PSMENUDEFN
/menus/{name}
Application Packages
PSPACKAGEDEFN
/apppackages/{name}
Application Engines
PSAEAPPLDEFN
/appengines/{name}
SQL Objects
PSSQLDEFN
/sqlobjects/{name}
Service Operations
PSOPERATION
/serviceoperations/{name}
Roles
PSROLEDEFN
/roles/{name}
Data Flow
1. For each object type:
Query the primary table with LASTUPDOPRID <> 'PPLSOFT'
(using paginated batches of 500 rows)
|
v
2. Collect all results across all pages
|
v
3. Generate summary table with counts per object type
|
v
4. Generate per-type detail sections with links to psLens detail pages
Report Output
The report contains:
Header with database name, generation timestamp, and definition of “customized”
Summary table showing the count of customized objects per type and a grand total
Detail section per object type, each with a markdown table listing:
Object name (linked to the psLens detail page)
Description (where available)
Object Owner ID (where available)
Last Updated By operator
Last Updated timestamp
Parameters
This report has no configurable parameters.
Interpreting Results
High counts in a specific object type indicate heavy customization in that area. This increases upgrade risk for those object types.
Object Owner ID (OBJECTOWNERID) shows the functional owner of the object (e.g., a product line or module). A customer-specific owner ID confirms the object is a true customization vs. a third-party product extension.
Last Updated By shows which operator last touched the object. Objects last updated by a system batch operator may have been auto-modified vs. intentionally customized.
Objects with no entry in a section means that type has no customizations, which is worth noting for upgrade planning.
Use Cases
Pre-upgrade assessment. Run this report before a PeopleTools or application upgrade to understand the full scope of customizations that will need to be reviewed and re-applied.
Customization audit. Share with Oracle support or an implementation partner to get an accurate picture of what has been changed in the environment.
Developer handoff. Use as a starting inventory when onboarding new team members or transferring system ownership.
8.4.2 - Project Cross-Database Comparison
This report compares a PeopleSoft project’s definition and items across two databases. It identifies:
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This report compares a PeopleSoft project’s definition and items across two databases. It identifies:
Objects that exist only in the source database (not yet migrated to target)
Objects that exist only in the target database (previously migrated, now deleted in source)
Objects in both databases where the item metadata (source status, target status, upgrade action, take action, copy done) differs
This is primarily a migration and change management tool. Use it to verify that a project migration completed correctly, to audit what is in DEV vs. TEST vs. PROD, or to identify drift between environments.
The report surfaces added, removed, and changed project items so migration drift is visible in one artifact
What It Detects
Items Only in Source
Objects that are in the project in the source database but not in the target. These are typically items that have not been migrated yet or were added to the project after the last migration.
Items Only in Target
Objects that are in the project in the target database but not in the source. These may indicate objects that were removed from the project definition in the source after migration, or items migrated separately.
Items with Differences
Objects present in both databases but with different metadata values:
Field
Description
Source Status
Whether the object was copied from the source (Copied, Not Copied, etc.)
Target Status
Whether the object was copied to the target
Upgrade Action
The configured upgrade action for this item
Take Action
Whether psLens will take action on this item during copy
Copy Done
Whether the copy operation completed for this item
Project Definition Comparison
In addition to items, the report compares the project header fields:
Description and long description
Version number
Last updated timestamp and operator
Owner ID and release label
Tables Queried
PSPROJECTDEFN — Project Definitions
Field
Description
PROJECTNAME
Project name (primary key)
DESCR
Short description
DESCRLONG
Long description
VERSION
Version number
LASTUPDOPRID
Last updated by
LASTUPDTTM
Last updated timestamp
OBJECTOWNERID
Object owner ID
RELEASELABEL
Release label
RELEASEDTTM
Release date/time
PSPROJECTITEM — Project Items
Field
Description
PROJECTNAME
Project name
OBJECTTYPE
Numeric object type code
OBJECTVALUE1-4
Object identifier fields (vary by type)
SOURCESTATUS
Copy-from status
TARGETSTATUS
Copy-to status
UPGRADEACTION
Configured upgrade action
TAKEACTION
Whether action will be taken
COPYDONE
Copy completion flag
Data Flow
1. Fetch project definition from Source DB
|
v
2. Fetch project definition from Target DB
|
v
3. Compare project header fields
→ Report differences
|
v
4. Fetch all project items from Source DB
|
v
5. Fetch all project items from Target DB
|
v
6. Build composite key maps for each item
(ObjectType + ObjectValue1-4)
|
v
7. Find items only in source (not in target)
8. Find items only in target (not in source)
9. Find items in both with field differences
|
v
10. Generate Markdown report with summary + detail sections
Parameters
Parameter
Required
Description
projectName
Yes
The exact PeopleSoft project name to compare
targetDB
Yes
The name of the target database (as configured in psLens)
The source database is the database selected when running the report.
Report Output
The generated report contains:
Header with source and target database names, project name, and generation timestamp
Project Definition Comparison table showing any fields that differ between the two databases
Summary with counts: total items in source, total in target, only-in-source, only-in-target, with-differences, identical
Items Only in Source section, grouped by object type
Items Only in Target section, grouped by object type
Items with Differences table showing object type, name, field, source value, and target value
If the project does not exist in one of the databases, the report notes this and shows the available definition from the other database.
Interpreting Results
Items only in source are likely candidates for migration — they exist in your development or staging environment but have not been moved to the target yet.
Items only in target may indicate stale objects in the target environment that were removed from the project in source, or objects migrated separately outside this project.
Items with differences in Source/Target Status or Copy Done fields can indicate a migration that did not complete cleanly.
Project definition differences in Version or Last Updated can help confirm which database has the more recent project definition.
Use Cases
Pre-migration verification: Confirm which objects in a project have not yet been migrated to the next environment
Post-migration audit: Verify that all project items made it to the target cleanly
Environment drift detection: Identify objects that exist in PROD but not in DEV (or vice versa)
Change management documentation: Generate a Markdown report of exactly what changed between environments for a release
8.4.3 - Missing Projects Refresh Risk Report
This page documents the report used to audit project risk in a target database before a database refresh.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
This page documents the report used to audit project risk in a target database before a database refresh.
Purpose
When refreshing a non-production PeopleSoft database (like TEST or DEV) with a copy of production (like PRD), code or metadata changes in TEST/DEV that have not yet been migrated to production are permanently deleted. This report identifies target database projects updated since a specific date that are missing or have older versions in the production database.
What It Detects
The report groups target projects into three risk categories based on their presence and versions in the source database:
High Risk: Missing in Source
Projects that exist in the target database but are completely missing in the source database. Overwriting the target database will delete these projects and their constituent objects.
Medium Risk: Newer in Target
Projects that exist in both databases, but the target database contains a newer version number or last updated timestamp. Overwriting the target database will revert these changes to the older version.
Low Risk: Identical or Older in Target
Projects that exist in both databases where the source database has an identical or newer version. These are safe to overwrite.
Tables Queried
PSPROJECTDEFN — Project Definitions
Field
Description
PROJECTNAME
Project name (primary key)
PROJECTDESCR
Short description
VERSION
Version number
LASTUPDOPRID
Last updated by
LASTUPDDTTM
Last updated timestamp
Parameters
Parameter
Required
Description
source_db
Yes
The name of the source/production database (e.g. PRD)
as_of_date
Yes
The date to filter target projects (updated on or after this date)
The target database is selected from the primary database dropdown in the report runner.
Use Cases
Pre-refresh audit: Run this report before restoring a production database backup to a non-production database to identify developer work that needs to be backed up or migrated.
Unmigrated work tracking: Audit what projects have been created or modified in a test database but not yet migrated to production.
8.4.4 - Project Import — PeopleCode Diff vs Database
You uploaded a PeopleSoft project XML on the Project Import page, and you want to know — line-by-line — how every PeopleCode program inside that fi…
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
You uploaded a PeopleSoft project XML on the Project Import page, and you want to know — line-by-line — how every PeopleCode program inside that file compares to the same program in a live database.
The Project Import results page itself shows a quick Same / Different / Not in DB badge per object (powered by a content-hash compare against PSPCMTXT). That’s enough for triage. When you need to see what actually changed, run this report; it emits a full markdown document with file source, database source, and a unified diff for every PeopleCode object that differs.
The output is designed to be reviewed by hand or fed directly to an LLM — the per-object structure (file block, DB block, diff block) is what most assistants need to reason about the change.
What It Compares
This report only looks at PeopleCode-bearing object types:
Record PeopleCode (type 8)
Menu PeopleCode (type 9)
Message PeopleCode (type 39)
App Engine PeopleCode (type 43)
Page PeopleCode (type 44)
Component PeopleCode (type 46)
Component Record PeopleCode (type 47)
Component Record Field PeopleCode (type 48)
Application Package PeopleCode (type 58)
For each PeopleCode item in the project, the report:
Reads the source from the uploaded XML (peoplecode_text node parsed at upload time).
Fetches the current source from the target database’s PSPCMTXT table, concatenating multi-row PCTEXT payloads in PROGSEQ order.
Normalizes both sides (line-ending normalization, trailing-whitespace strip, blank-line collapse) so cosmetic differences don’t show up as content changes.
Classifies the item as Same, Different, Not in DB, No XML Source, or Error.
For Different items, renders both sources and a line-level diff inline.
Non-PeopleCode object types in the same project are not included in this report — use the Project Import results page for those (it uses LASTUPDDTTM comparison, which is reliable for non-PeopleCode types).
Parameters
Parameter
Required
Default
Description
project_id
Yes
—
The file-store ID of the uploaded project. The Project Import results page provides a “PeopleCode Diff Report” button that pre-fills this.
max_objects
No
100
Cap on how many Different objects are rendered with full source + diff. Excess Different objects are mentioned in a footer line; raise the cap if you need them all inline. Prevents the report from blowing up on projects with hundreds of changed PeopleCode programs.
include_same
No
false
Set to true to append a table listing every PeopleCode object that matched. Off by default since this is usually the noise, not the signal.
The target database is the standard psLens database selector on the Reports page — the report runs against whichever database you have selected.
Output Structure
The report is a single markdown document with these sections in order:
Header — project name, source DB (from the XML export), target DB, export date, exporter ID, uploaded filename, upload time.
Summary — counts of Same / Different / Not in DB / No XML Source / Errors.
Different — one section per Different object containing:
File source — code fence with peoplecode language hint.
Database source — code fence with peoplecode language hint.
Line diff (file → DB) — code fence with diff language hint; lines unchanged on both sides appear with two-space prefix, removed-from-file lines with -, added-in-DB lines with +.
Not in Database — one section per item, with the file source rendered. These are typically programs the project would create on import.
No XML Source — table of programs the DB has but the XML didn’t inline. Usually means the project listed the PJM entry without the PCM payload.
Errors — table of programs whose DB query failed, with the underlying error.
Same (optional, include_same=true) — table of matching programs.
Tips
Feed it to an LLM. The structure (file block + DB block + diff block per object) is what assistants need to reason about a change. Download the markdown and paste into your assistant of choice, or use the Download .md button on the report run page.
Pair with the Cross-Database Comparison report.project-compare covers two databases; this one covers file vs database. Different problems.
Run before a project import. Knowing exactly what will change in PeopleCode terms is the question this report answers — not “what does the timestamp say” but “what code lines will end up different.”
8.4.5 - Message Catalog Usages
This report searches the entire PeopleSoft database and codebase to locate every usage of a specific Message Catalog entry.
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Report ID:msgcat-usagesCategory: Objects / Development
Purpose
This report searches the entire PeopleSoft database and codebase to locate every usage of a specific Message Catalog entry. It answers the question: “If I modify or delete this message set or number, what fields, pages, or PeopleCode programs will be affected?”
Use this when someone hands you a (10, 12) error code, or when you want to know if anything still references a message before you delete it.
What Gets Searched
The report dynamically discovers and queries all tables that store message reference columns (MESSAGE_SET_NBR and MESSAGE_NBR or their field aliases, such as GRDLBLMSGSET and GRDLBLMSGNUM), as well as the PeopleCode codebase.
Whitelisted Tables:
The report automatically queries all whitelisted database tables containing both message columns or their aliases. The most common UI placement searched is:
PSPNLFIELD (Page Fields): Finds where message catalogs are assigned as static labels or tooltips on page controls.
PeopleCode Source (PSPCMTXT):
Searches the actual text of all compiled PeopleCode programs for function calls that fetch catalog messages. This includes:
MsgGet(...)
MsgGetText(...)
MsgGetExplainText(...)
Non-Whitelisted Tables:
Discovers any other database tables in the system that contain both message columns or their aliases but are not currently in the SWS whitelisting table. The report generates a custom SQL snippet for each of these so developers can query them manually.
Report Output
The generated markdown report contains:
Detailed Findings: Tables showing matching objects (e.g. Page Fields and data tables) with key identifiers and deep links back to their respective psLens detail pages.
PeopleCode References: A table listing the PeopleCode program type, record/package name, event, and field where the MsgGet call was found.
Manual Query SQL Block: A single consolidated SQL block with comments identifying each non-whitelisted table, ready to copy and paste into a SQL client.
Parameters
Parameter
Required
Type
Description
message_set_nbr
Yes
Integer
The Message Set number to search for (e.g., 10 or 20000).
message_nbr
No
Integer
The specific Message number. If omitted, the report returns all usages across every message in the specified Message Set.
Use Cases
Impact Analysis: Before updating a delivered or custom message text, run this report to ensure the change is appropriate for all context areas where it is displayed.
Error Debugging: If an application log or user screenshot displays an error message ID (e.g., (10, 12)), run the report with message_set_nbr = 10 and message_nbr = 12 to instantly locate the exact line of PeopleCode emitting the error.
Audit and Cleanup: Scan custom message sets (e.g., set numbers > 20000) to find orphan messages that are no longer referenced anywhere in code or page labels.
8.4.6 - Code & SQL Text Search
This report performs text string searches across PeopleCode programs (PSPCMTXT), SQL Objects (PSSQLTEXTDEFN), and Application Engine SQL statements (PSAESTMTDEFN).
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
Report ID:code-sql-search Category: Objects / Development
Purpose
The Code & SQL Text Search report performs text searches across PeopleCode, standalone SQL Objects, and Application Engine SQL statements. It returns matched line numbers, surrounding code context, and deep links to psLens detail pages.
Use this report when searching for references to deprecated fields, custom function calls, hardcoded URLs, or specific SQL statements.
Metadata Tables Searched
PSPCMTXT (PeopleCode Source Text):
Searches plain-text PeopleCode across Record, Page, Component, Component Interface, App Package, Message, App Engine, and Menu PeopleCode programs. Concatenates multi-row PROGSEQ sequences to compute line numbers and extract 2-line code context.
PSSQLTEXTDEFN (SQL Object Source Text):
Searches SQL text for views, standalone SQL objects, App Engine SQL definitions, and App Class SQL statements. Concatenates multi-row SEQNUM rows to return line-level matches.
Summary: Total match counts broken down by PeopleCode, SQL Objects, and App Engine SQL.
PeopleCode Matches: Program type, record or package name, event or class name, line number, and a syntax-highlighted code block with surrounding context lines and a match indicator (<-- MATCH).
SQL Object Matches: SQL ID, line number, code snippet, and deep links to /sqlobjects/{SQLID}.
App Engine SQL Matches: Application Engine ID, section, step, line number, code snippet, and deep links to /appengines/{APPLID}.
Parameters
Parameter
Required
Type
Default
Description
search_term
Yes
String
The text string to search for across code and SQL text.
scope
No
String
All
Search scope: All, PeopleCode, or SQL.
case_sensitive
No
Boolean
false
Set to true to perform exact case-sensitive text matching.
custom_only
No
Boolean
false
Set to true to filter for items last updated by non-PPLSOFT user IDs.
max_results
No
Integer
200
Maximum total matches to return in the report output.
Use Cases
Impact Analysis: Before modifying a record field or function signature, search PSPCMTXT to locate all calling locations.
Hardcoded Reference Audit: Search for hardcoded URL paths, IP addresses, or environment-specific strings in PeopleCode and SQL objects.
Upgrade & Tax Update Triage: Search for modified SQL views or Application Engine SQL statements when evaluating target database releases.
8.5 - Sample Report Output
Real psLens report output, exported to Markdown from a development environment, so you can see the exact artifact a report run produces before installing anything.
Every psLens report produces a Markdown document: findings up top, supporting detail below, stored for 90 days and exportable with one click. The files linked on this page are real output, run against a Campus Solutions 9.2 development image and exported exactly as psLens produced them. Only hostnames and two service-account names were changed. The deep links inside each file point at a placeholder psLens URL; in your deployment they resolve to the live object pages.
Stale Passwords Report
Lists unlocked accounts whose password is older than the configured threshold (90 days in this run), with last sign-on and permission list context. Against this dev image it analyzed 212 user accounts and flagged 11 accounts that had not changed passwords in over a year, including the delivered PS superuser at 463 days.
Checks permission lists for capabilities that bypass security controls or escalate privileges: SOAP-to-CI web library access, WSDL generation, user profile management, role management, node configuration, and more. Each finding lists the permission lists involved, the roles that carry them, and the count of unlocked users affected. This run found 2 permission lists granting SOAP-to-CI access, one of them attached to broad self-service roles.
Flags message nodes with no authentication configured. Against this dev image: 62 active nodes, 58 of them with AUTHOPTN='N', meaning any system that can reach the gateway can send messages through them. Delivered dev images really do look like this, which is why the report exists.
Each report above is documented in the reports catalog with its parameters and the PeopleTools tables it reads. Reports run in the background with live progress, and results stay available for 90 days.
9 - Alerts
psLens real-time alerts for PeopleSoft: monitor long-running processes, process errors, stalled Integration Broker messages, failed logins, and more.
Alerts
Alert checks run on a 5-minute timer against every connected database. Findings appear on the dashboard with severity, and clear automatically when the underlying condition resolves. There is no acknowledge or dismiss.
Alerts surface on the dashboard with severity and context, then hand the operator into the exact follow-up view
How the Alert System Works
psLens runs a set of alert checks on a timer (default: every 5 minutes)
Each check queries one or more connected databases
If a check finds something worth noting, it creates alert items with a severity level
Alert results appear on the dashboard immediately
When the underlying issue resolves, the alert clears automatically on the next check cycle
Alerts always reflect the current state of the system.
Alert Severity Levels
Severity
Color
Meaning
Critical
Red
Something is actively wrong and needs immediate attention
Warning
Yellow
Something should be investigated. It may become a problem.
Info
Blue
Low-priority finding; worth noting but not urgent
Alert Data Retention
Alert results are stored for 15 minutes. This means the dashboard shows findings from the most recent check cycle. Once an issue is resolved and the next check runs cleanly, the alert data expires.
Configuring Alerts
Alerts are configured in config.yaml. You can:
Enable or disable the entire alert system (alerts.enabled)
Set how often checks run (alerts.intervalMinutes)
Enable or disable individual checks
Set thresholds for stalled/long-running checks
Set lookback windows for error checks
Exclude specific process names or IB operation names from checks
See Configuration for the full configuration reference.
Alert Categories
Browse alerts by category:
Process Scheduler: Long-running processes, errors, backlogged jobs, locked operators, critical process monitoring
Web Server / WebLib: Alerts when the PeopleSoft Web Server or WebLib endpoints fail to respond
Security: Failed login detection and authentication monitoring
Generic SWS Alerts: Define custom, queryable alert rules using PsoftQL against any whitelisted tables
See Alerts in Action
The catalog tells you what psLens checks. A live walkthrough shows what matters operationally: how alerts appear, how they clear, and how quickly your team can move from a card on the dashboard to the underlying problem.
Process Scheduler alerts: long-running processes, process errors, backlogged processes, queue latency, locked operators, and critical process monitoring.
Process Scheduler alerts monitor your PeopleSoft batch processing environment for errors, stalls, and missing critical runs.
Schedulers that have not updated their heartbeat status in PSSERVERSTAT recently
9.1.1 - Long-Running Processes
This alert finds Process Scheduler requests that are currently in Initiated or Processing status and have been running longer than their expected d…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:long_running_processesCategory: Process Scheduler
Default threshold: Dynamic (4x rolling median, min 10 min baseline) or static fallback (20 minutes)
What This Alert Detects
This alert finds Process Scheduler requests that are currently in Initiated or Processing status and have been running longer than their expected duration.
Instead of relying solely on a static global threshold, psLens dynamically calculates an expected duration for each process using its own history:
It fetches the last 10 successful run durations for the specific process name (PRCSNAME).
It calculates the rolling median runtime of those successful runs.
It raises an alert if the current execution duration exceeds a multiple of the median (default: $4\times$ the median, with a minimum baseline of 10 minutes).
If no successful runs are found (e.g. a brand new process or a process that has never completed successfully), it falls back to the static global thresholdMinutes (default: 20 minutes).
A process that has been running for a long time may be stuck, consuming excessive server resources, or waiting on a lock or resource that will never become available.
Severity Logic
Condition
Severity
Running longer than dynamic threshold (or static fallback)
Warning
For example:
If a process usually runs in 3 minutes: median is 3m. $4\times 3 = 12$ minutes. The alert triggers if it runs for 12 minutes or more.
If a process usually runs in 1 minute: median is 1m. $4\times 1 = 4$ minutes. Since this is below the 10-minute minimum baseline, the baseline is used: the alert triggers if it runs for 10 minutes or more.
If a process has no history: fallback is used. The alert triggers if it runs for 20 minutes or more.
What Gets Checked
The alert queries the Process Scheduler request table for processes in run status 6 (Initiated) or 7 (Processing). For each result, it calculates how long the process has been running based on its BeginDttm (begin datetime) and the current server time.
Processes with no BeginDttm value are skipped (the process hasn’t truly started yet).
Alert Details
Each alert item includes:
Process name (PRCSNAME)
Process instance number
How long the process has been running (in minutes)
The rolling median runtime (if available, in minutes)
The operator who submitted the request
A link to the Process Monitor detail page for that instance
Configuration
alerts:checks:long_running_processes:enabled:truethresholdMinutes:20# Fallback static minutes when history is emptyanomalyMultiplier:4.0# Multiplier applied to rolling mediananomalyMinBaselineMinutes:10# Minimum baseline runtime before alertingexcludeProcesses:# Process names to skip- SOME_LONG_BATCH_JOB
Setting
Default
Description
thresholdMinutes
20
Fallback static minutes a process must be running to trigger an alert if no successful run history exists.
anomalyMultiplier
4.0
Multiplier applied to the rolling median duration to calculate the dynamic threshold.
anomalyMinBaselineMinutes
10
The minimum baseline duration in minutes. Dynamic thresholds are capped to be at least this value to prevent false alerts on very fast processes.
excludeProcesses
[]
List of process names to exclude from this check. Use for known long-running processes that are expected to take a long time.
How to Respond
Click the alert link to go directly to the Process Monitor entry for the flagged process
Review the process details: what it is, who submitted it, when it started
Check whether the process appears to be making progress or is stuck
If the process is genuinely stuck, you may need to cancel it from PeopleSoft’s Process Monitor
Investigate why it got stuck: look for locks, resource contention, or data issues
Tuning the Threshold
The right threshold depends on your environment. You can adjust anomalyMultiplier or anomalyMinBaselineMinutes globally or per-database to reduce noise, or use excludeProcesses to ignore specific jobs entirely.
9.1.2 - Process Errors
This alert finds Process Scheduler requests that have failed within a configurable lookback window.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:process_errorsCategory: Process Scheduler
Default lookback: 24 hours
What This Alert Detects
This alert finds Process Scheduler requests that have failed within a configurable lookback window. It catches processes that ended in one of three error statuses:
Run Status
PeopleSoft Code
Meaning
Error
3
The process ended with an error condition
Not Successful
10
The process ran but reported a non-success result
Unable to Post
12
The process output could not be delivered
Severity Logic
Process Type
Status
Severity
Recurring (on a recurrence schedule)
Error (3), Not Successful (10), Unable to Post (12)
Critical
Non-Recurring (ad-hoc execution)
Error (3), Not Successful (10), Unable to Post (12)
Warning
Recurring Processes: Any failure fires Critical immediately.
Non-Recurring Processes: Fire Warning after the thresholdMinutes grace period.
Alert Details
Each alert item includes:
Process name and instance number
Run status label (Error, Not Successful, Unable to Post)
The operator who submitted the request
When the process ran
A link to the Process Monitor detail page for that instance
Configuration
alerts:checks:process_errors:enabled:truelookbackHours:24# How far back to look for failuresthresholdMinutes:15# Grace period buffer in minutes for non-recurring errorsexcludeProcesses:# Process names to skip- KNOWN_FLAKY_PROCESS
Setting
Default
Description
lookbackHours
24
Number of hours back to search for failed processes
thresholdMinutes
0
Grace period buffer (in minutes) for non-recurring process errors before they raise a Warning alert.
excludeProcesses
[]
List of process names to exclude from this check
How to Respond
Click the alert link to go directly to the Process Monitor entry for the failed process
Review the process details: run status, begin and end times, server
Look for output files or log information that might explain the failure
Check whether this is a one-time failure or a repeating issue
If the process needs to be rerun, submit a new request from PeopleSoft
Common Causes of Process Failures
Data errors: The process encountered unexpected data (null values, bad formats, constraint violations)
Resource issues: The server ran out of memory or disk space
Timeout: The process exceeded its allowed run time
Configuration problems: A required configuration parameter is missing or incorrect
Dependency failures: A process that runs after another failed because the first one didn’t complete correctly
Reducing Alert Noise
If certain processes fail regularly and you’re already tracking them separately, add them to excludeProcesses to keep the alert list focused on unexpected failures.
9.1.3 - Backlogged Processes
This alert finds Process Scheduler requests that are in Queued or Blocked status and whose scheduled run time (RUNDTTM) has already passed by more …
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:backlogged_processesCategory: Process Scheduler
Default threshold: 30 minutes
What This Alert Detects
This alert finds Process Scheduler requests that are in Queued or Blocked status and whose scheduled run time (RUNDTTM) has already passed by more than the configured threshold. This alert focuses exclusively on processes currently waiting to start. Once a process begins running, it is cleared from this alert and is instead tracked by the Queue Latency alert.
Severity Logic
Condition
Severity
Overdue by more than thresholdMinutes
Warning
Overdue by more than thresholdMinutes × 2
Critical
For example, with the default threshold of 30 minutes:
A process scheduled 40 minutes ago that is still queued → Warning
A process scheduled 65 minutes ago that is still queued → Critical
What Gets Checked
The alert queries the Process Scheduler request table for processes in run status 5 (Queued) or 18 (Blocked) whose RUNDTTM (scheduled run datetime) is in the past. For each result, it calculates how far past the scheduled time the process is based on RUNDTTM and the current server time.
Processes with no RUNDTTM value are skipped. Completed or active runs are skipped.
Alert Details
Each alert item includes:
Process name (PRCSNAME)
Process instance number
How long the process is overdue (in minutes)
Current run status (Queued or Blocked)
The operator who submitted the request
A link to the Process Monitor detail page for that instance
Configuration
alerts:checks:backlogged_processes:enabled:truethresholdMinutes:30# Minutes overdue before flagging as WarningexcludeProcesses:# Process names to skip- SOME_LOW_PRIORITY_JOB
Setting
Default
Description
thresholdMinutes
30
Minutes past the scheduled run time before a queued/blocked process triggers a Warning alert. Critical fires at 2× this value.
excludeProcesses
[]
List of process names to exclude from this check. Use for processes that are known to queue for a long time and are not a concern.
How to Respond
Click the alert link to go directly to the Process Monitor entry for the flagged process
Check whether the Process Scheduler server is running and accepting work
Look at how many processes are currently running on the server. It may have hit its concurrency limit
Check if the process type or class has reached its maximum allowed concurrent instances
For blocked processes, investigate what is blocking them (dependencies, server restrictions, etc.)
If the Process Scheduler server is down, restart it from PeopleSoft’s Process Scheduler administration
Tuning the Threshold
The right threshold depends on how busy your Process Scheduler is. In environments where many jobs are submitted at once, some queuing is normal. Set thresholdMinutes high enough to avoid false positives during peak batch windows but low enough to catch genuine problems. You can also use excludeProcesses to exclude specific low-priority processes that are known to queue for long periods.
9.1.4 - Locked OPRID Scheduled Processes
This alert finds queued or scheduled Process Scheduler requests where the submitting operator’s account (OPRID) is currently locked in PSOPRDEFN (A…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:locked_oprid_processesCategory: Process Scheduler
What This Alert Detects
This alert finds queued or scheduled Process Scheduler requests where the submitting operator’s account (OPRID) is currently locked in PSOPRDEFN (ACCTLOCK = 1).
When an operator account is locked after a process has been queued, PeopleSoft will refuse to run the process, or run it under the locked account and immediately fail. PeopleSoft does not surface this condition anywhere obvious: Process Monitor shows the job queued, the operator’s user page shows them locked, but nothing connects the two. This alert does.
Common scenarios:
A service or batch account had its password expire and was locked
An employee left and their account was locked, but scheduled jobs were not transferred
A security lockout from failed login attempts affected a batch account
Severity Logic
All findings are reported at Warning severity. Every queued or scheduled process with a locked submitting account is flagged.
What Gets Checked
The alert queries PSPRCSRQST joined to PSOPRDEFN for process requests in Queued or Scheduled run status where the submitting OPRID has ACCTLOCK = 1.
Alert Details
Each alert item includes:
Process name and instance number
Submitting OPRID (with link to User detail page)
Current run status (Queued, Scheduled, etc.)
Scheduled run date/time
Recurrence name (if applicable)
Configuration
alerts:checks:locked_oprid_processes:enabled:trueexcludeProcesses:[]# Process names to ignore
Setting
Default
Description
excludeProcesses
[]
List of process names to exclude from this check
How to Respond
Click the alert link to open the Process Monitor detail page for the affected instance
Identify the locked OPRID shown in the alert
Navigate to the User detail page to review the account lock status
Either unlock the account (if appropriate) or re-queue the process under an active operator account
For recurring processes, update the recurrence definition to use a non-locked operator
Investigate why the account was locked. If it was a failed login lockout, check the Failed Logins alert for additional context
Tables Queried
Table
Description
PSPRCSRQST
Process Scheduler request queue
PSOPRDEFN
Operator definitions (user accounts)
9.1.5 - Queue Latency
This page documents the queue latency alert, which monitors the delay between a process’s scheduled run time and its actual start time.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:queue_latencyCategory: Process Scheduler
Default threshold: 15 minutes
Queue Latency Alert in psLens showing processes with start delays exceeding the threshold
What This Alert Detects
This page documents the queue latency alert, which monitors the delay between a process’s scheduled run time and its actual start time. It queries the PSPRCSRQST table for processes that have started running or completed within the lookback window and calculates the delay as BEGINDTTM - RUNDTTM.
Severity Logic
Condition
Severity
Start delay more than thresholdMinutes
Warning
For example, with the default threshold of 15 minutes:
A process scheduled for 10:00 that started running at 10:20 → Warning
What Gets Checked
The alert queries the Process Scheduler request table (PSPRCSRQST) for processes whose BEGINDTTM (begin datetime) is in the past lookback window (default 24 hours). For each process, it calculates the difference between BEGINDTTM and RUNDTTM (scheduled run datetime).
Processes that have not started running yet (empty BEGINDTTM value) are skipped. Active queuing checks are handled by the backlogged_processes alert.
Alert Details
Each alert item includes:
Process name (PRCSNAME)
Process instance number
Start delay duration (in minutes)
Current run status (Initiated, Processing, Success, Error, etc.)
The operator who submitted the request
A link to the Process Monitor detail page for that instance
Configuration
alerts:checks:queue_latency:enabled:truethresholdMinutes:15# Minutes delay before flagging as WarninglookbackHours:24# Hours to look back for completed/running processesexcludeProcesses:# Process names to skip- LOW_PRIORITY_AE
Setting
Default
Description
thresholdMinutes
15
Minutes of start delay before a process triggers a Warning alert.
lookbackHours
24
Hours to look back for processes to verify.
excludeProcesses
[]
List of process names to exclude from this check. Use for processes that are known to delay and are not a concern.
How to Respond
Click the alert link to go to the Process Monitor entry for the flagged process.
Review the process server definition to identify if it is running and accepting work.
Check the max concurrent limits configured on the Process Scheduler server or category definitions.
Verify if other higher-priority processes occupied all available channels.
If the delay is caused by category stalls, adjust the process class concurrency settings.
Tuning the Threshold
Environments with heavy batch schedules may experience normal queue delays during peak hours. Set thresholdMinutes high enough to prevent alerts on minor delays but low enough to flag scheduler capacity bottlenecks or server category stalls.
9.1.6 - Process Run Check
This alert monitors configured critical processes and fires when one has not completed successfully within its expected time window.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:process_run_checkCategory: Process Scheduler
What This Alert Detects
This alert monitors configured critical processes and fires when one has not completed successfully within its expected time window. It is the alert equivalent of the Process Run Check report. The difference is that this runs automatically on every check cycle and surfaces failures on the dashboard without any manual action.
Use this alert for processes that must run on a regular cadence, such as:
Nightly batch jobs that must complete before business hours
Data synchronization processes that run every few hours
Critical integrations that should run multiple times per day
Post-maintenance verification of essential processes
Severity Logic
Condition
Severity
Process has run recently but not successfully in the configured window
Warning
Process has no run history at all
Critical
Configuration
Process checks are configured per process name in config.yaml. Each entry specifies the process name and the number of hours within which a successful run is expected.
alerts:checks:process_run_check:enabled:trueprocessChecks:SOMEJOBNAME:24# Must run successfully within 24 hoursANOTHERJOB:8# Must run successfully within 8 hoursNIGHTLY_ETL:12# Must run successfully within 12 hours
Setting
Default
Description
processChecks
{}
Map of process name to expected run window in hours
If a process name is listed with 0 or a negative value, the check defaults to a 24-hour window.
What Gets Checked
For each configured process, psLens queries PSPRCSRQST for successful runs (RunStatus = 9 / Success) within the configured time window. If none are found, it then checks for any run history to determine severity:
No successful run in window + recent run history found: Warning
No run history at all: Critical
Alert Details
Each alert item includes:
Process name
Configured threshold (hours)
Last known run status (if any history exists)
Last known run time (if any history exists)
Link to the Process Definition detail page
How to Respond
Click the alert link to open the Process Definition detail page for the affected process
Review recent run history to understand what happened. Did the process run but fail, or did it not run at all?
Check the Process Scheduler server configuration if the process never ran
Investigate error logs if the process ran but ended in a failed state
If the process ran and succeeded but outside the expected window, consider adjusting the threshold in config.yaml
Tables Queried
Table
Description
PSPRCSRQST
Process Scheduler request queue and run history
9.1.7 - Process Scheduler Down
This alert triggers when any active Process Scheduler server registered in PSSERVERSTAT has not reported a status update (heartbeat) within the con…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:process_scheduler_downCategory: Process Scheduler
Default threshold: 10 minutes
What This Alert Detects
This alert triggers when any active Process Scheduler server registered in PSSERVERSTAT has not reported a status update (heartbeat) within the configured amount of time.
Note
The alert automatically ignores servers whose status is explicitly set to "1" (Down) or "7" (Suspended - Offline), as these represent intentionally stopped or offline schedulers. It will only flag active server configurations (e.g., Running, Suspended, Error, Overloaded) that have stalled or stopped updating.
Severity Logic
Condition
Severity
Heartbeat stale by more than thresholdMinutes
Warning
Heartbeat stale by more than thresholdMinutes × 2
Critical
For example, with the default threshold of 10 minutes:
A scheduler that hasn’t heartbeat’ed for 12 minutes → Warning
A scheduler that hasn’t heartbeat’ed for 22 minutes → Critical
What Gets Checked
The alert queries the PSSERVERSTAT table to retrieve all server status definitions. For each active scheduler (status not Down/Offline), it calculates the elapsed time since its LASTUPDDTTM timestamp. If that time exceeds the configured threshold, the alert fires.
Alert Details
Each alert item includes:
Server name (SERVERNAME)
Current status code and friendly string status (e.g., Running, Error, Suspended)
Last heartbeat timestamp (LASTUPDDTTM)
Host name (SRVRHOSTNAME)
A detailed explanation of how long the heartbeat has been stale
A link to the Server Definition detail page for that server
Configuration
alerts:checks:process_scheduler_down:enabled:truethresholdMinutes:10# Minutes stale before flagging as WarningexcludeProcesses:# Server names (e.g., PSUNX, PSNT) to skip- PSUNX_OLD
Setting
Default
Description
thresholdMinutes
10
Minutes of stale heartbeat status updates before a scheduler triggers a Warning alert. Critical fires at 2× this value.
excludeProcesses
[]
List of server names to exclude from this check. Use for retired scheduler definitions that linger in PSSERVERSTAT but aren’t cleaned up.
How to Respond
Click the alert link to go directly to the Server Definition detail page for the affected scheduler.
Check the Host Name where the Process Scheduler daemon runs.
Access the server host and verify whether the Process Scheduler processes (e.g., psadmin, PSAESRV, etc.) are running.
Review the Process Scheduler logs (e.g., TUXLOG, SCHED_*.LOG) on the host machine to diagnose why the process has hung or crashed.
If the scheduler has hung, stop the process scheduler daemon and restart it using psadmin.
If the server definition is obsolete or decommissioned, consider deleting it in PeopleSoft Server Definitions configuration to clean up the PSSERVERSTAT row.
9.1.8 - No Process Completed
This alert fires when no process has successfully completed within the configured lookback window. It is a broad scheduler health check.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:no_process_completedCategory: Process Scheduler
Default lookback: 1 hour
What This Alert Detects
This alert fires when no process has successfully completed within the configured lookback window. It is a broad scheduler health check. If nothing has finished successfully in the past hour, the Process Scheduler may be down, stalled, or not dispatching jobs.
This is distinct from the Process Run Check, which monitors specific named processes. This alert monitors overall scheduler activity.
Severity Logic
Condition
Severity
Zero successful completions in the lookback window
Warning
What Gets Checked
The alert queries PSPRCSRQST for any process with RunStatus = 9 (Success) and an end datetime within the lookback window. If no rows are returned, the alert fires.
Only one result is needed to resolve the alert. The check uses a limit of 1 for efficiency.
Alert Details
When firing, the alert produces a single item:
Summary: No process completed successfully in the last N hour(s)
Lookback hours used for the check
Configuration
alerts:checks:no_process_completed:enabled:truelookbackHours:1# How far back to look for completed processes
Setting
Default
Description
lookbackHours
1
How many hours back to look for a successfully completed process.
How to Respond
Check PeopleSoft’s Process Monitor to see if any processes are running, queued, or have recently completed
Verify the Process Scheduler server is running (PeopleSoft > PeopleTools > Process Scheduler > Servers)
If processes are queued but not running, the scheduler daemon may need to be restarted
If this fires regularly during off-hours when no jobs run, increase lookbackHours or disable the alert for those periods
Tuning
If your environment has periods where no batch jobs are expected to run (e.g., overnight maintenance windows), consider increasing lookbackHours to cover those gaps, or disable the alert entirely during those windows.
9.1.9 - Stalled Recurrences
This alert fires when a scheduled recurring process has finished a run recently (within the lookback window) but does not have a subsequent schedul…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:stalled_recurrencesCategory: Process Scheduler
Default lookback: 336 hours (14 days)
What This Alert Detects
This alert fires when a scheduled recurring process has finished a run recently (within the lookback window) but does not have a subsequent scheduled instance.
In PeopleSoft, the Process Scheduler is responsible for scheduling the next run of a process based on its recurrence definition when the current one runs. If the scheduler is interrupted, a database is refreshed, or an error occurs during the scheduling process, the recurring job can fall off the schedule. This check identifies those occurrences so they do not go unnoticed.
Severity Logic
Condition
Severity
The latest completed run failed (status was Error, Not Successful, or Unable to Post) and no next run is scheduled
Critical
The latest completed run succeeded or was cancelled and no next run is scheduled
Warning
What Gets Checked
The alert queries PSPRCSRQST for all process requests that have a recurrence name assigned. It then groups these requests by:
Process Name (PRCSNAME)
Run Control ID (RUNCNTLID)
User ID (OPRID)
Recurrence Name (RECURNAME)
For each unique combination, if the latest instance has a completed status and there are no active/pending requests (such as Queued, Blocked, Hold, Pending, Initiated, or Processing) to follow, the recurrence is flagged as stalled.
Alert Details
When firing, the alert produces an item for each stalled recurrence:
Summary: Recurrence RECURNAME for PRCSNAME — Stalled (Last status: STATUS)
Details:
prcsName: The process name
runCntlId: The run control ID
oprid: The user ID that submitted the process
recurName: The recurrence definition name
lastInstance: The process instance number of the last run
lastRunStatus: The status of the last run (e.g. Success, Error)
lastRunDttm: The date and time the last run was scheduled
Configuration
alerts:checks:stalled_recurrences:enabled:truelookbackHours:336# How far back to look for completed runs (14 days)
Setting
Default
Description
lookbackHours
336
How many hours back to look for the last completed run of a recurrence.
How to Respond
Click the link in the alert detail to view the last process instance in the Process Monitor.
Check the logs for that instance if the status was an error.
If the recurrence should continue running, go to PeopleSoft and submit the process again on the same recurrence name using the matching User ID and Run Control ID.
If the recurrence has intentionally finished its life cycle (e.g., reached its end date), you can ignore the warning or configure the process in the exclusions list.
Integration Broker alerts monitor your PeopleSoft IB infrastructure for errors, stalled messages, volume anomalies, and sync exceptions.
Where to start. For a new environment, enable IB Down, IB Dispatcher Down, IB No Active Domain, and IB Operation Errors first. These four catch the conditions that produce the most pages. Add stalled checks after tuning thresholds for your operations. Volume checks need 24 hours of history before they fire usefully.
Message nodes registered as down in PSNODESDOWN with blocked transactions
9.2.1 - IB Operation Errors
This alert finds asynchronous Integration Broker operation instances that are in Error or Timeout status within a configurable lookback window.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert finds asynchronous Integration Broker operation instances that are in Error or Timeout status within a configurable lookback window. These are messages that attempted to process but did not complete successfully.
An IB operation instance represents a single execution of a Service Operation through the Integration Broker. When an instance errors, the message did not reach its destination. The original publish/subscribe data is preserved in the IB tables and can usually be resubmitted from the Service Operations Monitor.
Severity Logic
Status
Severity
Error
Critical
Timeout
Warning
Error status means the processing actively failed. Timeout means it ran out of time, which may be a transient issue but still warrants investigation.
Alert Details
Each alert item includes:
Operation instance ID
Service operation name
Status (Error or Timeout)
The originating node
When the instance was created
A link to the IB Monitor detail page
Configuration
alerts:checks:ib_operation_errors:enabled:truelookbackHours:24# How far back to look for errorsexcludeOperations:# Operation names to skip- SOME_NOISY_OPERATION
Setting
Default
Description
lookbackHours
24
Number of hours back to search for error/timeout instances
excludeOperations
[]
List of IB operation names to exclude from this check
How to Respond
Click the alert link to go to the IB Monitor entry for the failed operation
Review the error details. The IB Monitor shows the error message or exception
Check whether this is a configuration issue (wrong endpoint, auth failure) or a data issue
If the message needs to be reprocessed, you can do so from PeopleSoft’s Service Operations Monitor
If this is a recurring operation, investigate the root cause before errors pile up
Relationship to Other IB Alerts
This alert finds operations that have already ended in error. For operations that are stuck in progress, see IB Operations Stalled.
For similar alerts on publication and subscription contracts, see:
This alert finds asynchronous Integration Broker operation instances that are stuck in New or Working status and have been in that state longer tha…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert finds asynchronous Integration Broker operation instances that are stuck in New or Working status and have been in that state longer than the configured threshold. These are messages that started processing (or are waiting to be processed) but have not completed in a reasonable amount of time.
Cross-reference with IB Dispatcher Down first. A stalled queue plus a down dispatcher is almost always the dispatcher.
Severity Logic
Condition
Severity
Stuck longer than thresholdMinutes
Warning
Stuck longer than thresholdMinutes × 2
Critical
For example, with the default threshold of 30 minutes:
An operation stuck for 35 minutes → Warning
An operation stuck for 65 minutes or more → Critical
Alert Details
Each alert item includes:
Operation instance ID
Service operation name
Current status (New or Working)
How long it has been stuck (in minutes)
The originating node
A link to the IB Monitor detail page
Configuration
alerts:checks:ib_operation_stalled:enabled:truethresholdMinutes:30# Minutes before flagging as WarningexcludeOperations:# Operation names to skip- BULK_SYNC_OPERATION
Setting
Default
Description
thresholdMinutes
30
Minutes an operation must be stuck to trigger a Warning. Critical fires at 2× this value.
excludeOperations
[]
List of IB operation names to exclude from this check. Use for known long-running operations.
How to Respond
Click the alert link to go to the IB Monitor entry for the stalled operation
Check whether the IB dispatcher/handlers are running on the PeopleSoft application server
Look for signs of a larger IB backlog (many operations in New status)
Check the gateway and connector configuration if the operation can’t reach a node
If the operation is safe to reprocess, you can cancel and resubmit from PeopleSoft’s Service Operations Monitor
Relationship to Other IB Alerts
This alert finds operations that are stuck in progress. For operations that have already ended in error, see IB Operation Errors.
For similar alerts on publication and subscription contracts, see:
This alert finds Integration Broker publication contracts that are in Error or Timeout status within a configurable lookback window.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert finds Integration Broker publication contracts that are in Error or Timeout status within a configurable lookback window.
In the PeopleSoft Integration Broker architecture, a publication contract tracks the delivery of a published message to a specific subscribing node. When a publication contract fails, it means a message that PeopleSoft published was not successfully delivered to one or more subscribers.
When This Matters
Publication contract errors typically mean:
An outbound message from PeopleSoft was not delivered to a downstream system
An integration partner did not receive data it was expecting
A workflow or data sync that depends on this message may be incomplete
Severity Logic
Status
Severity
Error
Critical
Timeout
Warning
Alert Details
Each alert item includes:
Publication contract ID
Service operation name
Status (Error or Timeout)
The target subscribing node
When the contract was created
A link to the IB Monitor detail page
Configuration
alerts:checks:ib_pub_contract_errors:enabled:truelookbackHours:24# How far back to look for errorsexcludeOperations:# Operation names to skip- HIGH_VOLUME_SYNC
Setting
Default
Description
lookbackHours
24
Number of hours back to search for error/timeout contracts
excludeOperations
[]
List of IB operation names to exclude from this check
How to Respond
Click the alert link to go to the IB Monitor entry for the failed contract
Review the error details. The IB Monitor shows the error message
Check whether the target subscribing node is reachable and its connector is configured correctly
This alert finds Integration Broker publication contracts that are stuck in New or Working status and have not progressed beyond that state within …
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert finds Integration Broker publication contracts that are stuck in New or Working status and have not progressed beyond that state within the configured threshold.
A stalled publication contract means PeopleSoft has published a message to a subscriber, but the delivery has not completed. The message is either waiting to be picked up (New) or is in the process of being delivered but taking too long (Working).
alerts:checks:ib_pub_contract_stalled:enabled:truethresholdMinutes:30# Minutes before flagging as WarningexcludeOperations:# Operation names to skip- LARGE_BATCH_SYNC
Setting
Default
Description
thresholdMinutes
30
Minutes a contract must be stuck to trigger a Warning. Critical fires at 2× this value.
excludeOperations
[]
List of IB operation names to exclude. Use for operations that legitimately take a long time.
How to Respond
Click the alert link to go to the IB Monitor entry for the stalled contract
Check whether the IB dispatchers are running on the PeopleSoft application server
Look for a larger backlog (many contracts in New status may mean the dispatcher is down)
Check whether the target node’s endpoint is reachable
Review connector configuration for the target node
This alert finds Integration Broker subscription contracts that are in Error or Timeout status within a configurable lookback window.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert finds Integration Broker subscription contracts that are in Error or Timeout status within a configurable lookback window.
In the PeopleSoft Integration Broker architecture, a subscription contract tracks the processing of an inbound message by a subscribing handler. When a subscription contract fails, it means PeopleSoft received a message from an external system but was unable to process it completely.
When This Matters
Subscription contract errors typically mean:
An inbound message from an integration partner was not fully processed
PeopleSoft was unable to apply the data changes the message carried
A business process that depends on this message may be incomplete or in an error state
Severity Logic
Status
Severity
Error
Critical
Timeout
Warning
Alert Details
Each alert item includes:
Subscription contract ID
Service operation name
Status (Error or Timeout)
The originating (publishing) node
When the contract was created
A link to the IB Monitor detail page
Configuration
alerts:checks:ib_sub_contract_errors:enabled:truelookbackHours:24# How far back to look for errorsexcludeOperations:# Operation names to skip- KNOWN_RETRY_OPERATION
Setting
Default
Description
lookbackHours
24
Number of hours back to search for error/timeout contracts
excludeOperations
[]
List of IB operation names to exclude from this check
How to Respond
Click the alert link to go to the IB Monitor entry for the failed contract
Review the error details. The IB Monitor typically shows the exception or error message from the handler PeopleCode
Check the subscription handler code for the operation (viewable in the Service Operation detail page in psLens)
Investigate whether the data in the message is valid. Handler errors often come from unexpected data
If the subscription can be safely reprocessed, resubmit from PeopleSoft’s Subscription Contracts Monitor
This alert finds Integration Broker subscription contracts that are stuck in New or Working status and have not progressed beyond that state within…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert finds Integration Broker subscription contracts that are stuck in New or Working status and have not progressed beyond that state within the configured threshold.
A stalled subscription contract means PeopleSoft received an inbound message from an external system, but has not yet finished processing it. The message is either waiting to be handled (New) or is in the process of being handled but taking too long (Working).
When This Matters
For sub contracts, the most common cause specific to this alert is subscription handler PeopleCode that runs unusually long or waits on an external resource. For broader IB-side causes (dispatcher down, backlog), cross-reference IB Dispatcher Down and IB Operations Stalled.
Severity Logic
Condition
Severity
Stuck longer than thresholdMinutes
Warning
Stuck longer than thresholdMinutes × 2
Critical
Alert Details
Each alert item includes:
Subscription contract ID
Service operation name
Current status (New or Working)
How long it has been stuck (in minutes)
The originating (publishing) node
A link to the IB Monitor detail page
Configuration
alerts:checks:ib_sub_contract_stalled:enabled:truethresholdMinutes:30# Minutes before flagging as WarningexcludeOperations:# Operation names to skip- BULK_INBOUND_SYNC
Setting
Default
Description
thresholdMinutes
30
Minutes a contract must be stuck to trigger a Warning. Critical fires at 2× this value.
excludeOperations
[]
List of IB operation names to exclude. Use for known long-running handlers.
How to Respond
Click the alert link to go to the IB Monitor entry for the stalled contract
Check whether the IB dispatchers are running on the PeopleSoft application server
Look for a broader backlog. Many New contracts may mean no dispatcher is running
Check application server logs for errors in the subscription handler
For Working contracts, check whether the handler PeopleCode is looping or waiting on an external resource
This alert detects when the volume of IB async operation instances (PSAPMSGPUBHDR) is significantly higher than the rolling historical average.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert detects when the volume of IB async operation instances (PSAPMSGPUBHDR) is significantly higher than the rolling historical average.
A sudden volume spike may indicate a runaway integration sending messages in a loop, an upstream system retrying failed messages, or an unusually large but legitimate batch publish event.
How Baselining Works
psLens maintains a rolling history of up to 288 volume snapshots (approximately 24 hours at a 5-minute check interval). Each check cycle records the current message count for the lookback window.
Once at least 6 baseline snapshots have accumulated, the alert begins comparing the current count against the historical average. This prevents false alerts during the first few minutes after psLens starts.
Severity Logic
Condition
Severity
Volume exceeds average by >= thresholdPercent
Warning
Volume exceeds average by >= thresholdPercent x 2
Critical
Historical average is 0 and current count is > 0
Warning
For example, with the default threshold of 50%:
Current count is 75% above average → Warning
Current count is 100%+ above average → Critical
Configuration
alerts:checks:ib_operation_volume:enabled:truelookbackHours:1# Window for counting current messagesthresholdCount:50# Percentage increase to trigger Warning
Setting
Default
Description
lookbackHours
1
Hours to look back when counting current message volume
thresholdCount
50
Percentage increase over historical average to trigger a Warning alert. Critical fires at 2x this value.
Alert Details
Each alert item includes:
Current message count for the lookback window
Historical average count
Percentage increase above average
Number of baseline samples used
Link to the IB Monitor page
How to Respond
Navigate to the IB Monitor in psLens to see which operations are generating the volume
Check if any operations are in Error or Stalled status (see related IB alerts)
Review the specific operations with high message counts to determine if the volume is expected
If a runaway integration is identified, investigate the upstream system sending the messages
This alert detects when the volume of IB publication contracts (PSAPMSGPUBCON) is significantly higher than the rolling historical average.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert detects when the volume of IB publication contracts (PSAPMSGPUBCON) is significantly higher than the rolling historical average. Publication contracts represent messages being delivered to subscribing nodes, so a spike here can indicate unexpected fan-out, retries, or a high-volume event.
A sudden volume spike may indicate repeated retries of failed contracts inflating the count, an upstream system publishing in a loop, or a legitimate but unusually large batch publication event.
How Baselining Works
psLens maintains a rolling history of up to 288 volume snapshots (approximately 24 hours at a 5-minute check interval). Each check cycle records the current publication contract count for the lookback window.
Once at least 6 baseline snapshots have accumulated, the alert begins comparing the current count against the historical average.
Severity Logic
Condition
Severity
Volume exceeds average by >= thresholdPercent
Warning
Volume exceeds average by >= thresholdPercent x 2
Critical
Historical average is 0 and current count is > 0
Warning
For example, with the default threshold of 50%:
Current count is 75% above average → Warning
Current count is 100%+ above average → Critical
Configuration
alerts:checks:ib_pub_contract_volume:enabled:truelookbackHours:1# Window for counting current contractsthresholdCount:50# Percentage increase to trigger Warning
Setting
Default
Description
lookbackHours
1
Hours to look back when counting current contract volume
thresholdCount
50
Percentage increase over historical average to trigger a Warning alert. Critical fires at 2x this value.
Alert Details
Each alert item includes:
Current publication contract count for the lookback window
Historical average count
Percentage increase above average
Number of baseline samples used
Link to the IB Monitor page
How to Respond
Navigate to the IB Monitor in psLens to see which publication contracts are generating the volume
This alert fires when the SWS endpoint returns a connection error, timeout, 404, or 5xx.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert fires when the SWS endpoint returns a connection error, timeout, 404, or 5xx. psLens cannot fetch IB data without SWS, so this also blocks every other psLens IB check. A connection failure indicates that the Integration Broker gateway, local node, or application server is down.
Severity Logic
Condition
Severity
SWS connection attempt fails
Critical
What Gets Checked
The alert invokes the standard SWS connection test method. If it receives any network connection error (e.g., HTTP gateway timeout, connection refused, dns resolving failure, or HTTP 404/500 errors), a Critical alert is raised immediately.
Alert Details
Each alert item includes:
The base REST URL of the SWS endpoint (baseURL)
The raw network or connection error message
Troubleshooting links to verify connection settings
Configuration
alerts:checks:ib_down:enabled:true
Setting
Default
Description
enabled
true
Whether this check is active.
How to Respond
Verify that the PeopleSoft Web Server and PIA are up and running.
Check the Integration Gateway web application status (typically /PSIGW/PeopleSoftListeningConnector).
Ensure that the application server domain is booted and the Integration Broker handlers/dispatchers are active.
Verify there are no firewalls, proxies, or security policies blocking outbound HTTPS traffic from the psLens server to the Integration Broker gateway port.
Inspect the basic auth credentials in the config.yaml to ensure the API service user has not expired or been locked.
9.2.10 - Abnormal IB Subscription Contract Volume
This alert detects when the volume of IB subscription contracts (PSAPMSGSUBCON) is significantly higher than the rolling historical average.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert detects when the volume of IB subscription contracts (PSAPMSGSUBCON) is significantly higher than the rolling historical average. Subscription contracts represent inbound messages being processed by local subscribers, so a spike here can indicate a flood of inbound messages, excessive retries, or an integration firing more frequently than expected.
How Baselining Works
psLens maintains a rolling history of up to 288 volume snapshots (approximately 24 hours at a 5-minute check interval). Each check cycle records the current subscription contract count for the lookback window.
Once at least 6 baseline snapshots have accumulated, the alert begins comparing the current count against the historical average.
Severity Logic
Condition
Severity
Volume exceeds average by >= thresholdPercent
Warning
Volume exceeds average by >= thresholdPercent x 2
Critical
Historical average is 0 and current count is > 0
Warning
For example, with the default threshold of 50%:
Current count is 75% above average → Warning
Current count is 100%+ above average → Critical
Configuration
alerts:checks:ib_sub_contract_volume:enabled:truelookbackHours:1# Window for counting current contractsthresholdCount:50# Percentage increase to trigger Warning
Setting
Default
Description
lookbackHours
1
Hours to look back when counting current contract volume
thresholdCount
50
Percentage increase over historical average to trigger a Warning alert. Critical fires at 2x this value.
Alert Details
Each alert item includes:
Current subscription contract count for the lookback window
Historical average count
Percentage increase above average
Number of baseline samples used
Link to the IB Monitor page
How to Respond
Navigate to the IB Monitor in psLens to see which subscription contracts are generating the volume
This alert triggers when no active message domains are found in the Integration Broker.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert triggers when no active message domains are found in the Integration Broker. In PeopleSoft, message domains correspond to individual application servers running the Integration Broker background processes. If there are no active domains, Integration Broker cannot route, dispatch, or process any asynchronous publication or subscription messages.
Severity Logic
Condition
Severity
No message domains are in “Active” status
Critical
What Gets Checked
The alert queries the PSAPMSGDOMSTAT table to retrieve all registered domains. It counts the domains where the status is "A" (Active). If the count of active domains is zero, it triggers a Critical alert.
Alert Details
Each alert item includes:
The total count of registered domains
A list of inactive domains along with their machine names and app server paths
A link to the Integration Broker Monitor on the dashboard to inspect the domain statuses
Configuration
alerts:checks:ib_no_active_domain:enabled:true
Setting
Default
Description
enabled
true
Whether this check is active.
How to Respond
Log into the PeopleSoft server or use PSAdmin to check the status of the application server domains.
Verify if the Quick-Start or normal app server configuration has Integration Broker (Pub/Sub) processes enabled.
If the application server was recently restarted, check if the domains were configured to boot automatically or if they need to be booted manually.
Check system logs for application server boot crashes, memory errors, or database connection failures.
9.2.12 - IB Dispatcher Down
This alert monitors Integration Broker dispatcher processes (such as the publication dispatcher, subscription dispatcher, or handler dispatchers) o…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert monitors Integration Broker dispatcher processes (such as the publication dispatcher, subscription dispatcher, or handler dispatchers) on active domains and triggers when any dispatcher is inactive or has stopped reporting health updates.
When a dispatcher process is down, messages assigned to that dispatcher fail to process and queue up indefinitely, leading to a backlog.
Severity Logic
Condition
Severity
Dispatcher status is not active, or no health update within thresholdMinutes
Warning
Dispatcher has not updated health status for more than thresholdMinutes × 2
Critical
For example, with the default threshold of 10 minutes:
No health update for 11 minutes → Warning
No health update for 20+ minutes → Critical
What Gets Checked
The alert queries PSAPMSGDSPSTAT for dispatcher process statuses. For each dispatcher associated with an Active domain (from PSAPMSGDOMSTAT), it verifies:
The status string is "ACT" (Active).
The health timestamp (DspHealthDttm) has been updated within the threshold window.
Note: Dispatchers on inactive domains are ignored by this check (they are covered by the IB No Active Domain check).
Alert Details
Each alert item includes:
Dispatcher process name
Physical machine/host name
App server path
The last updated health timestamp
Reason for the down status (e.g. status not active, or elapsed minutes since last update)
Minutes a dispatcher can go without updating health before raising a Warning. Critical fires at 2× this threshold.
How to Respond
Go to the Integration Broker Monitor on the psLens dashboard to identify which specific dispatcher on which host is failing.
Log into the affected PeopleSoft application server and check the status of the dispatcher processes via PSAdmin.
Review the application server and Pub/Sub subdirectories log files (such as APPSRV.log, TUXLOG, or stderr / stdout logs) for crashes, Tuxedo errors, or database lockups.
Restart the Pub/Sub processes on the application server if the dispatcher has locked up or crashed.
9.2.13 - IB Sync Operation Exceptions
This alert detects synchronous IB service operations that have logged errors in the sync transaction log (PSIBLOGHDR) within the configured lookbac…
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert detects synchronous IB service operations that have logged errors in the sync transaction log (PSIBLOGHDR) within the configured lookback window. Results are aggregated by operation name to avoid noise from high-volume sync operations that may have individual errors but function normally overall.
Unlike async IB errors (which create persistent queue entries), sync operation errors are logged transiently in PSIBLOGHDR. Without active monitoring, these errors are often missed until a consuming system reports a problem.
Severity Logic
All findings are reported at Warning severity. Since synchronous request-response transactions are executed in real time, any error must be handled and logged by the calling HTTP client. Administrators generally cannot resolve these errors from within PeopleSoft, as the client must reinitiate the transaction.
What Gets Checked
The alert queries PSIBLOGHDR for records with error status within the lookback window, aggregated by IB operation name. Only operations with at least one error are reported. Operations in the exclude list are skipped.
Alert Details
Each alert item includes:
Service operation name (with link to Service Operation detail page)
Number of errors in the lookback window
Lookback window in hours
Configuration
alerts:checks:ib_sync_exceptions:enabled:falselookbackHours:24# How far back to check for sync errorsexcludeOperations:[]# Operation names to ignore
Setting
Default
Description
enabled
false
Enable or disable the sync exception checker
lookbackHours
24
Hours to look back for sync operation errors
excludeOperations
[]
List of operation names to exclude from this check
How to Respond
Click the alert link to open the Service Operation detail page
Review the operation’s handler configuration and routing
Check PSIBLOGHDR directly for the specific error messages (psLens links to the operation, not individual log entries)
Verify that the operation’s service handler is still functional and the underlying code has not changed
Contact the calling system to understand whether they are seeing failures on their end
The PSIBLOGHDR table must be whitelisted in the PeopleSoft SWS framework on each target environment. Sync logging must be enabled on the relevant routings. If logging is disabled, errors will not appear in PSIBLOGHDR. See the Sync Operations Without Logging report to find operations where logging may be disabled.
Tables Queried
Table
Description
PSIBLOGHDR
IB sync transaction log headers
9.2.14 - IB Nodes Down
This alert triggers when there are entries in the PeopleSoft table PSNODESDOWN.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert triggers when there are entries in the PeopleSoft table PSNODESDOWN. An entry in this table indicates that a message node is blocked or offline.
When the Integration Broker attempts to publish a message to an external or remote node and the connection fails, the system registers the node as “down” in PSNODESDOWN. While the node is down, all subsequent publication contracts to that node are automatically paused/blocked and remain queued in the database until the node status is resolved.
Severity Logic
Condition
Severity
Message node entry exists in PSNODESDOWN
Critical
What Gets Checked
The alert queries PSNODESDOWN for any active rows. For each row found, it groups the results by message node and counts the number of blocked transactions.
Alert Details
Each alert item includes:
The name of the offline message node
The count of blocked transactions queueing for the node
A link to the Node detail page in the browser showing connection diagnostics
Configuration
alerts:checks:ib_nodes_down:enabled:true
Setting
Default
Description
enabled
true
Whether this check is active.
How to Respond
Click the node link in the alert to inspect the node configuration and test connectivity.
Check if the external target service (e.g. an external API gateway, third-party system, or another PeopleSoft application node) is offline or undergoing maintenance.
Verify network routing and gateway connector configurations.
Once the external endpoint is confirmed to be healthy, delete the down-node status entry in PeopleSoft (typically via the Service Operations Monitor > Administration > Nodes Down page) and resubmit or force retry the stalled publication contracts.
9.3 - Security
Security alerts: failed login detection and authentication monitoring.
Security alerts monitor your PeopleSoft environment for authentication issues and suspicious login activity.
Users with excessive failed login attempts in PSPTLOGINAUDIT
9.3.1 - Failed Logins
This alert finds PeopleSoft users with excessive failed login attempts by querying the PSPTLOGINAUDIT table.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
This alert finds PeopleSoft users with excessive failed login attempts by querying the PSPTLOGINAUDIT table. It only reports users whose most recent login attempt was a failure (PT_SIGNON_STATUS = 1).
PSPTLOGINAUDIT stores only the last login state per user. Once a user successfully logs in, their failure count resets. This means the alert reflects the current state: users who are actively failing to log in right now.
A high number of failed logins may indicate:
A brute-force attack against a user account
A user who has forgotten their password
An integration or batch account with stale credentials
An account lockout situation that needs admin attention
Severity Logic
Condition
Severity
Failed logins >= thresholdCount
Warning
Failed logins >= thresholdCount x 2
Critical
For example, with the default threshold of 5:
A user with 6 failed logins -> Warning
A user with 10 or more failed logins -> Critical
What Gets Checked
The alert queries PSPTLOGINAUDIT for rows where:
PT_SIGNON_STATUS = '1' (last attempt was a failure)
FAILEDLOGINS >= threshold (failed count meets or exceeds the configured threshold)
Results are ordered by FAILEDLOGINS descending (highest failure counts first).
Alert Details
Each alert item includes:
Signon ID (PTSIGNONID) — the username entered at the login screen
OPRID — the resolved PeopleSoft user ID
Number of failed login attempts
Authentication type (Token/SSO, Signon PeopleCode, or Standard)
Timestamp of the last failed login attempt
A link to the User detail page (when the OPRID is resolved)
Configuration
alerts:checks:failed_logins:enabled:truethresholdCount:5# Failed attempts before flagging as Warning
Setting
Default
Description
thresholdCount
5
Number of failed logins to trigger a Warning alert. Critical fires at 2x this value.
How to Respond
Click the alert link to go to the User detail page for the affected account
Check the authentication type. Token/SSO failures may indicate a misconfigured integration
Review the timestamp. Recent failures are more concerning than old ones
Check if the user’s account is locked (ACCTLOCK in PSOPRDEFN)
If the failures look like a brute-force attempt, consider locking the account and investigating the source
For legitimate users, help them reset their password and unlock their account
The PSPTLOGINAUDIT table must be whitelisted in the PeopleSoft SWS framework on each target environment. If the table is not whitelisted, this alert will log an error on each check cycle but will not affect other alerts.
9.4 - Web Server / WebLib Down
psLens POSTs to one or more configured WebLib or IScript URLs every check cycle.
New to psLens? This page documents one specific alert. To see how it appears on the dashboard,
what operators investigate, and how teams tune it, start with a live walkthrough.
Alert ID:weblib_downCategory: Web Server / WebLib
Default threshold: Immediate
What This Alert Detects
psLens POSTs to one or more configured WebLib or IScript URLs every check cycle. If any target connection fails or returns a 5xx, the alert fires Critical.
By default, the checker tests the standard delivered WebLib endpoint:
WEBLIB_PTBR.ISCRIPT1.FieldFormula.IScript_StartPage
If the Web Server is down, or if the whitelisted API service account loses security access to the tested WebLib, the alert triggers immediately.
Severity Logic
Condition
Severity
Target URL is unreachable or connection times out
Critical
Target WebLib returns an HTTP status code >= 500 (Internal Server Error)
Critical
Note: HTTP statuses like 200 (Success), 401 (Unauthorized), 403 (Forbidden), or 302 (Redirect) indicate the Web Server is active and processing requests; they do not trigger a down alert.
What Gets Checked
For each target URL configured in weblibTestTargets:
It sends an HTTP POST request with a 10-second timeout.
It applies HTTP Basic Authentication using either target-specific credentials or default database connection credentials.
It registers a failure if the request fails to connect or returns a status code in the 5xx range.
List of target configurations. Each target requires a url and optional username / password overrides.
How to Respond
Verify whether the PeopleSoft Web Server (WebLogic or WebSphere) process is booted and running.
Check if there are network outages, load balancer failures, or firewall changes between the psLens server and the PIA URL.
If the server is reachable but returning a weblib_down alert, verify that the configured PeopleSoft service account has security clearance (assigned Permission Lists) to access the target WebLib.
9.5 - Generic SWS Alerts
Generic SWS Alerts let you define alert checks in YAML using PsoftQL queries against whitelisted PeopleSoft records.
Generic SWS Alerts
Generic SWS Alerts let you define alert checks in YAML using PsoftQL queries against whitelisted PeopleSoft records. Use these when you need a one-off check that the built-in alert types don’t cover.
The scheduler runs each query on the database’s checking interval and triggers alerts based on the resulting row counts.
Configuration Properties
Generic alerts are configured under the genericSWSAlerts list, either globally under alerts or overridden per-database under databases[].alerts.
Property
Type
Required
Default
Description
id
String
Yes
-
Unique alphanumeric identifier. The system registers the alert internally as generic_sws_<id>.
name
String
Yes
-
Friendly name shown on the dashboard and in reports (e.g. Stale Admins).
enabled
Boolean
No
true
Toggle execution of this generic alert.
severity
String
No
warning
Severity of the alert when triggered: info, warning, or critical.
alertOn
String
No
row_found
Condition to trigger the alert: row_found (trigger if row count > 0) or no_result_found (trigger if row count == 0).
message
String
Yes
-
Summary message shown on the dashboard and sent in notifications when the alert triggers.
For security, the SWS client restricts query capabilities to a defined list of records. Every record/table referenced in a generic alert query must be whitelisted in the psLens whitelisting table (CHG_PSLENS_WL) on the target PeopleSoft database.
If a query references a record that is not whitelisted, the alert run will fail with a whitelisting validation error.
PsoftQL Query Structure
The query property follows the exact structure of a psLens PsoftQLRequest query:
Property
Type
Description
records
Array
List of record configurations to query (can be nested for joins).
rowLimit
Integer
Max rows to return (recommended to keep low, e.g. 5 or 10).
orderBy
String
SQL ORDER BY clause for sorting findings.
noEffectiveDateLogic
Boolean
Set true to skip automatic EFFDT filtering logic.
noEffectiveStatusLogic
Boolean
Set true to skip automatic EFF_STATUS = 'A' filtering logic.
Record Configuration (records[])
recordName (String, Required): PeopleSoft record name (e.g., PSOPRDEFN).
excludeFields (List, Optional): Field names to exclude from results.
Practical Examples
Example 1: Critical Administrative Account Access (Row Found)
This alert triggers a Critical warning if an administrator account has been modified recently, or if a locked/inactive operator is seen initiating processes.
alerts:genericSWSAlerts:- id:"locked_oprid_activity"name:"Locked Admin Activity"enabled:trueseverity:"critical"alertOn:"row_found"message:"Security warning: Activity detected from locked operator accounts!"query:records:- recordName:"PSPRCSRQST"sqlWhereClause:"RUNDTTM > CAST(SYSDATE - 1 AS DATE) AND OPRID IN (SELECT OPRID FROM PSOPRDEFN WHERE ACCTLOCK = 1)"rowLimit:5
Example 2: Process Scheduler Daemon Down (No Result Found)
This alert triggers a Critical warning if no process scheduler daemon has updated its status in the last 15 minutes, indicating that the scheduler might be down.
alerts:genericSWSAlerts:- id:"scheduler_daemon_down"name:"Process Scheduler Daemon Status"enabled:trueseverity:"critical"alertOn:"no_result_found"message:"Alert: No active process scheduler daemons detected in the last 15 minutes!"query:records:- recordName:"PSSERVERDEFN"sqlWhereClause:"LASTUPDDTTM > CAST(SYSDATE - 1/96 AS DATE)"# 15 minutes lookbackrowLimit:1
Notification Routing
To route notifications for a generic SWS alert, use its registered ID (generic_sws_<id>) in the alertTypes property of your notification subscription:
psLens reference material: PeopleSoft tables, configuration options, and technical details.
Reference
This section contains reference material for understanding psLens internals and the PeopleSoft tables it works with.
PeopleSoft Tables Used by psLens
The following tables list every PeopleSoft metadata and operational table that psLens queries through the SWS framework. All of these must be whitelisted (see Installation for the full whitelist SQL).
If you add a new query against a PeopleSoft record in the code, add it to the appropriate category below and add a matching INSERT to the installation guide.
Security Tables
Table
Description
Used By
PSCLASSDEFN
Permission list definitions
Permission Lists browser, Full Access report, PeopleTools Access report
PSAUTHITEM
Menu / component authorizations per permission list
Menu item transfer destinations (target menu / component / page / portal / node) — keyed on MENUNAME + ITEMNAME only (no BARNAME). Populated for PSMENUITEM.ITEMTYPE = 12 (Transfer) items.
Menus detail
PSPROJECTDEFN
Project definitions
Projects browser
PSPROJECTITEM
Items contained in a project
Projects detail, App Packages detail
PSBCDEFN
Component Interface definitions
Component Interfaces browser
PSBCITEM
Component Interface property and method items
Component Interfaces detail
PSPRSMDEFN
Component Reference (CREF) and folder definitions
Components detail, Component References
PSPRSMSYSATTR
Component Reference system attributes
Component References detail
PSPRSMSYSATTRVL
Component Reference system attribute values
Component References detail
PSPRSMATTRVAL
Component Reference custom attribute values
Component References detail
PSPRSMPERM
Component Reference permission list mappings
Component References detail
PSPRUFDEFN
Portal user favorites
Users detail
PSRECDDLPARM
Record DDL parameter overrides per database platform
Records detail
PSIDXDDLPARM
Index DDL parameter overrides per database platform
Records detail
PSSPCDDLPARM
Tablespace DDL parameter overrides per database platform
Records detail
PSDDLMODEL
DDL statement model creation templates per database platform
Records detail
PSDDLDEFPARMS
Default DDL model parameters per database platform
Records detail
PSOPTIONSADDL
Additional platform DDL build options
Records detail
PSTBLSPCCAT
Database tablespace catalog definitions
Records detail
PSRECTBLSPC
Explicit record-to-tablespace assignments per database
Records detail
PSFLDDEFN
File Layout header definition table
File Layouts browser & detail
PSFLDSEGDEFN
File Layout segment hierarchy and file-record mapping table
File Layouts detail
PSFLDFIELDDEFN
File Layout field attributes, positions, and formatting masks table
File Layouts detail
PSXPRPTDEFN
BI Publisher report definitions
BI Publisher browser & detail
PSXPDATASRC
BI Publisher data source definitions
BI Publisher detail
PSXPTMPLDEFN
BI Publisher template definitions
BI Publisher detail
PSXPTMPLFILEDEF
BI Publisher template file definitions
BI Publisher detail
PSXPRPTVIEWER
BI Publisher report security viewers (Role/User distribution)
BI Publisher detail
Integration Broker Tables
Table
Description
Used By
PSMSGNODEDEFN
Message node definitions
Nodes browser, Nodes No Password report, Users detail (Special Use: nodes whose USERID = this OPRID)
PSNODECONPROP
Node connector properties
Nodes detail
PSNODEURITEXT
Node URI text
Nodes detail
PSNODESDOWN
Down message nodes and blocked transactions
Nodes detail, Nodes Down alert
PSSERVICE
Service definitions
Services browser
PSSERVICEOPR
Service operations within a service
Services detail, Application Services detail
PSOPERATION
Service operation definitions
Service Operations browser, Message Definitions detail
PSOPERATIONAC
Service operation handler access (status)
Service Operations detail
PSOPERATIONURI
Service operation URIs
Service Operations detail
PSOPRVERDFN
Service operation version definitions
Service Operations detail
PSOPRVERDFNPARM
Service operation version parameters
Service Operations detail, Queues detail
PSOPRHDLR
Service operation handler definitions
Service Operations detail
PSIBRTNGDEFN
Integration Broker routing definitions
Services detail, Nodes detail
PSIBAPPLDEFN
Application service (ASF) definitions
Application Services browser
PSIBAPPLOPR
Application service operations and handler classes
Application Services detail
PSIBAPPURI
Application service URI templates
Application Services detail
PSIBAPPMETHOD
Application service REST method configuration
Application Services detail
PSIBPARAM
Application service method parameters
Application Services detail
PSIBBASEPARAM
Application service base parameters
Application Services detail
PSIBTEMPLPARAM
Application service template parameters
Application Services detail
PSIBBASETMPLPRM
Application service base template parameters
Application Services detail
PSIBAPPLSTATES
Application service result state to HTTP status mappings
Queries detail (Execution Log panel), Users detail (Query History panel)
PSTREEDEFN
Query tree definitions
Query Trees browser
PSTREENODE
Query tree node structure
Query Trees detail
PSCHGCTLDEF
System-wide PeopleTools Change Control settings
Projects detail (Change Control Status panel)
PSCHGCTLLOCK
PeopleTools Change Control object checkout locks
Projects detail (Object Lock Info panel)
Audit & User Profile Tables
Table
Description
Used By
PSPTLOGINAUDIT
Sign-on / sign-off audit trail
Login Audit page
PSUSEREMAIL
User email addresses
Users detail
PSOPRALIAS
User ID alias mappings (Employee, Customer, Vendor, etc.)
Users compare tool
PSOPTIONS
System-wide options; OPRID is the user context for Signon PeopleCode pre-authentication
Users detail (Special Use card)
Campus Solutions Security Tables
Table
Description
Used By
OPR_DEF_TBL_CS
User Defaults CS (Institution, Career, Term, Aid Year, Business Unit)
Users detail (Campus Security card)
OPR_DEFAULT_TBL
3C User Defaults (Business Unit, SetID)
Users detail (Campus Security card)
OPR_GRP_3C_TBL
3C Group Security (Checklists, Comments, Communications)
Users detail (Campus Security card)
SCRTY_TBL_INST
Academic Institution Security per user ID
Users detail (Campus Security card)
SCRTY_TBL_CAR
Institution and Academic Career Security per user ID
Users detail (Campus Security card)
SCRTY_TBL_PROG
Academic Program Security per user ID
Users detail (Campus Security card)
SCRTY_TBL_PLAN
Academic Plan Security per user ID
Users detail (Campus Security card)
SCRTY_TBL_ACAD
Academic Organization Security per user ID
Users detail (Campus Security card)
SCRTY_TBL_STGP
Student Group Security per user ID
Users detail (Campus Security card)
SCRTY_TBL_SRVC
Service Indicator Security per user ID
Users detail (Campus Security card)
SCRTY_TBL_MLSTN
Milestones Security per user ID
Users detail (Campus Security card)
SCC_STY_TBL_CMP
Institution / Campus Security per user ID
Users detail (Campus Security card)
SCRTY_ADM_ACTN
Admissions Action Security per user ID
Users detail (Campus Security card)
SCRTY_PROG_ACTN
Program Action Security per user ID
Users detail (Campus Security card)
SCRTY_APPL_CTR
Application Center Security per user ID
Users detail (Campus Security card)
SCRTY_RECR_CTR
Recruiting Center Security per user ID
Users detail (Campus Security card)
SAD_TEST_SCTY
Admissions Test Load Security per user ID
Users detail (Campus Security card)
SCRTY_TSCRPT
Transcript Type Security per user ID
Users detail (Campus Security card)
SSR_SCRTY_TSRPT
Transcript Report Security per user ID
Users detail (Campus Security card)
SAA_SCRTY_AARPT
Advisement Report Security per user ID
Users detail (Campus Security card)
Configuration Reference
For the full config.yaml reference, see Configuration.
Alert Reference
For details on all alert types, see the Alerts section.
Report Reference
For details on all available reports, see the Reports section.
11 - Security & Trust
How psLens protects your PeopleSoft environment: read-only by design, table whitelist, dedicated instance per client, no direct database access.
psLens gives your team a window into PeopleSoft metadata. It cannot write to your database, it cannot query outside a whitelist you approve, and your instance does not share anything with anyone else’s.
The Short Version
Read-only by design. psLens never writes to PeopleSoft. There is no code path that issues INSERT, UPDATE, or DELETE against your environment.
No direct database credentials required. psLens connects to PeopleSoft through the SWS framework, which exposes a bounded REST API. Your database passwords stay on your side.
Query surface is whitelisted. psLens can only query PeopleTools metadata tables that are explicitly allowed. Anything off-list is rejected before it reaches PeopleSoft.
Dedicated instance per client. Each customer gets their own isolated deployment. No shared tenancy, no shared database, no cross-customer blast radius.
Your PeopleSoft business data stays in PeopleSoft. psLens stores alert history and report output only, nothing else.
Nothing is cached in the browser. Pages render server-side and stream over SSE. psLens writes nothing to LocalStorage, SessionStorage, or IndexedDB; closing the tab clears everything.
For the high-level picture of how psLens is deployed and how it talks to PeopleSoft, see the Architecture Overview. This page focuses on the security implications of that design.
How Queries Reach PeopleSoft
%%{init: {"flowchart": {"htmlLabels": true, "padding": 16, "nodeSpacing": 50, "rankSpacing": 60}}}%%
flowchart TD
APP["psLens app<br/>(dedicated instance per customer)"]
SWS["SWS framework<br/>(installed in your PeopleSoft environment)"]
DB[("PeopleSoft database<br/>(read-only)")]
APP -- "HTTPS + basic auth<br/>(token in config.yaml or env var)" --> SWS
SWS -- "psoftQL, scoped to<br/>whitelisted tables" --> DB
classDef ps fill:#e8f4fd,stroke:#0d6efd,stroke-width:2px,color:#000
classDef ext fill:#fff5e6,stroke:#fd7e14,stroke-width:2px,color:#000
class APP ext
class SWS,DB ps
Every query psLens issues flows through this path. There is no second channel. If the SWS framework is not installed, psLens cannot see anything.
Read-Only by Design
psLens reads metadata. It does not change anything in PeopleSoft, and it has no code path that could:
No administrative actions. Reports, alerts, and metadata browsing are all read operations.
No PeopleCode execution. psLens inspects configuration; it does not run it.
No project migration, no security grants, no user creation.
If you want to change something you see in psLens, you still do that in App Designer, PIA, or your existing change-management process.
Query Surface: The Table Whitelist
The SWS framework only responds to queries against tables that are explicitly whitelisted. psLens ships knowing which PeopleTools metadata tables it needs: PSRECDEFN, PSPNLDEFN, PSCLASSDEFN, PSAUTHITEM, process scheduler tables, Integration Broker tables, and similar (a known, published list).
A query that references any table outside the whitelist is rejected by SWS before it touches the database. This is enforced on your side of the connection, not the psLens side. Even if psLens were misconfigured, it could not reach into payroll, HR, financials, or any other transactional data.
When you add psLens to an environment, you see the whitelist and approve it. You can review or narrow it at any time.
Credential Handling
The SWS endpoint uses HTTP basic auth over HTTPS.
The auth token is stored in psLens config.yaml or injected through environment variables at deployment time.
No PeopleSoft database username or password is ever needed by psLens.
No single-sign-on tokens, session cookies, or end-user credentials are stored.
Rotating the SWS auth token is straightforward: rotate on the PeopleSoft side, update the psLens config or env var, restart the instance.
Deployment Isolation
Every psLens customer gets a dedicated deployment:
One instance per customer. No shared app, no shared database, no shared filesystem.
Hosted on fly.io by default, with deployment options to match your security requirements.
Your data does not traverse a shared service. There is no psLens SaaS multi-tenant backend.
If you prefer to host psLens yourself in your own cloud account or on-prem, that is supported — see installation for bare-metal and Docker options, including air-gapped environments.
What psLens Stores
psLens only persists two categories of data, and both stay inside your dedicated instance:
Alert history. A rolling record of alerts that fired, for trend review. Retention is configurable; defaults to a short window because alerts are meant to surface current issues.
Report output. The Markdown output of reports you have run, kept for 90 days so you can revisit audit findings or compare runs. See reports.
psLens does not copy PeopleSoft business data (employee records, financial transactions, HR data) into its own storage. Reports pull what they need at run time and summarize it; browsing and search fetch metadata on demand and display it.
What psLens Does NOT Do
It does not write to PeopleSoft.
It does not require a direct database connection.
It does not store PeopleSoft business data outside of alert and report output.
It does not share a database or application instance across customers.
It does not phone home. Your deployment talks to your PeopleSoft environment; it does not report back to Cedar Hills Group.
Going Deeper
This page is the short version. If you’re preparing a vendor security review or filling out a SIG / CAIQ, these pages cover the topics your reviewers will ask about: current state, gaps, and roadmap, stated plainly.
What SWS Installs in PeopleSoft. The objects, roles, and Integration Broker setup added to your environment, for the reviewer approving the install.
If a quick Q&A is all you need, the FAQ has one-paragraph answers cross-linked to the deeper pages above.
Questions Before a Demo?
If you have specific security or compliance questions (data residency, SWS role permissions on your PeopleSoft side, how to integrate with your existing SSO for the psLens login layer) raise them on the demo call or email chris.malek@cedarhillsgroup.com and we will answer in writing before you commit to anything.
11.1 - What SWS Installs in PeopleSoft
The objects, roles, and Integration Broker setup the SWS framework adds to a PeopleSoft environment. Written for the admin, DBA, or security reviewer who has to approve the install.
The psLens application connects to your PeopleSoft environments through a scoped, read-only subset of the SWS (Secure Web Services) framework delivered in the CHG_PSLENS Application Designer project. This page lists what installing the project changes in your environment, giving the administrator, DBA, or security reviewer the full footprint before anything is migrated. The step-by-step setup guide is at Installation.
The Install in One Paragraph
The CHG_PSLENS project is delivered as a standard Application Designer project. You import it into a development environment first, build the single whitelist table, test connectivity, and migrate it to TEST and PROD through your normal change-management path, the same way you move any other project. There is no installer, no agent, and no software on the database server. Plan for under an hour of PeopleSoft admin time for the first environment.
What the Project Contains
The project contains exactly 46 PeopleSoft objects, all namespaced with the CHG_ prefix (and one helper package named PsoftQL). It contains no custom pages, menus, components, or portal definitions, and no standalone fields.
Program classes for query parsing, serialization, and whitelist filtering
Schemas
5
Logical, XML, Document, JSON, and HTML schema definitions for CHG_SWS.PARAMS.V1
Total
46
Object details:
Record (1): CHG_PSLENS_WL, built as physical SQL table PS_CHG_PSLENS_WL. This is the only table created by the project. It stores the whitelist of PeopleTools records psLens can query.
Role (1) and Permission List (1): CHG_PSLENS_API_USER. Grants web-service authorization for the two service operations. It provides no access to PIA pages, components, queries, or processes.
Service Operations (2):
CHG_PSLENS_SWSPQL_POST — The primary read-only query endpoint. Accepts structured psoftQL requests (record names, field criteria, WHERE clauses, pagination) and returns data in JSON or XML.
CHG_PSLENS_METADATA_GET — Returns read-only environment metadata (such as PeopleTools version and IB sync log entries) that cannot be read directly from tables.
Application Packages (6) and PeopleCode (20): Contains serialization logic (CHG_ENCODING_TOOLS), HTTP request handling (CHG_HTTP), Integration Broker response formatting (CHG_IB), query execution and whitelist enforcement (CHG_PSLENS.PsoftQL), and utility helpers (CHG_UTILS).
No Pages or UI Objects: The project adds no pages, components, menus, or portal registry entries. Configuration is managed strictly by populating CHG_PSLENS_WL.
No Sample Data: The project ships only definition metadata. No sample rows, dummy records, or seed business data are imported.
Security Objects and the Service Account
psLens connects as a dedicated PeopleSoft operator you create for it (recommended name: CHG_PSLENS_API_USER). That account:
Holds the CHG_PSLENS_API_USER role, which assigns permission list CHG_PSLENS_API_USER to grant access to the two service operations and nothing else.
Has no access to PIA pages, query tools, process definitions, or database utilities.
Authenticates to the service operations with HTTP Basic Auth over HTTPS.
Is an ordinary PeopleSoft account, so your existing controls apply: lock it in PSOPRDEFN and all psLens access stops immediately.
No new database users are created. Nothing connects to the database directly; every query runs through the application server like any other Integration Broker request.
The Whitelist
SWS only answers queries against records listed in PS_CHG_PSLENS_WL. A query that references anything off-list is rejected before it reaches the database.
psLens needs roughly 130 PeopleTools metadata records whitelisted. The list is published in two places: the Reference page describes each record and which psLens feature uses it, and Whitelist Tables has the SQL inserts you run during installation. You run those inserts yourself, which means you review every record psLens will ever be able to read, and you can narrow the list at any time.
Integration Broker Setup
The two service operations come with routing definitions and handlers and run on your existing Integration Broker gateway. No new gateway, listening connector, or node is required. Because the traffic is ordinary REST service-operation traffic, it is visible in your IB monitoring tools alongside every other integration.
What to Tell Your DBA
All queries are reads against PeopleTools metadata tables on the whitelist. SWS has no write path for psLens to call.
Query volume is driven by on-demand page views plus a configurable alert interval (default every 5 minutes). See the load FAQ for the breakdown.
There is nothing to install or configure at the database layer. The change is entirely PeopleTools objects in App Designer plus building CHG_PSLENS_WL and inserting whitelist rows.
Questions
If your security team needs answers in writing before approving the install (object-by-object review, role configuration, whitelist scoping), raise it on the demo call or email chris.malek@cedarhillsgroup.com.
11.2 - Code & Supply Chain
What code runs in psLens, how it’s built and distributed, dependency posture, and the vulnerability disclosure & patching process.
This page is for security reviewers who need to understand what is running inside psLens before approving its deployment. It covers four questions:
What code is actually running?
Can we audit it?
How is it built and shipped?
How are vulnerabilities found, disclosed, and fixed?
If you’re looking for the higher-level read-only / whitelist story, start with Security & Trust and come back here for the detail.
1. What’s Inside the Image
psLens is a single Go binary plus an embedded NATS server, packaged as a multi-stage Docker image distributed from ghcr.io/cedarhillsgroup/pslens. There is no separate database, message broker, or external worker process; one container is the whole application.
Runtime stack
Component
Purpose
Go 1.27+
Application language; binary statically linked
gorilla/mux
HTTP routing
a-h/templ
Server-rendered HTML templates
Embedded NATS (nats-server/v2)
In-process key-value store for sessions, alerts, report output
data-star (datastar.dev)
Hypermedia / SSE for interactive UI; no SPA framework
Goldmark
Markdown rendering for report output
Standard library crypto/aes, crypto/tls
Encryption at rest and in transit
There is no embedded browser, no third-party telemetry SDK, no analytics tracker. The full dependency list is go.mod in the source tree.
Base image
The runtime stage is debian:bookworm-slim with ca-certificates. No shell access is required for normal operation; psLens runs as PID 1.
2. Source Availability and Review
psLens is closed-source. The source tree is not published publicly.
For customers who need to review the code: Cedar Hills Group offers a read-only source review under NDA as part of the procurement process. Mechanics (on-site, screen-share, time-boxed access) are agreed during contracting. Reach out via the contact page to arrange.
This is the same model used by most enterprise PeopleSoft tooling: the binary is yours to run, the source is reviewable under contract, redistribution is not granted.
The release pipeline injects the version, commit SHA, and ISO-8601 build timestamp into the binary at compile time via Go ldflags. You can read them back from any running instance via /healthz and the startup banner in container logs. Useful for confirming exactly which build a customer is running.
What we do today
Traceable builds. Every image embeds the git SHA and build timestamp in its label and binary; you can map any running container back to the exact source commit that produced it.
Pinned tag flavors. Production customers pin to vMAJOR.MINOR (or exact vMAJOR.MINOR.PATCH) so a docker compose pull never surprises them with a major-version change. See Deployment Options for the tag flavors and recommended pinning.
Private package distribution. GHCR access is gated by per-customer read-only fine-grained personal access tokens.
What we don’t do yet (roadmap)
Image signing with cosign. Planned. Once landed, every published tag will carry a sigstore-verifiable signature and you’ll be able to verify provenance with cosign verify.
go.mod is the single source of truth; all dependencies are pinned by version and content hash (go.sum).
Automated scanning. We run govulncheck daily and on every push/PR in our GitHub Actions CI pipeline to verify there are no known exploitable vulnerabilities in our dependencies.
Dependency monitoring. Dependabot is enabled to track Go modules, GitHub Actions, and Dockerfile base images, raising automated pull requests for updates.
The dependency footprint is intentionally narrow (see the table above); Go standard library does most of the work.
Affected version (the git SHA from /healthz is most precise)
Reproduction steps or proof-of-concept
Your assessment of severity (CVSS or descriptive)
We commit to:
Acknowledgement within 1 business day of receipt.
Coordinated disclosure. We will agree a disclosure window with the reporter before publishing details.
Crediting researchers in the release notes unless they prefer otherwise.
Patch SLA
Specific patch targets (business days for Critical, High, Medium) are disclosed during contracting.
When a fix ships, it goes out as a patch release in the same vMAJOR.MINOR stream you’re already pinned to. docker compose pull && docker compose up -d picks it up. Critical fixes are also announced by email to deployment contacts.
Subscribing to release notes
Release notes are published as GitHub Releases on the source repo. Deployment contacts are notified by email for any release with a security note.
6. What Reviewers Usually Ask
“Is the binary statically linked?” Yes. Go produces a static binary; no system library version drift.
“Does it phone home?” No. There is no outbound connection from a running psLens instance other than (a) to your SWS endpoint and (b) to your SMTP server if you’ve enabled magic-link auth. No telemetry, no update checks, no license-server callbacks.
“What user does it run as inside the container?” Confirm the current default with us on the demo call. Recommendation for self-hosters regardless: run with --user 1000:1000 and a read-only root filesystem; only /data needs to be writable.
“How big is the attack surface?” One HTTP listener (default port 8080 or whatever you configure), serving HTML and Server-Sent Events. No raw socket listeners, no UDP, no message-queue ingress, no plugin loader.
Inventory of third-party dependencies, open-source licenses, and downloadable CycloneDX SBOM for psLens.
This page documents all third-party software components compiled into the psLens binary or embedded as client assets.
A machine-readable Software Bill of Materials in standard CycloneDX v1.6 format is generated automatically during the build process and is publicly accessible:
psLens uses only standard, permissively licensed open-source libraries.
Zero copyleft. There are no GPL, LGPL, AGPL, SSPL, or reciprocal licenses in the application.
Permissive licenses only. All runtime dependencies are licensed under Apache 2.0, MIT, BSD-2-Clause, BSD-3-Clause, or SIL Open Font License (OFL).
Safe for enterprise and on-premises deployment. Deploying or self-hosting psLens does not impose any requirement to disclose proprietary configuration, code, or schema.
Compiled Runtime Dependencies
The following external Go modules are compiled directly into the psLens server binary (cmd/server):
License compliance and dependency security are validated during the build and release process:
License policy enforcement:go-licenses check validates that every compiled package complies with permissive licensing before an image is tagged.
CVE vulnerability scanning: Go’s official govulncheck audits the dependency graph for known security vulnerabilities on every commit.
SBOM publishing: The CycloneDX SBOM (/sbom.json) is re-generated automatically as part of each documentation site build.
11.4 - Authentication & Access
How users log in to psLens, the deliberate scope decision behind no in-app RBAC, native OIDC Single Sign-On, and reverse-proxy SSO.
This page covers how end users authenticate to psLens, what access controls exist (and which deliberately don’t), and how to front psLens with your existing identity provider today.
psLens ships with optional email magic-link authentication. It is off by default in the shipped config.yaml and must be turned on for production deployments.
When auth.enabled: true:
User visits any psLens URL → redirected to /login.
User enters their email address.
psLens emails a one-time verification code to that address (only if the address is on the configured AuthorizedUsers allowlist).
User enters the code at /verify-code.
Session created in NATS KV, identified by an HTTP-only psLens_auth cookie.
Property
Value
Mechanism
Email one-time code (no passwords)
Session storage
NATS KV bucket auth-sessions
Session TTL
1 year (configurable)
Cookie
psLens_auth, HTTP-only
User allowlist
AuthorizedUsers in config.yaml, case-insensitive
Public endpoints (no auth required)
/healthz, /static/*, the auth flow itself
There are no end-user passwords for psLens to store, leak, hash, or rotate.
Disabling auth entirely is supported only for sandbox or trusted-network deployments. The shipped config defaults to disabled so a first-time installer can get to a working UI quickly. Flip it on before exposing the instance.
2. The Deliberate Scope Decision: No In-App RBAC
psLens has no role-based access control inside the application. Every authenticated user sees the same set of metadata, can run the same reports, and can browse the same PS objects.
This is intentional, not an oversight:
psLens is read-only. It cannot modify PeopleSoft. The worst an authenticated user can do is read metadata.
The query surface is whitelisted on the PeopleSoft side by the SWS framework. Even psLens itself cannot query anything off-list. See Security & Trust.
The access boundary therefore lives at who is on the AuthorizedUsers list, not at “what role does this user have inside psLens?”. If a user shouldn’t see PS metadata at all, they shouldn’t have a psLens login.
For most customers, the population of people who need psLens (PS developers, sec admins, sys admins, business analysts doing audit work) is small and homogeneous. Adding in-app roles would create configuration overhead without changing the actual blast radius.
If your security policy requires per-user authorization decisions at the application layer, raise it on the demo call. The reverse-proxy patterns below can enforce this without requiring psLens itself to grow an RBAC model.
3. SSO Today: Reverse Proxy
The recommended pattern for any production deployment is to front psLens with a reverse proxy that handles SSO, and turn off the built-in magic-link layer. This delegates authentication to the IdP you already trust.
The reverse proxy terminates TLS, authenticates the user against your IdP, and only forwards authenticated requests to psLens.
psLens trusts the proxy (binds to a private network or listens on 127.0.0.1).
auth.enabled: false in psLens config. The proxy is the identity boundary.
Cross-link: the TLS termination patterns in Deployment Options cover the same reverse proxies and explain how to wire them up; this page is the identity-layer companion.
What the proxy can do that psLens RBAC could not: enforce group membership (“only the psoft-admins group in Okta”), require MFA, enforce conditional access policies (managed device, geo, time-of-day), and write to your existing IdP audit log.
4. Native OIDC Single Sign-On
psLens natively supports OpenID Connect (OIDC) Single Sign-On. You can configure your Identity Provider (Microsoft Entra ID, Okta, Keycloak, Auth0, Google Workspace) directly in config.yaml without requiring a reverse-proxy sidecar.
auth:enabled:truemode:oidc# "magic_link" (default) or "oidc"oidc:issuerUrl:"https://login.microsoftonline.com/{tenant-id}/v2.0"clientId:"pslens-client-id"clientSecret:"pslens-client-secret"redirectUrl:"https://pslens.company.com/auth/callback"# OptionalallowedGroups:["psoft-admins"]# Optional group claim check
Environment variable overrides are supported: PSLENS_AUTH_MODE, PSLENS_OIDC_ISSUER_URL, PSLENS_OIDC_CLIENT_ID, PSLENS_OIDC_CLIENT_SECRET, and PSLENS_OIDC_REDIRECT_URL.
Native SAML 2.0 is not built-in; for SAML-only identity providers, use the reverse-proxy patterns described above.
5. Session Management
Concern
Behavior
Where sessions live
NATS KV, bucket auth-sessions, scoped to this psLens instance
Cookie scope
HTTP-only, marked Secure when served over HTTPS
Idle timeout
None today. Sessions live until the TTL expires.
Absolute TTL
1 year (configurable per deployment)
Logout
/logout clears the session entry from NATS KV
Mass invalidation
Restart the container, or clear the auth-sessions bucket via nats kv. Useful after a credential incident.
A built-in admin-facing “kill all sessions” UI is on the roadmap. Today the NATS CLI path above is the supported route.
6. What Reviewers Usually Ask
“Can we require MFA?” Yes, by fronting with a reverse proxy that enforces MFA at the IdP layer (any of the proxies above). Magic-link auth on its own is single-factor (control of the email inbox).
“Where does the user email come from on the SWS side?” psLens authenticates its own users via magic-link or reverse-proxy SSO. Those are the people using the psLens UI. psLens authenticates to PeopleSoft via the SWS service account (basic auth, see Code & Supply Chain). The two identity domains are independent. Your psLens users do not need PS accounts.
“Can we revoke a user instantly?” Yes. Remove them from AuthorizedUsers and restart; their next request fails. With reverse-proxy SSO, revoke them at the IdP and they lose access on the next request, no restart needed.
“Does psLens store passwords?” No end-user passwords. The only password-shaped secret psLens holds is the SWS service-account password used to call PeopleSoft, encrypted at rest with AES-256-GCM. See Data Handling & Logging.
What psLens stores, what it does not, how data is encrypted at rest and in transit, and what gets logged for audit.
This page is for compliance reviewers and DPOs who need a precise answer to “what data does psLens hold, where, and for how long?”, and for security teams checking encryption and audit-trail posture.
Bind-mounted from your filesystem; secrets preferably via env vars
That is the complete persistent footprint. Everything else (query results, page renders, search hits) is generated on demand and not written to disk.
2. What psLens Does NOT Store
PeopleSoft business data. Employee records, payroll, financial transactions, HR data, customer records, journals, vouchers. None of it. Reports summarize at runtime and discard the raw rows.
Database passwords in cleartext (when PSLENS_MASTER_KEY is set).
End-user passwords. psLens uses magic-link or reverse-proxy SSO; there are no user passwords to store.
Logs on disk. Logs go to stderr; your container runtime decides what to do with them.
Telemetry, analytics, or usage data shipped back to Cedar Hills Group. psLens does not phone home.
Client-side cached data. Nothing is cached in the browser. No writes to LocalStorage, SessionStorage, or IndexedDB; close the tab and there is nothing left.
3. Personal Data (PII)
The answer is more nuanced than “no PII”.
psLens does not store PeopleSoft user PII. No persistent table or KV entry contains employee or operator records.
psLens does process PeopleSoft user PII at request time. When a user opens a search for Users, Operator IDs, or related security objects, psLens queries PeopleSoft, renders fields like OPRID, OPRDEFNDESC, EMAILID, and EMPLID in the browser, and discards the rows after the response. The data passes through psLens memory; it is not written to NATS, disk, or any log.
What this means for GDPR / CCPA / similar:
psLens acts as a processor of this data while a query is in flight.
The controller is the PeopleSoft owner (the customer).
Subject access / erasure requests are handled at the PeopleSoft source of record. psLens has nothing to delete because it has nothing persisted.
If your jurisdiction or policy requires that even transient processing be scoped, the AuthorizedUsers allowlist and the SWS table whitelist give you two layers of control over who can trigger such a query at all.
The SWS endpoint URL is HTTPS in every supported deployment. If you have a network where the PS server is reachable only over HTTP, raise it on the demo call. Running psLens over plaintext to PS is not a supported posture.
At rest
Item
Encryption
Key source
SWS / DB credentials in NATS KV
AES-256-GCM
PSLENS_MASTER_KEY env var (32 bytes, hex-encoded)
Auth sessions in NATS KV
Opaque session IDs only; no secret material at rest
n/a
Report output
Not encrypted (plain Markdown)
Stored on the customer-controlled volume
Alert history
Not encrypted (alert metadata)
Stored on the customer-controlled volume
Project archive uploads
Not encrypted at application layer
Disk-level encryption (LUKS, fly.io volumes, EBS) is the recommended boundary
Master key management:
Required (and enforced at startup) when PSLENS_ENV=production.
Stored as a 64-char hex string (32 raw bytes) in the PSLENS_MASTER_KEY env var. On fly.io: fly secrets set PSLENS_MASTER_KEY=.... In Docker Compose: .env file with 0600 permissions, or an external secret manager.
Back it up out of band. Losing the master key means encrypted DB credentials in NATS KV become unreadable; you’d need to re-enter them.
Self-service rotation. Generate a new key and trigger rotation directly from the Settings UI (Advanced page). The server decrypts all stored credentials using the old key and re-encrypts them with the new key in NATS KV. The operator must update the PSLENS_MASTER_KEY environment variable in the deployment configuration to match the new key before the container restarts.
5. Audit Logging
What psLens logs today
Event
Where it goes
Includes
Every HTTP request
stderr (structured slog)
X-Request-Id, path, method, status, duration, authenticated user email (if auth.enabled)
Application errors
stderr (structured slog)
Stack-relevant context, request ID for correlation
Startup banner
stderr
Version, commit SHA, build timestamp
Alert checker runs
stderr + NATS KV (alert history)
Which checker, what it found
The request ID flows through every log line tied to a request, so you can correlate a UI action to its server-side handler chain.
Logs are written to stderr only. psLens does not write logs to disk. Your container runtime decides what happens next: typically piped to your Docker logging driver, your systemd journal, your fly.io log stream, or your K8s log shipper. Send them to your SIEM via the same standard mechanism you use for any container workload.
Where the user-action audit actually lives today
Because psLens is read-only, the question “who looked at what PS data, when” has its authoritative answer on the PeopleSoft side. The SWS framework logs every query it accepts, including the OPRID of the SWS service account, the SQL it ran, and the timestamp. That is the audit trail that matters for “did someone see employee X’s record”.
What psLens contributes:
The HTTP request log (above) ties an authenticated psLens user to a specific page hit, and the page hit corresponds to a known set of SWS queries.
Correlation across the two logs uses the request ID on the psLens side and the timestamp + query pattern on the SWS side.
The gap and the roadmap
Today, psLens does not write a structured per-user “action” audit log. For example, {user: alice, action: viewed, object: PSRECDEFN PS_VOUCHER, at: 2026-05-21T14:32Z}. The HTTP request log is close to that but is operational logging, not an audit artifact.
Roadmap: add a first-class user-action audit log written to a NATS KV bucket with configurable retention, exportable to your SIEM. No committed date.
If a customer needs a richer audit story today, the recommended interim is: enable auth.enabled, ship the HTTP request log to your SIEM, and correlate with the SWS-side audit. Cedar Hills Group can help with the correlation queries.
Retention
psLens retains structured logs only in your container runtime’s log stream. Retention is whatever you configure there. No psLens-managed log retention policy exists; we deliberately stay out of that decision so it aligns with your existing log-retention SLAs.
6. What Reviewers Usually Ask
“Where is the data physically?” In your dedicated psLens instance. Managed deployments live in the fly.io region you choose at provisioning. Self-hosted: wherever you run the container. There is no shared backend.
“Can you delete all data for a customer on request?” Yes, by removing the deployment. Because all customer-specific state lives in the per-customer container’s /data volume, deletion is fly apps destroy or docker compose down --volumes. There is no other location to scrub.
“Do you encrypt the entire volume?” Application-level encryption covers credentials. Volume-level encryption is the customer’s choice. On fly.io, volumes are encrypted at rest by default; on your own infrastructure, use LUKS / EBS encryption / equivalent.
“Do you have an SBOM?” Available on request for any tagged build. See Code & Supply Chain.
How psLens is deployed, network requirements, sizing, backup, upgrade, DR, monitoring — consolidated for ops and security reviewers.
This page consolidates the operational story that an IT or DBA reviewer needs in one place. It overlaps with Installation and Deployment Options; those are the how-to references, and this page is the what-to-expect security-review companion.
1. Deployment Model
One container per customer. Each customer gets a dedicated psLens deployment: separate process, separate NATS instance, separate /data volume.
No shared multi-tenant backend. There is no Cedar Hills Group SaaS plane that customer instances talk to. Your psLens instance talks to your PeopleSoft and (optionally) your SMTP, and that is it.
Two hosting options:
Mode
Operated by
Where it runs
Managed
Cedar Hills Group
fly.io, in the region you choose at provisioning
Self-hosted
You
Docker, docker-compose, Kubernetes, or systemd on a Linux VM. Your cloud, on-prem, or air-gapped.
The choice is reversible. You can start managed and migrate to self-hosted (or vice versa). The data volume is portable and the configuration travels.
2. Network Requirements
Inbound
From
To
Why
Your users (browsers)
psLens UI on HTTPS (port per your TLS pattern)
The whole point
Your monitoring system
GET /healthz
Liveness check, returns 200 OK
Outbound
From
To
When
psLens
Your SWS endpoint (HTTPS)
Every request that hits PeopleSoft
psLens
Your SMTP server
Only if auth.enabled: true and you’re using built-in magic-link
psLens
Anywhere else
Never. No telemetry, no update checks, no callback to Cedar Hills Group.
This means psLens runs cleanly behind strict egress filtering. Allow it the SWS hostname (and SMTP host if applicable) and deny everything else.
TLS termination
Cross-link: Deployment Options → TLS compares 6 patterns (native cert, Let’s Encrypt, Caddy, nginx, Traefik, Tailscale Serve). Pick the one that matches your existing edge.
3. Sizing
Recommended minimums:
Resource
Minimum
Notes
CPU
1 vCPU
Matches the smallest fly.io machine class currently in production
RAM
512 MB
Most requests are well under this; reports can spike briefly
Disk
1 GB persistent
NATS KV + uploaded project archives; grow if you upload many projects
Network
~negligible
Metadata queries are small; most traffic is HTML rendering
For deployments handling many concurrent users or running heavy reports, scale up to 2 vCPU / 1 GB RAM. psLens is a single Go process; vertical scaling is the path, and there is no clustering model today.
#!/usr/bin/env bash
set -euo pipefail
TS=$(date -u +%Y%m%dT%H%M%SZ)docker run --rm \
--volumes-from pslens \
-v "$BACKUP_DIR":/backup \
alpine \
tar czf "/backup/pslens-${TS}.tar.gz" /data
Restore
Stop the container.
Restore the tarball into a fresh /data volume.
Ensure PSLENS_MASTER_KEY matches the key that encrypted the credentials.
Start the container.
5. Disaster Recovery
Today’s posture:
For self-hosted: DR is whatever your existing container DR posture is. psLens fits the same pattern as any small stateful Go service: restore the data volume, restart.
For managed (fly.io): redeployment is fast because all state fits in one volume. Cedar Hills Group operates the deployment; RTO/RPO targets for managed deployments are disclosed during contracting.
No multi-region replication of psLens state today. The single-customer scope makes this rarely worth the complexity, but if your contract requires it, raise it on the demo call.
If you need a higher DR posture than this, the answer is usually “self-host and use your existing DR tooling for the volume.” Cedar Hills Group can help structure that.
6. Monitoring
What ships today
GET /healthz returns 200 OK if the process is alive. Liveness check only; no readiness signal beyond startup completion.
Structured slog to stderr for every request and every error. Ship to your SIEM via your container runtime’s log driver.
Startup banner in logs: version, commit SHA, build timestamp. Useful for confirming an upgrade landed.
Connection-status UI inside psLens shows live SWS reachability for each configured database.
What doesn’t ship today
No Prometheus /metrics endpoint. Planned. No committed date.
No built-in alerting, in the sense of “psLens noticing it has a problem and notifying you.” That is your monitoring system’s job, fed by /healthz and the log stream.
Recommended wiring for a customer environment:
Signal
How to monitor
Process alive
GET /healthz from your uptime monitor every 30–60 s
Errors
Forward stderr to your log aggregation; alert on error-rate spikes
Auth failures
Same: the request log includes status codes
SWS reachability
psLens already shows this; if you want it externalized, build a small probe against /healthz
7. Upgrades and Rollback
Pin production to a vMAJOR.MINOR tag. To upgrade:
docker compose pull
docker compose up -d
The data volume survives the restart. Schema migrations on the NATS KV layer (if any) run automatically on first start of the new version.
To roll back, pin to the prior vMAJOR.MINOR.PATCH tag, docker compose up -d. Downgrade compatibility within a vMAJOR.MINOR is guaranteed; across major versions, check the release notes.
Breaking change contract: breaking changes only land in major version bumps and are called out explicitly in release notes. Patch and minor releases preserve config compatibility.
A single psLens instance can be configured to connect to multiple PeopleSoft databases (DEV, TEST, PROD, demo) via entries in config.yaml. The database selector appears on every search and report page.
This is usually the right deployment shape: one psLens instance per psLens user community, configured to see every PS environment that community needs. It is rarely useful to run multiple psLens instances unless those communities have non-overlapping access requirements that need to be enforced at the network layer.
9. DBA Concerns: What psLens Does to Your PS Server
For PeopleSoft admins who need to sign off on the load profile:
Property
Behavior
Connection type
HTTPS to SWS, basic auth, no JDBC, no direct DB connection
Read or write
Read-only. No code path issues INSERT, UPDATE, or DELETE.
Table coverage
Only whitelisted PeopleTools metadata tables (PSRECDEFN, PSPNLDEFN, PSAUTHITEM, process scheduler, IB tables, etc.)
Query shape
Mostly short metadata reads. Reports use a 90-second QuerySlow path; nothing runs longer.
Concurrency
One concurrent request per active user; small (handful) at any moment for typical customers
Service account permissions
Read on whitelisted tables; no write, no execute
The PS-side audit trail (SWS query log) captures every query psLens issues with timestamps and the SWS service-account OPRID. If psLens is misbehaving, that log shows what it actually did.
SOC 2 posture, GDPR / personal-data handling, DPA, sub-processors, business continuity, and how psLens fits in a vendor-risk review.
This page is for procurement, legal, and vendor-risk reviewers. It states current posture plainly, including where certifications do not yet exist.
If you’re filling out a vendor questionnaire (SIG, CAIQ, custom), the Security Questionnaires section is the right place to start.
1. SOC 2 — Current Posture
Cedar Hills Group is not SOC 2 certified today. Certification is on the roadmap. No committed date.
In the interim, this site documents the controls a SOC 2 Type II report would cover, so a reviewer can map them to their own framework. The relevant Trust Service Criteria and where they’re addressed:
This map is not a SOC 2 report; it is a vendor-side description of controls. We will fill out your SIG, CAIQ, or in-house questionnaire and return it (see below).
2. GDPR and Personal Data
psLens does not persist PeopleSoft user PII. There is no stored copy of employee, operator, or HR records.
psLens does process PeopleSoft user PII at request time when users search Users / OPRIDs / EMPLIDs. Data is rendered to the browser and discarded.
For GDPR purposes, the customer (the PeopleSoft owner) is the controller; psLens / Cedar Hills Group is the processor.
Your chosen SMTP provider (or Cedar Hills Group’s, if not specified)
Delivering one-time auth codes
All
GitHub (GHCR)
Image distribution; only at docker pull time, not at runtime
Self-hosters who don’t use magic-link auth have no Cedar Hills Group sub-processors at runtime. You run the infrastructure end to end.
The specific SMTP provider used by default for managed deployments is named during contracting so it can be reviewed against your vendor list.
Notification of sub-processor changes is provided in the DPA and in writing to deployment contacts.
5. Contract, SLA, and Termination
Topic
Posture
Contract length
Negotiated per customer; typical terms discussed on the demo call
SLA (managed)
Uptime targets and support response targets are disclosed during contracting
Support
Setup assistance included; ongoing support terms in the agreement
Termination & data return
All customer state lives in the per-customer /data volume. On termination, you can take a final tarball before the instance is destroyed. Self-hosters keep everything by definition.
Commercial general liability and cyber policy details available on request during contracting
6. About Cedar Hills Group
Cedar Hills Group is a PeopleSoft consultancy. The same team that built the SWS framework (the bounded REST API that psLens uses to talk to PeopleSoft) builds psLens, so the access path psLens uses is one we control end to end.
What this means for vendor reviewers:
The team has run real PS environments for real customers and built psLens out of that operational need.
Cedar Hills Group is reachable and contactable; this is not a self-service SaaS where you can’t get a human on a call. See contact.
7. Business Continuity: What Happens If Cedar Hills Group Goes Away
A fair question in any vendor review:
You keep the Docker image you’re running. GHCR can rotate tokens or change ownership; the image you’ve already pulled keeps working. Pin to a specific vMAJOR.MINOR.PATCH and you have an indefinite-life binary.
Self-hosting works without Cedar Hills Group infrastructure. No runtime callback, no license check, no cloud control plane. If our domain disappeared tomorrow, every self-hosted instance keeps running.
Managed deployments could be migrated to self-hosted. All state is in the per-customer /data volume. Cedar Hills Group commits to providing the volume and configuration on termination so you can restart it on your own infrastructure.
Source escrow. Available on request for enterprise contracts.
Together: a binary you already hold, a portable data volume, and (on enterprise contracts) source escrow. That is the answer to “what is our exposure if the vendor goes away.”
8. Security Questionnaires
We complete the following questionnaires on request as part of an evaluation:
HECVAT Lite / HECVAT On-Prem. For higher education vendor assessments. See HECVAT & Higher Education.
SIG Lite. Standard short form.
SIG Core. Long form.
CAIQ (Cloud Security Alliance). For cloud-shape reviews.
Your own custom questionnaire. Preferred, since it asks what your team actually cares about.
To kick this off, email chris.malek@cedarhillsgroup.com with the questionnaire attached, or raise it on the demo call.
For questions that are common across questionnaires, the answer often already lives in one of the pages below. Cross-referencing those pages in your questionnaire response is encouraged.
How psLens aligns with the Higher Education Community Vendor Assessment Tool (HECVAT), FERPA data boundaries, single-tenant hosting, and on-premises deployment.
This page documents how psLens aligns with the Higher Education Community Vendor Assessment Tool (HECVAT v4), FERPA compliance requirements, and university information security evaluations.
Institutions evaluating psLens can request our pre-populated HECVAT Lite or HECVAT On-Premises assessment workbook by contacting security@cedarhillsgroup.com.
1. FERPA and Student Data Boundaries
psLens is designed exclusively for PeopleTools system administration, security auditing, and operational monitoring.
No Student or Financial Data: psLens does not query, replicate, or store student education records, financial aid data, payment information, or course grades.
Enforced Table Whitelist: All queries execute against an institution-managed table whitelist (PS_CHG_PSLENS_WL) on the PeopleSoft application server. Queries targeting non-whitelisted records (e.g., student tables like PS_STDNT_ENRL or PS_ACAD_PROG) are rejected before execution.
In-Memory Operator Auditing: While PeopleTools security tables contain administrative operator IDs (PSOPRDEFN) and operator email addresses (PSUSEREMAIL) for access auditing, this data is processed in memory during active user requests and is not permanently synced to external databases.
2. Authentication and Access Control (AAAI)
Single Sign-On (SSO): psLens supports native OpenID Connect (OIDC) Single Sign-On against campus identity providers, including Microsoft Entra ID, Okta, Google Workspace, and Keycloak.
Email One-Time Passcode (OTP): For deployments without SSO, authentication uses 6-digit email passcodes restricted to a verified institution email domain allowlist.
Credential Storage: PeopleSoft service account credentials used by psLens are encrypted at rest using AES-256-GCM. Decryption keys are loaded from environment variables or enterprise secret vaults (e.g., 1Password) at boot time.
Session Management: Web sessions are stored in HTTP-only, secure cookies with configurable inactivity timeouts.
3. Data Residency and Hosting Models (DATA & DCTR)
Institutions can choose between two deployment models based on risk tolerance and data residency policies:
Attribute
Dedicated Managed Instance
Self-Hosted Docker Container
Hosting Location
Single-tenant container on Fly.io
University private cloud, VM, or on-premises server
Network Egress
Dedicated static egress IP or private Tailscale VPN
Internal network only; zero outbound internet required
Both options provide isolated single-tenancy. No multi-tenant shared databases or shared application processes are used.
4. System Integrity and Least Privilege
Read-Only by Design: The SWS framework installed on PeopleSoft provides read-only SQL queries via Integration Broker. The psLens application and SWS framework contain zero INSERT, UPDATE, DELETE, or DROP endpoints.
Standard Integration Broker Channel: psLens connects via standard HTTPS REST calls to the PeopleSoft Integration Broker listening connector. It does not require direct database listeners (e.g., Oracle 1521 or SQL Server 1433) or direct database administrator accounts.
Independent Failure Domain: psLens operates out-of-band as an observability window. If the psLens service is interrupted or disabled, PeopleSoft core processing, student self-service, and batch jobs continue unaffected.
Static Binary Architecture: psLens compiles to a standalone Go binary with minimal external dependencies, eliminating Node.js/npm and dynamic runtime attack surfaces.
Automated CI Scanning: Every code release is automatically scanned for known vulnerabilities using Go’s official govulncheck tool and Dependabot alerts.
Institution Vulnerability Testing: Cedar Hills Group welcomes institutions to conduct vulnerability scans and penetration tests against their dedicated evaluation or staging instances under a mutually agreed testing window.
6. Artificial Intelligence and MCP Alignment
psLens includes optional Model Context Protocol (MCP) server support to allow authorized local developer tools to inspect PeopleTools metadata.
No Third-Party AI Data Transmission: psLens does not transmit institutional data to external AI model providers (such as OpenAI, Anthropic, or Google).
No Model Training: psLens does not train, fine-tune, or retain institutional data in any machine learning or large language model.
Feature Disablement: MCP endpoints can be completely disabled in configuration by omitting the MCP listener settings.
7. Business Continuity and Offboarding
No Vendor Lock-In: Because psLens relies on standard Docker containers and requires no cloud licensing handshake, the application remains fully functional on customer infrastructure even in the event of vendor dissolution.
Data Portability & Offboarding: On contract termination, institutions can export all historical report markdown files and configuration state directly from their /data volume. Managed instances on Fly.io are securely decommissioned and persistent storage volumes are permanently destroyed.
Related
Security & Trust. Overview of read-only architecture and table whitelisting.
Recent feature releases, PeopleTools object additions, security enhancements, and system updates in psLens.
Release & Change History
This page tracks major updates, new PeopleTools object handlers, security features, and configuration enhancements in psLens.
September 6, 2026 — PeopleSoft Trace Analyzer
Trace Analyzer (/trace):
Upload, inspect, and analyze PeopleSoft trace files (.tracesql, .trc, and .aet).
Automatically reconstructs execution call hierarchies for PeopleCode methods, functions, and Application Engine steps with timing breakdown.
Interactive SQL statement analytics with slow query detection, bind variable substitution, and candidate N+1 loop detection.
Cross-references traced database tables with the live PeopleSoft catalog to display record types (SQL Table, SQL View, Dynamic View) and provide direct one-click links to Record definitions.
Links Application Package methods and Application Engine steps directly to their object inspectors in psLens.
Side-by-side execution path diffing to align and compare two trace runs (e.g. Test vs. Production or working vs. failing transactions) to pinpoint where logic branched.
Quick-reference modal for PeopleTools TraceSQL, TracePC, and TraceAE bitmask recipes.
September 4, 2026 — Security Comparisons Saved to Reports & Scheduled Audits
Automatic Report Persistence for Security Compares:
Running a security comparison for Permission Lists, Roles, or User Profiles now automatically saves the complete comparison results and Markdown report to the Reports repository.
Interactive comparison results now include a “View in Reports” button for easy navigation to stored comparison runs and historical review.
Scheduled Security Comparison Reports:
Added on-demand and scheduled reports for Permission List Comparison, Role Comparison, and User Profile Comparison under the Security reports category.
Run or schedule comparisons across environments (such as Production vs. Test) to detect security configuration changes and drift over time.
September 4, 2026 — Markdown Viewer Tool
Markdown Viewer (/markdown-viewer):
Open, inspect, format, and print PeopleSoft markdown exports directly in the browser.
Supports drag-and-drop file upload, file browsing, and direct text pasting for .md, .markdown, and .txt files.
One-click toggle between rendered preview and raw markdown source.
One-click copy for markdown content and clean browser printing / PDF export.
Direct helper link added to all object definition “Export as Markdown” sidebar cards.
September 2, 2026 — Public Software Bill of Materials (SBOM) & License Compliance
Public Software Bill of Materials (SBOM): Automated CycloneDX v1.6 SBOM generation (/sbom.json) integrated directly into the documentation build and deployment pipeline.
License & Dependency Inventory: Published a dedicated SBOM & Licenses page detailing all compiled runtime packages and frontend asset licenses.
September 1, 2026 — Record/Field Reference Finder & Impact Analysis
Record/Field Reference Finder (/records/{recname}/fields/{fieldname}):
Launched directly from any record’s field listing or field detail record usage tables.
Full cross-object impact analysis across 7 PeopleTools metadata dimensions:
Pages (PSPNLFIELD): Lists all page definitions containing the record field, with page type and control type badges.
Components (PSPNLGROUP): Lists components hosting pages with the record field, including item name, search record, and marketplace info.
Component Interfaces (PSBCITEM): Lists CIs exposing the record field with property names and access modes.
PeopleCode Programs (PSPCMPROG & PSPCMNAME): Identifies direct record field events, component record field events, and where-used code references.
PSQueries (PSQRYFIELD): Finds queries selecting or filtering on the record field with column headings and criteria.
File Layouts (PSFLDFIELDDEFN): Finds file layout definitions and segments mapping the record field.
Search Definitions (PSPTSF_SD_DCATR): Identifies Search Framework definitions indexing the record field as search or display attributes.
Real-time parallel metrics summary badges and asynchronous SSE loading for high-scale databases.
Markdown report export (/records/{recname}/fields/{fieldname}.md) and MCP tool analyze_record_field_impact.
Permission List Query Tree Deep Links: Query Access Tree nodes on the Permission List detail page now link directly to the tree definition (/querytrees/{tree_name}).
August 31, 2026 — PeopleSoft Compare Report Analyzer
Compare Report Analyzer (/compare-reports):
Upload and analyze PeopleSoft Application Designer binary compare reports (.idx and .prt files).
Supports uploading a single .zip archive containing compare report files or multi-file drag-and-drop.
Generates compare summaries showing project metadata, source database, target database, release, run date, and total changed object counts across definition types.
Interactive definition diff viewer for 17-column definition reports (Records, Pages, Components, Menus, Roles, Permission Lists, Portal Registry, Routings, and Documents) with before/after attribute value comparisons.
Line-level PeopleCode diff viewer with unified diff formatting and side-by-side code comparisons for Application Package PeopleCode (Upg58).
Downloadable Markdown summary reports and CSV exports for definition differences.
August 30, 2026 — Cross-Database Security Object Compare (Roles & User Profiles)
Cross-Database Role Comparison (/roles/compare):
Expanded the cross-database security comparison toolset to diff PeopleSoft Role definitions (PSROLEDEFN) across environments (e.g., DEV vs. PROD) or within the same database.
Compares assigned permission lists (PSROLECLASS), assigned users (PSROLEUSER) with dynamic rule assignment flags (DYNAMIC_SW), Process Scheduler job notifications and distribution lists, and aggregate effective access across Pages, Web Libraries, Service Operations, and Component Interfaces.
Real-time SSE comparison stream with summary metric cards, deep links to detail pages in both databases, and full Markdown report export (/roles/compare/export).
Added “Compare Tool” header actions and “Compare” detail page shortcut buttons on Role browsing views.
Cross-Database User Profile Comparison (/users/compare):
Added full cross-database User Profile (PSOPRDEFN) diffing across environments or within the same database.
Field-by-field profile attribute comparison (description, emplID, account status, symbolic ID, language/currency, primary, row-security, process profile, default homepage, and password configuration).
Assigned roles comparison (PSROLEUSER), composite effective permission lists with back-references to granting roles, authorized Service Operations (PSAUTHWS), email accounts (PSUSEREMAIL), portal favorites (PSPRUFDEFN), and system Special Use bindings (Message Node default user and signon PeopleCode execution).
Real-time SSE comparison stream with summary metric cards, deep links to user and security detail views in both databases, and Markdown report export (/users/compare/export).
Added “Compare Tool” header actions and “Compare” detail page shortcut buttons on User browsing views.
Cross-Database Permission List Comparison (/permissionlists/compare):
Added multi-environment diffing for PeopleSoft Permission Lists (PSCLASSDEFN).
Comprehensive comparison across Component Authorizations, Web Libraries, Component Interfaces, Process Groups, Application Services, and Query Profiles with Markdown export.
Restrict access to psLens web interface and API endpoints by CIDR block or client IP address with fail-closed enforcement policies.
30-Day Connection Uptime & Incident History:
Interactive 30-day availability timeline bars and incident history recording scheduled maintenance and unexpected connection outages.
PeopleTools Change Control & Object Lock Visibility:
Direct visibility into database Change Control status and active checkout locks (PSCHGCTLLOCK) across object detail views.
Live Notification Delivery Testing:
Interactive delivery testing modals in Settings to verify webhook endpoints (Slack, Microsoft Teams, generic JSON) and SMTP email dispatch in real-time.
In-App Database Credential Management:
Update PeopleSoft connection credentials securely from the Settings UI with encryption at rest and optional password changes.
August 21, 2026 — MCP Operation Audit Logging & Live Activity Stream
MCP Operations Audit Stream: All MCP tool calls and operations executed by AI coding assistants (Google Antigravity, VS Code, Claude Desktop, Claude Code) are now recorded to an append-only persistent audit stream with automatic 30-day retention and storage protection.
Live Activity Feed in Settings: Added a real-time MCP Operations Audit Log table to the MCP Settings page (/settings/mcp) showing timestamps, caller identity, tools executed, target databases, arguments, duration, and execution status with refresh and log clearing capabilities.
August 18, 2026 — MCP Setup Guides for Google Antigravity and VS Code
Google Antigravity & VS Code Setup Guides: Added tabbed configuration guides and ready-to-paste JSON snippets for Google Antigravity (~/.gemini/config/mcp_config.json) and VS Code (.vscode/mcp.json and MCP extensions) on the MCP Settings page (/settings/mcp) and documentation.
Pre-Populated Token Configuration Modal: Token generation modal now displays copyable configuration snippets with personal access tokens pre-populated for Google Antigravity, VS Code, Claude Desktop, and Claude Code CLI.
Agent Skill Installation: Added setup commands for installing the pslens agent skill directly into Google Antigravity global and project skill directories.
August 17, 2026 — MCP Server v2: Cohesive 20-Tool Surface, Sizing Tiers & Embedded Agent Skills
Consolidated 20-Tool Surface: Redesigned the MCP tool suite from 27 dispersed tools into a cohesive 20-tool domain architecture (18 domain tools + 2 developer tools) with clear sizing tiers (Summary, Structured, Full).
Batch Record Introspection (batch_records_summary): Inspect schemas, primary keys, and prompt table relationships for up to 25 records in a single round-trip call, eliminating multi-turn join loops during SQL authoring.
Record Schema Consolidation (get_record_schema): Unified record field listings, subrecord flattening (expand_subrecords), DDL parameters (format='ddl'), and markdown documentation (format='markdown') into a single endpoint.
Embedded Agent Skills Distribution:
Embedded pslens Agent Skill package served at /skills/pslens.zip containing PeopleSoft naming conventions, status code decoders, and step-by-step diagnostic workflows.
Implemented Agent Skills Discovery specification (/.well-known/agent-skills/index.json) for discovery and auto-installation by autonomous agents.
Added Skill Download Card to the psLens MCP Settings page (/settings/mcp).
Unified Environment Comparison (compare_environments): Merged disparate comparison tools into a multi-modal comparison endpoint supporting project, single_object, recurrences, and missing_projects.
Integrated Operations Triage (triage_operations): Consolidated Process Scheduler queue analysis and Integration Broker contract diagnostics into a single call.
Automated DDL & DMS Generation (generate_dms_script, lint_dms_script): Tools for generating and linting PeopleSoft Data Mover export/import scripts.
Streamable HTTP endpoint works with sign-in enabled: https://<your-pslens>/mcp no longer redirects MCP clients to the login page when psLens authentication is turned on. Claude Code should be registered with claude mcp add --transport http pslens https://<your-pslens>/mcp --header "Authorization: Bearer <token>"; the older /mcp/sse endpoint still works but is deprecated by the MCP specification.
Token generation keeps your label and expiry: tokens created from Settings → MCP Tokens now record the label and expiration you chose. Revoke and delete require a POST.
More accurate tool results for AI agents:
Public PSQueries are found by get_object_definition and get_psquery_definition; mixed-case role names work in export_object_markdown and compare_object.
include_* options that document a default of true now default to true when omitted.
compare_object no longer reports a connectivity failure as “missing in the target”; existence is reported as unknown and the result carries comparisonComplete and warnings. Permission lists, App Engines, components, and pages are compared by content, not by counts.
compare_recurring_processes now diffs the two environments (only in source, only in target, matched with differences) instead of returning two raw lists.
get_system_health, export_health_snapshot, and the pslens://system/health/{db} resource share one health calculation; query failures surface as warnings and degrade the verdict instead of reading as healthy.
Capped lists (who_has_access, user_access_summary, get_object_dependencies, get_security_matrix, triage_process_scheduler) report hasMore/limit so an agent knows when a list is incomplete. get_security_matrix honors menu_name.
list_active_alerts and get_alert_history work for a configured database even while its PeopleSoft connection is down; database names match case-insensitively everywhere.
Very large tool results are cut at a fixed size with an explicit truncation marker instead of being rejected by the client.
Alert mutes created through MCP are attributed to the token owner and capped at 7 days.
Server hygiene: idle MCP sessions expire after 30 minutes; tools carry a display title; server instructions describe database discovery, name casing, pagination, and output limits.
August 15, 2026 — MCP Server Enhancements: Proactive Health Sensor & Priority Intelligence Tools
Expanded the native embedded Model Context Protocol (MCP) Server with real-time proactive health sensor telemetry and deep diagnostic tooling for autonomous AI agents and pair-programming workflows:
Proactive System Health Sensor & Telemetry:
Enhanced get_system_health into a real-time health sensor evaluating Process Scheduler heartbeats (PSSERVERSTAT), Integration Broker domain dispatchers (PSAPMSGDOMSTAT), blocked message nodes (PSNODESDOWN), stalled/overdue process requests, locked-user process blockers, recent errors, and active firing alerts with automatic HEALTHY, DEGRADED, or CRITICAL categorization.
Added real-time passive resources pslens://alerts/active and pslens://system/health/{db}.
Introduced proactive_system_monitor prompt for autonomous AI agents monitoring production PeopleSoft instances.
Export any of the 32+ PeopleSoft object types directly into LLM-optimized and structured Markdown with optional recursive PeopleCode reference resolution (recursive_pc: true).
Breakdown component/menu action authorizations (Add, Update/Display, Update/Display All, Correction, Data Entry) across permission lists, roles, and user accounts.
DBA Storage & Index Inspection (get_record_ddl_and_indexes):
Inspect low-level table DDL parameters (PSRECDDLPARM), index structures (PSKEYDEFN primary and alternate keys), and tablespace assignments (PSRECTBLSPC).
Deep inspection of PeopleSoft Search Framework definitions (PSPTSF_SD), source queries, mapped attributes (PSPTSF_SD_ATTR), facets, and parent categories.
Alert Execution History & Triage (get_alert_history):
Review historical background alert check runs, check durations, failure errors, and active firing incidents across databases.
Dynamic Alert Muting Rules (manage_alert_mute):
Enable agents to list, create, or remove temporary alert silences in NATS KV during planned maintenance or active incident triage without database modifications.
Probe database SWS endpoints on demand, returning round-trip latency (ms), PIA responsiveness, database metadata, and PeopleTools release.
Markdown Operational Health Digest (export_health_snapshot):
Generate comprehensive Markdown health reports with comparative environment tables, Process Scheduler heartbeats, and active alert summaries formatted for Slack/Teams alerts or incident briefs.
Retrieve the full execution hierarchy of an Application Engine program (PSAEAPPLDEFN), state records, temp tables, section flow, and step action breakdown.
Inspect PeopleTools Event Mapping configurations (PSEVMAPLINK, PSEVMAPDATA) to discover custom Application Classes injected into standard Component, Page, and Record events.
Service Operation & Routing Graph (get_service_operation_routing):
Inspect Integration Broker Service Operations, Operation Versions, Handlers (with App Classes), Sender/Receiver Nodes, and transformation programs.
Specialized Multi-Step MCP Prompts:
Added security_compliance_audit and event_mapping_impact_analysis guided workflows for autonomous security and upgrade impact analysis.
Data Mover Script Linter & Parser (lint_dms_script):
Parse, lint, and validate PeopleSoft Data Mover scripts (.dms) checking command sequences, syntax validity, %DateTimeIn macros, and table references.
Deep inspection of Project definitions (PSPROJECTDEFN, PSPROJECTITEM) with object type groupings and upgrade action flags (UPGRADEACTION, TAKEACTION, COPYDONE).
Message Catalog Deep Search (search_message_catalog):
Query message catalog error codes and explanations (PSMSGCATDEFN) by set number, message number, or full text search.
Web Object & HTML Asset Explorer (get_web_object):
Fetch raw HTML definitions (PSHTMLDEFN), stylesheets (PSSTYLEDEFN), and freeform web assets.
Guided multi-step prompt for generating and validating Data Mover scripts.
August 14, 2026 — Embedded Model Context Protocol (MCP) Server & AI Assistant Integration
Added a native, high-performance embedded Model Context Protocol (MCP) Server running directly inside the psLens Go server process over HTTP/SSE, allowing AI assistants like Claude Desktop, Claude Code CLI, and Cursor to query, inspect, and analyze PeopleSoft metadata and runtime operations in real time.
Embedded Architecture: Zero external dependencies, python bridges, or local daemons to install. The MCP server runs natively inside the psLens binary alongside the web UI.
Personal Access Token Authentication: Built-in token engine under Settings → MCP Tokens (/settings/mcp) allowing users to generate revocable API tokens (psl_mcp_...) with configurable expiration windows and automatic last-used tracking.
One-Click AI Client Setup: Settings page provides copy-ready configuration snippets for Claude Desktop (claude_desktop_config.json) and Claude Code CLI (claude mcp add ...).
20+ PeopleSoft Intelligence Tools:
Metadata & PeopleCode: Universal object search (search_objects), structured schema exploration with recursive subrecord flattening (get_object_definition), PeopleCode source retrieval across all event types (get_peoplecode), forward and reverse dependency where-used graph (get_object_dependencies), full-text SQL/PeopleCode search (search_code_sql), and safe table data sampling (get_table_sample_and_count).
Security & Access: Complete 360-degree user access profile (user_access_summary), reverse security path traversal (who_has_access), high-risk grant auditing (audit_dangerous_access), Query Security Tree authorizations (query_tree_access), and authentication history audit (user_login_audit).
Operational Triage: Multi-point system health check (get_system_health), Process Scheduler triage with human-readable run statuses (triage_process_scheduler), Integration Broker transaction triage (triage_integration_broker), and active alert review (list_active_alerts).
Agent Ergonomics & Context Preservation: Built-in tool safety annotations to eliminate permission prompts, human-readable enum descriptors alongside numeric constants, and credential column protection for safe table inspection.
Guided Workflow Prompts & Passive Resources: Standardized prompts for post-migration verification, on-call incident triage, user security audits, and change impact analysis, plus passive context resources for connected databases and object catalogs. See MCP Server.
August 13, 2026 — Live Field Alias Discovery & Field Pages Pagination
Added live field alias discovery and pagination support to Field detail pages (/fields/{fieldname}).
Field Alias Discovery: Automatically inspects SWS prompt tables and record metadata to check if a field is an alias of a canonical entity, or to discover all alternative field names that act as aliases (e.g. AV_EMPLID, PARTNER_EMPLID, or INSTRUCTOR_ID as aliases for EMPLID).
Likely vs Confirmed Aliases: Softens the verdict to “Likely Field Alias Identified” and flags ambiguity when multiple matching keys are found on a prompt table.
Field Pages Pagination: Replaced the previous 200-item hard limit on the “Pages using field” list with infinite scroll offset-based pagination.
Markdown Export Integration: Extends the field exporter to include the aliases details in the generated Markdown file.
Optimized Performance: Reuses SWS client helpers to collapse sequential query calls by orders of magnitude.
Added native OpenID Connect (OIDC) authentication support for enterprise Single Sign-On (SSO).
Native OIDC Integration: Added native OIDC authentication (auth.mode: oidc), allowing direct integration with enterprise Identity Providers such as Microsoft Entra ID, Okta, Keycloak, Auth0, and Google Workspace without requiring a reverse proxy.
Automated OpenID Discovery & Token Verification: Uses standard OpenID Connect discovery (.well-known/openid-configuration), OAuth 2.0 PKCE, and automated JWKS key signature verification to validate user identity claims.
Group Claim Verification & User Authorization: Supports optional group claim enforcement (allowedGroups) and user allowlist matching (authorizedUsers).
1Password Secret Resolution: Integrated op:// reference resolution for OIDC client ID (clientId) and client secret (clientSecret) settings.
Environment Overrides & Schema Update: Supported configuration via PSLENS_AUTH_MODE and PSLENS_OIDC_* environment variables. Updated configuration JSON schema verification. See Authentication & Access and Configuration.
August 8, 2026 — Code & SQL Text Search & Auth Configuration
Added full-text search capabilities across SQL and PeopleCode and refined authentication configuration.
Code & SQL Text Search Report: Introduced a new report (code-sql-search) that allows searching for specific text strings across all stored SQL statements and PeopleCode in the database. Added to the navigation sidebar under Definitions and in the command palette.
August 6, 2026 — Campus Solutions Row-Level Security Integration
Added support for Campus Solutions (CS) application-level security tables, user defaults inspection, responsive sidebar toggling, Markdown export integration, and Full User Access Report inclusion.
Campus Solutions Security Integration: Added discovery and inspection for 9 Campus Solutions security tables:
OPR_DEF_TBL_CS: User Defaults (Institution, Career, Program, Plan, Term, Aid Year, Business Unit, SetID, Campus, Admission Application/Recruiter Center)
SCRTY_TBL_INST: Academic Institution Security
SCRTY_TBL_CAR: Academic Career Security
SCRTY_TBL_PROG: Academic Program Security
SCRTY_TBL_PLAN: Academic Plan Security
SCRTY_TBL_ACAD: Academic Organization Security
SCRTY_TBL_STGP: Student Group Security
SCRTY_TBL_SRVC: Service Indicator Security
OPR_GRP_3C_TBL: 3C Group Security
User Detail Page Integration: Added a dedicated Campus Solutions Security panel on User detail pages (/users/{oprid}), accessible via an optional toggle switch under Related Data in the right sidebar.
Dynamic Direct Querying & Graceful Degradation: Direct SWS endpoint querying fetches active security grants in parallel without requiring upfront connection status cache updates. If no CS security tables are whitelisted for a database, an informative guidance card displays candidate table whitelist instructions.
Full User Access Report Integration: Extended SecurityUserAccessReport to concurrently query and include Campus Solutions row-level security grants in generated Full Access Reports.
Markdown Export: Integrated Campus Solutions Security tables into User detail Markdown exports (/users/{oprid}/export).
August 1, 2026 — COBOL SQL Statements (SQLSTMT_TBL)
Added COBOL SQL statement discovery and inspection to Record detail pages (/records/{recname}).
COBOL SQL Statements Panel: Sourced from SQLSTMT_TBL, this panel displays stored SQL statements (PGM_NAME, STMT_TYPE, STMT_NAME) used by COBOL programs that reference the record in statement text, program names, or statement names.
Syntax Highlighting & Type Badges: Displays formatted SQL statement text with syntax highlighting alongside color-coded badges for statement types (Select, Update, Insert, Delete).
Markdown Export: Integrated COBOL SQL statements into Record Markdown exports for documentation and offline review.
Whitelist Table Requirements: Added SQLSTMT_TBL to system table requirements and Whitelist Tables. See Records.
August 1, 2026 — Process Definition Recurrence History & Schedule Variance
Added recurrence execution history analysis and start delay variance visualization to Process Definitions (PRCSDEFN).
Recurrence History & Variance Panel: Automatically analyzes process requests in PSPRCSRQST executed via recurrence schedules (RECURNAME <> ' ').
Start Delay Variance (BEGINDTTM - RUNDTTM): Calculates and displays schedule latency, comparing target scheduled run times against actual execution start times.
Aggregate KPI Metrics: Displays summary metrics for Total Recurring Runs, Average Start Delay, Maximum Start Delay (with instance reference), and On-Time Rate percentage.
Visual Delay Breakdown: Progress bar categorizing runs into On-Time (≤ 1m), Minor Delay (1-5m), and Significant Delay (> 5m).
Historical Run Log: Detailed table listing process instance numbers, recurrence schedule links (/recurrences/{recurname}), scheduled run times, actual start times, color-coded variance badges, execution durations, run statuses, and executing servers.
Markdown Export: Integrated recurrence history summary metrics and recent recurring run logs into Process Definition Markdown exports. See Process Definitions.
August 1, 2026 — File Layout Definitions (PSFLDDEFN)
Added full metadata browsing, definition hierarchy visualization, and Markdown export for PeopleSoft File Layout definitions.
New Object Handler: Dedicated File Layouts browser at /filelayouts and detail page at /filelayouts/{flname}.
Definition Hierarchy (App Designer View): Visual tree representation mapping parent-child segment hierarchies (PSFLDSEGDEFN via FLDSEGPARENT), field data types (PSFLDFIELDDEFN), start positions, lengths, and date formatting masks.
Related Data Sidebar Toggles: On-demand SSE toggles for Application Designer Projects (PSPROJECTITEM where OBJECTTYPE = 31) and PeopleCode Cross-References (PSPCMNAME).
PeopleCode Cross-References: Discovery of all PeopleCode programs referencing the File Layout via PSPCMNAME.
Markdown Export: One-click Markdown export (/filelayouts/{flname}/export) generating structured documentation with ASCII definition hierarchy trees, projects, and PeopleCode references.
Global Search & Navigation: Integrated into the ⌘K command palette and sidebar under Definitions.
Whitelist Table Requirements: Added PSFLDDEFN, PSFLDSEGDEFN, and PSFLDFIELDDEFN to system table requirements and Whitelist Tables. See File Layouts.
July 31, 2026 — Hot-Reload Configuration & SWS Whitelist Management
Enhanced live NATS KV configuration management and database connection synchronization.
Live Config Hot-Reload: Real-time NATS KV configuration updates for database connections, alert thresholds, and notification rules without restarting the server.
Air Hot-Reload File Guard: Excluded config.yaml from live-reload file watchers to prevent infinite build loops during automated config sync.
Report Link Generation: Standardized deep-link URL generation across security and object comparison reports using appBaseURL.
SWS Whitelist Discovery: Updated CHG_PSLENS_WL runtime discovery to validate table authorizations on startup. See Configuration.
July 28, 2026 — Component Record Hierarchy & Menu Market Metadata
Expanded component data hierarchy analysis and menu item metadata inspection.
Component Record Hierarchy: Enhanced the /components/{compname} record hierarchy panel with scroll levels, page access types, and updatable record identification. See Components.
Menu Market Metadata: Added Market metadata parsing to menu item detail views for cross-market navigation analysis.
Search Definitions (PSPTSF_SD): New metadata browser for Search Framework definitions, document category attributes (PSPTSF_SD_DCATR), search categories (PSPTSF_SRCCAT), and OpenSearch/Elasticsearch index mappings.
Database DDL Storage Parameters: Added DDL parameter inspection (PSRECDDLPARM, PSIDXDDLPARM, PSSPCDDLPARM) to record detail pages (/records/{recname}) for Oracle, SQL Server, and DB2 table storage verification.
Item-Level Page Security (PNLITEMNAME): Added PNLITEMNAME field resolution across PSAUTHITEM security queries to detect page-item-level authorization overrides in Permission Lists. See Permission Lists.
1Password Secret Resolution: Native resolution of op:// secret references in database credentials and SMTP notification settings.
July 22 - 23, 2026 — Infrastructure Enhancements
Optimized container deployment options and background notification delivery.
SMTP Notification Pipeline: Upgraded background notification delivery and retry logic for scheduled audit report distribution.
13 - Roadmap
Planned psLens capabilities, recently delivered milestones, and commitment posture. No published dates.
Roadmap
This page shows where psLens is headed next so you can judge how well it fits the way your team works today and what you may want from it next. Recent releases delivered an embedded Model Context Protocol (MCP) server for live AI agent integration and native OpenID Connect (OIDC) Single Sign-On. Current roadmap priorities focus on Segregation of Duties (SoD) analysis, cross-environment security drift, structured user-action audit logging, and expanded operational observability.
If a specific planned feature matters to your evaluation, bring it up on the demo call. The roadmap is part of the sales conversation precisely because customer demand changes the order.
Recently Delivered
These capabilities originated on the roadmap and are now shipped in psLens:
Embedded Model Context Protocol (MCP) Server. A native MCP server running directly inside the psLens Go process over Streamable HTTP (/mcp) and HTTP+SSE (/mcp/sse). Exposes 20+ specialized tools across metadata exploration, PeopleCode extraction, reverse dependency traversal, security access auditing, operational triage, and cross-environment drift comparison. Secured via Personal Access Tokens (psl_mcp_...). See MCP Server.
Native OpenID Connect (OIDC) Single Sign-On. Direct integration with enterprise Identity Providers (Microsoft Entra ID, Okta, Keycloak, Auth0, Google Workspace) via OAuth 2.0 PKCE, JWKS key verification, and group claim checks without requiring a reverse-proxy sidecar. See Authentication & Access.
Campus Solutions Security Integration. Discovery and auditing of 9 Campus Solutions row-level security tables, user defaults inspection, and inclusion in Full User Access reports. See Campus Solutions Security.
Live Field Alias Discovery. Real-time detection of prompt table alias hierarchies and canonical field mappings to resolve schema naming variations. See Fields.
Code & SQL Full-Text Search. Direct text search across stored PeopleCode, SQL objects, and Application Engine statements. See Code & SQL Search.
Planned Capabilities
Security & Governance
Segregation of Duties (SoD) & Business Operation Matrix. Rule-based auditing to detect users holding conflicting access grants across critical business operations (e.g. creating vendor definitions and approving vouchers, or modifying employee banking details and running payroll).
Cross-Environment Security Object Comparison. Direct drift comparison of Roles, Permission Lists, and User account assignments across DEV, TEST, and PROD, identifying permission creep and unauthorized production modifications.
Object Labeling and Pillar Classification. Tagging and categorizing PeopleSoft objects by business pillar (HCM, FSCM, CS) or custom organizational tags to scope audits, access reviews, and alerts.
Administration & Observability
Admin-Facing Session Management UI. Administrative interface to inspect active user sessions, view authentication metadata, and invalidate sessions individually or in bulk. See Authentication & Access → Session Management.
Prometheus /metrics Endpoint. Metric scrape endpoint exposing HTTP request latency, active database connection health, SWS query rates, and alert check durations for Prometheus and Grafana. See Deployment & Operations → Monitoring.
Search Framework & Index Health. Status checks and health diagnostics for OpenSearch and Elasticsearch clusters configured in the PeopleSoft Search Framework.
Compliance & Supply Chain
SOC 2 Type II Certification. Formal SOC 2 audit engagement and certification. See Compliance & Vendor → SOC 2.
Container Image Signing & SLSA Provenance. Sigstore Cosign image signatures and automated SLSA build provenance attestations for container image distribution. See Code & Supply Chain.
Missing a report, alert, or automation?
We are open for product feedback. New reports and alerts are modules in an existing framework (the 26 reports and 18 alert types in psLens today were added one module at a time), so a request that fits that framework is usually the fastest kind of item to ship.
If your audit needs a report psLens does not have, or you want a recurring security check automated, tell us. psLens is onboarding design partners, and partner requests set the build order.
How to influence the roadmap
Three ways an item moves up the queue:
It blocks a deal. Tell us during contracting.
It blocks a deployment in progress. Tell us in the customer Slack channel or via the contact page.
It is something many customers have asked for independently. We watch for patterns across customer conversations and re-rank when one emerges.
We do not run a public voting board. We do read every email.
14 - FAQ
Frequently asked questions about psLens: supported PeopleTools versions, security, deployment, and commercial terms.
Frequently Asked Questions
Quick answers to the questions we get most often. If your question is not here, reach out through the contact page.
Getting Started
Do I need App Designer to use psLens?
No. psLens is an alternative to opening App Designer for research, auditing, and monitoring work. Your developers still use App Designer for building and modifying PeopleSoft objects. psLens is for everything else (search, security audits, process monitoring, IB monitoring, reporting).
How long does setup take?
A typical first-time install is under an hour of real work: install the SWS framework in your PeopleSoft environment, deploy your psLens instance, point it at your SWS endpoint, and log in. The installation guide walks through every step with Docker and bare-metal examples.
Can I try psLens without installing the SWS framework?
No. SWS is how psLens reaches PeopleSoft; there is no alternate data path. The demo is the right way to see it running against a live environment before you commit to an install. SWS documentation lives at sws.books.cedarhillsgroup.com.
Which PeopleTools versions are supported?
psLens relies on standard PeopleTools metadata tables (PSRECDEFN, PSPNLDEFN, PSCLASSDEFN, process scheduler tables, Integration Broker tables) that have been stable for many PeopleTools releases. If you are on a currently supported PeopleTools release, psLens will run against it. Ask on the demo call if you have a specific version in mind.
What is the technology stack used by psLens?
A single Go binary. Rendering happens server-side and updates are pushed to the browser as HTML fragments over Server-Sent Events using Datastar. There is no React or Angular bundle to ship, and nothing from PeopleSoft is cached in the browser. See the Architecture Overview for details.
Security
Is psLens really read-only?
Yes. psLens does not have a code path that writes to PeopleSoft. It issues read queries through the SWS framework, which itself only answers queries against a whitelisted set of metadata tables. See the Security & Trust page for the full story.
What permissions does the SWS service account need in PeopleSoft?
Read access to the whitelisted PeopleTools metadata tables. No write access. No access to transactional business tables. The whitelist ships with psLens and SWS; you can review and narrow it before you approve it in your environment.
Does psLens store a copy of our PeopleSoft data?
No. psLens stores two things: alert history (short retention, meant to show what is currently wrong) and report output (kept for 90 days so you can review past audit findings). It does not copy employee records, financial transactions, HR data, or any other business data into its own storage.
There can be some temporary caching in memory on the server to facilitate rendering and alert/report generation, but this is short-lived and does not persist beyond the lifetime of the request or the retention period for alerts and reports.
Where does the data live?
Inside your dedicated psLens instance. Every customer gets their own isolated deployment; there is no shared multi-tenant backend. See Security & Trust for deployment isolation details.
Does psLens cache or store PeopleSoft data in my web browser?
No. psLens renders pages on the server and streams them as HTML fragments. The browser displays the HTML; it does not write metadata or credentials to LocalStorage, SessionStorage, or IndexedDB. As soon as the browser tab is closed, the data is cleared from client memory.
Deployment
Can I host psLens inside my own infrastructure?
Yes. The default is a dedicated instance hosted on fly.io, but psLens ships as a Go binary and a Docker image, so you can run it in your own cloud account, Kubernetes cluster, or on a Linux VM. The installation guide covers Docker, systemd, and air-gapped setups.
Does psLens work in an air-gapped environment?
Yes. The installation docs include instructions for environments with no outbound internet access. psLens does not phone home and does not require outbound connectivity at runtime beyond reaching your SWS endpoint.
How do upgrades work?
Upgrades replace the psLens binary or Docker image. Configuration stays in config.yaml or environment variables. Alert and report history is preserved across upgrades. See the upgrade section of the installation guide.
Day-to-Day Use
Can psLens connect to multiple PeopleSoft environments?
Yes. A single psLens instance can be configured to connect to multiple databases (DEV, TEST, PROD). The database selector appears on every search and report page. See configuration.
Can I compare objects across environments?
Yes. The Project Compare report compares project items across databases, useful after migrations to confirm what actually landed where.
Can I share or export what I find?
Yes. Every PS object detail page and every completed report can be exported as Markdown. The output is plain text that works in wikis, PRs, documentation sites, or as input to AI tools. See the AI enablement use case.
Commercial
How is psLens sold?
psLens is sold as a flat-rate subscription of $500/month with unlimited seats/users and unlimited PeopleSoft environments, plus a one-time setup fee: $2,500 for CHG-managed deployments or $4,500 for self-hosted. What each fee covers, and why self-hosting costs more, is on the pricing page.
Note: Standard pricing applies to single-organization end-users only. It does not apply to hosting providers, managed service providers (MSPs), or organizations that host and manage PeopleSoft databases for multiple third-party clients. Contact us for multi-client custom pricing.
What kind of support is included?
Setup assistance is included with every deployment. Ongoing support terms are part of the agreement and vary by customer. We will walk through it on the demo call.
Who builds psLens?
psLens is built by Cedar Hills Group, a PeopleSoft consultancy. The same team that built the SWS framework builds psLens.
Code & Supply Chain
Can we review the source code?
psLens is closed-source, but Cedar Hills Group offers a read-only source review under NDA as part of procurement. See Code & Supply Chain for details.
Is the code scanned for vulnerabilities?
Yes. We use govulncheck in our continuous integration pipeline to detect known Go package vulnerabilities on every build and run daily scans. Dependabot is enabled to monitor and automatically raise pull requests for dependency updates (Go modules, GitHub Actions, and Docker base images). See Code & Supply Chain.
Yes. psLens natively supports OpenID Connect (OIDC) Single Sign-On (Microsoft Entra ID, Okta, Keycloak, Auth0, Google Workspace) configured directly in config.yaml. Alternatively, you can front psLens with a reverse proxy that handles SSO (Cloudflare Access, oauth2-proxy, Pomerium, Tailscale). See Authentication & Access.
Does psLens have role-based access control?
No, by design. Because psLens is read-only and the query surface is whitelisted on the PeopleSoft side, the access boundary is “who can log in to psLens at all,” not “what role do they have inside it.” Per-user authorization is enforced at the reverse-proxy / IdP layer if you need it.
This is something we are exploring in a future release, pending customer feedback.
How are passwords stored?
No end-user passwords. psLens uses email magic-link, native OIDC, or reverse-proxy SSO. The only password-shaped secret psLens holds is the SWS service-account credential, encrypted at rest with AES-256-GCM. See Data Handling & Logging → Encryption.
Can we require MFA?
Yes. Enforce MFA at the IdP layer with native OIDC or reverse-proxy SSO. Magic-link auth on its own is single-factor.
Audit & Logging
Where do logs go?
psLens writes structured logs to stderr only. Your container runtime decides what happens next: Docker logging driver, systemd journal, fly.io log stream, or Kubernetes log shipper, then on to your SIEM.
Does psLens retain logs?
No. psLens does not manage log retention. Whatever your container runtime or log aggregator does is what you get. This is intentional, so your existing log-retention SLA covers psLens without us getting in the way.
Compliance
Are you SOC 2 certified?
Not yet. Certification is on the roadmap. In the interim, Compliance & Vendor maps the relevant Trust Service Criteria to current controls, and we complete SIG / CAIQ questionnaires in detail.
Where does our data physically live?
In your dedicated psLens instance. Managed deployments run in the fly.io region you choose at provisioning. Self-hosted: wherever you run the container. There is no shared multi-tenant backend, so there is no other location for data to exist.
Who are your sub-processors?
Depends on your deployment mode. For managed deployments: fly.io (hosting) and the SMTP provider for magic-link auth (if enabled). GHCR is touched only at docker pull time, not at runtime. Self-hosters have none of the above. See Compliance & Vendor → Sub-Processors.
What happens if Cedar Hills Group goes away?
You keep the Docker image you’re running, and self-hosting works without any Cedar Hills Group infrastructure. All state is in the per-customer /data volume, portable to your own infrastructure on demand. See Compliance & Vendor → Business Continuity.
Pending customer feedback, we can potentially look at a code escrow of the GitHub source code.
Operations
What load does psLens put on my PeopleSoft environment?
Small, and you control all of it. There are three sources of queries:
Browsing and search run on demand when someone uses the UI. Each page issues a handful of paged queries against PeopleTools metadata tables, comparable to a person opening a page in PIA. There is no background crawler or sync job; psLens fetches what is on screen and nothing else.
Alert checks are the only recurring traffic. They run on a configurable interval (default every 5 minutes), and each check is a small number of bounded queries. You can change the interval per database, disable individual checks, or turn alerting off entirely for an environment. See configuration.
Reports run only when someone starts one.
All of this arrives through the Integration Broker REST endpoint as ordinary service operation requests, so it appears in your existing IB monitoring like any other integration. psLens never opens a connection to the database itself.
What exactly does SWS install in my PeopleSoft environment?
A standard App Designer project (CHG_PSLENS), migrated dev-first through your normal change process: 46 objects under the CHG_ prefix, 1 record (the whitelist table), two service operations, and one API role/permission list. What SWS Installs in PeopleSoft lists the full breakdown for the admin, DBA, or security reviewer who has to approve it.
What’s the backup procedure?
Tar /data/nats and /data/projects nightly; back up PSLENS_MASTER_KEY separately and out-of-band. Restore is “untar into a fresh volume and start the container.” See Deployment & Operations → Backup.
There is no critical data stored in the application and technically, all the data could be left behind in the event of a failure. The backup procedure is primarily for convenience and peace of mind, not a strict requirement for disaster recovery.
How do I upgrade?
Pin production to vMAJOR.MINOR, then docker compose pull && docker compose up -d. The data volume survives the restart. Roll back by pinning to the prior patch tag. See Deployment & Operations → Upgrades.
What’s the resource footprint?
Small. 1 vCPU and 512 MB RAM as a minimum, 1 GB disk for /data. psLens is a single Go process; scaling is vertical. See Deployment & Operations → Sizing.
What network egress does psLens need?
HTTPS to your SWS endpoint, and SMTPS to your mail server only if magic-link auth is enabled. Nothing else: no telemetry, no update checks, no callback to Cedar Hills Group. Egress filtering is straightforward.
Does psLens have a Prometheus endpoint?
Not today. GET /healthz covers liveness; structured slog covers everything else. A native /metrics endpoint is on the roadmap.
15 - Use Cases
See how different PeopleSoft team members use psLens: developers, security administrators, system administrators, and business analysts.
Look up a record without opening App Designer. Catch a stuck IB message before users do. Audit who can run a web service from one screen.
Developers
Search records, fields, pages, components, SQL objects, and application packages from a browser. No App Designer VM, no menu navigation.
Reports surface permission lists granting access to hundreds of components, nodes without passwords, and web service endpoints anyone with PTPT1000 can call. Trace access from users through roles to permission lists in one screen.
Understand PeopleSoft configuration without needing App Designer or database access. Research components, security setup, and page structure independently.
Stop granting developer tools for research tasks. psLens gives your team read-only access to PeopleSoft object definitions without the security risk of App Designer.
Export PeopleSoft objects to Markdown and feed them to ChatGPT, Claude, or Copilot for code review, documentation, impact analysis, and knowledge transfer.
How PeopleSoft developers use psLens to trace impact before changes, understand unfamiliar customizations, and answer lookups without App Designer.
The Daily Grind
You are working on a customization. You need to check the structure of PSOPRDEFN, find which pages reference a specific record, or look up a Message Catalog entry. So you open a remote desktop session to the App Designer VM, wait for it to connect, launch App Designer, wait for it to load against the database, navigate through menus, and eventually find what you need. Then you do it again. And again.
The lookups are the annoyance. The bigger risk is what you don’t look up: the fourth page that references the record you are about to change, or the self-service role that exposes the component you assumed was internal. In a system customized over fifteen or twenty years, nobody holds the full picture in their head.
Walkthrough: How developers use psLens to speed up daily lookups
How psLens Changes This
What Breaks If I Change This Record?
Before you modify a record, you want the full list of what touches it. In App Designer that is a Find Definition References run: one object at a time, inside a tool session. In psLens, every object page links to its relationships, so the same question is a click:
Records: every field, the key structure, and the pages and components that reference the record
Fields: every record that uses the field, plus translate values
Pages: the components that contain the page and the menu path to reach it
Components: the pages inside, the permission lists that grant access, and the menu navigation
Application Packages: the full class hierarchy
Impact analysis stops being a separate research task and becomes part of reading the object.
Who Can Actually Reach This Component?
The change that hurts is rarely the one that fails in testing. It is the one that works and turns out to be reachable by a role you did not know about. From any component page, psLens shows the permission lists that grant access, the roles that carry them, and the users those roles reach. Check exposure before you ship the change, and confirm it again after the migration.
What Does This Customization Even Do?
Every object page exports to structured Markdown, including PeopleCode. That makes AI tools useful on legacy work:
Export an application package or project and ask Claude or ChatGPT to explain it in plain language
Hand a project’s PeopleCode to an LLM for a code review before the release
Generate a technical spec or onboarding doc from the real definition instead of a stale wiki
psLens does the exporting; the LLM does the reading. Neither step needs App Designer.
Skip the Launch Sequence for Lookups
Type a record name, field name, or any object identifier and results render as you type. Filter to a single object type or search across all of them at once. The minutes you used to spend reaching App Designer become the time it takes to type the name.
Answer a Teammate With a Link
Every object in psLens has a permanent URL. Instead of telling a colleague “look at the DERIVED_HR record in App Designer,” send a link. It works in Jira tickets, code review comments, Slack threads, wiki runbooks, and onboarding materials — and the person on the other end needs a browser, not a VM.
Keep App Designer Access Tight
App Designer is a full development environment. It connects directly to your PeopleSoft database (two-tier), can modify any object, view all PeopleCode, and run arbitrary SQL. That level of access is appropriate for developers who are actively building, not for lookups.
Because App Designer is a Windows-only desktop client that requires specialized network access, most organizations provision dedicated VMs or terminal servers just to run it. That infrastructure needs to be maintained, patched, and secured.
When developers use psLens for day-to-day research, they spend less time in App Designer. That means fewer VM sessions, less infrastructure to maintain, and App Designer access stays scoped to the people who actually need it.
How PeopleSoft security administrators use psLens to audit access, run security reports, and manage permission lists, roles, and users.
The Challenge
PeopleSoft security is complex. Users are assigned to roles. Roles contain permission lists. Permission lists grant access to components, pages, and web services. Understanding who has access to what means tracing through multiple layers, often across dozens of screens or with custom SQL queries.
An overly-broad permission list can expose sensitive data; a forgotten role assignment can give someone access they should not have. Manual review misses both because there is too much to check.
Walkthrough: How security administrators audit access and trace permissions in psLens
How psLens Changes This
Automated Security Reports
psLens includes built-in security audit reports that analyze your configuration and surface findings automatically:
Full Access Report: Identifies permission lists with unusually broad access across components
Nodes Without Passwords: Flags integration nodes configured without authentication
Web Service Access Report: Shows which permission lists can invoke web services and REST endpoints
Reports run in the background and store results for review, download, and sharing. Run them on demand or schedule them as part of your regular audit cycle.
Permission List Deep Dives
Search for any permission list and instantly see:
Component access grants
Page-level permissions within each component
Which roles include this permission list
Which users are ultimately affected
You skip the SQL and the page-by-page click-through.
Role and User Tracing
Start from any direction:
From a user: See all assigned roles and the permission lists they carry
From a role: See which users have it and what permission lists it contains
From a permission list: See which roles use it and which users are affected
Security Chain Visualization
Understanding the full security chain (User > Roles > Permission Lists > Component Access) usually means opening multiple windows and cross-referencing. psLens links everything together — click through the chain from any starting point.
A security review starts from any point in the chain and stays in one linked workflow instead of jumping between tools and SQL
Reduce App Designer Access
One of the simplest ways to improve your security posture is to remove App Designer access from people who only use it for research. Business analysts, functional consultants, auditors, and support staff often have App Designer access because there is no other way to look up PeopleSoft metadata. psLens gives them that capability without the ability to modify objects, run SQL, or connect directly to the database. See Reducing App Designer Access for details.
How PeopleSoft system administrators use psLens to monitor processes, Integration Broker, and get real-time alerts on problems.
The Problem
You find out about problems when users call. A batch process failed overnight. Integration Broker messages have been stuck for hours. A long-running process is blocking the queue. By the time someone notices, the impact has already spread.
Checking manually means logging into PeopleSoft, navigating to Process Monitor or IB Monitor, setting filters, and scanning for issues. Multiply that by the number of environments you manage.
How psLens Changes This
Real-Time Alerts
psLens runs background checks every few minutes and surfaces problems on the dashboard as they happen.
9 built-in alert types:
Long-Running Processes: Jobs running longer than expected thresholds
How business analysts use psLens to understand PeopleSoft configuration, research components, and make informed decisions without developer tools.
The Gap
You need to understand how something works in PeopleSoft. Maybe you are writing requirements for a customization. Maybe you are trying to understand why a process behaves a certain way. Maybe you need to know what data a page collects and where it goes.
But the tools for answering these questions — App Designer, SQL Developer, PeopleSoft’s technical pages — are built for developers. They require licenses, training, and technical knowledge that is outside your role. They are also fragmented: object definitions in App Designer, security in one set of PIA pages, process schedules in another, integrations in a third, each with its own access grant. Nobody hands an analyst all of that just to answer a question. So you ask a developer. They look it up and get back to you later. Or you wait.
Walkthrough: Using psLens to speed up daily lookups
How psLens Changes This
Self-Service Research
psLens gives you a web browser interface to explore PeopleSoft configuration without needing developer tools or database access. Search for any object by name and see its definition, structure, and relationships.
You don’t need an App Designer license, SQL skills, or a developer’s time.
This also means you do not need App Designer access just to research metadata. App Designer is a full development tool: it can modify objects, run SQL, and connect directly to the database. Granting it for research gives people far more access than they need. psLens provides the research capabilities without that risk. See Reducing App Designer Access for the full picture.
See the Parts App Designer Never Showed
Analyst questions usually cross tool boundaries: what data does this page collect, who can see it, and where does it go? Even a developer with full App Designer access cannot answer all three from one tool, because security, scheduling, and integration configuration live in separate PIA administration pages. psLens puts them in one place:
Security: trace User > Role > Permission List > Component without access to any PIA security pages
Schedules: see process definitions, recurrences, and run history to answer “when does this run, and did it?”
Integrations: follow nodes, service operations, and routings to answer “where does this data go?”
Queries: read a query’s SQL without Query Manager access, which would also let you run queries against live data
Understand Page and Component Structure
Need to know what fields are on a page? What record drives a component? Which menu path leads to it? Search for the component or page name in psLens and see:
The pages within a component
The records and fields on each page
The menu navigation path
The security (permission lists and roles) that control access
Research Security Configuration
When you need to understand who can access what:
Search for a user and see their roles
Search for a role and see its permission lists
Search for a permission list and see what it grants access to
Trace the full chain without asking anyone for help
Share What You Find
psLens deep links let you share a direct URL to any PeopleSoft object. Include links in your requirements documents, Jira tickets, or emails. When someone clicks the link, they see exactly what you are referencing, no instructions needed.
Export to Markdown for inclusion in documentation, presentations, or analysis.
Bridge the Communication Gap
One of the hardest parts of working with PeopleSoft is the gap between business needs and technical implementation. psLens helps bridge that gap by giving non-technical team members visibility into the technical side:
Understand what fields exist on a record before writing requirements
See how components are structured before requesting changes
Review security configuration before requesting access changes
Cite “PS_PERSONAL_DATA, field BIRTHDATE” in a Jira ticket and paste the psLens deep link, so the developer does not have to guess which page you meant
Common BA Tasks in psLens
Task
What You See
Research a component
Pages, records, fields, menu path, security
Understand a record
All fields with types, keys, descriptions, and labels
Check who has access
User > Role > Permission List > Component chain
Understand an integration
Nodes, service operations, routings, and queues
See when a process runs
Process definitions, schedules, and run history
Document a process
Export object definitions to Markdown
Write requirements
Reference exact field names, record structures, and component layouts
Why granting App Designer access for metadata research creates unnecessary risk, and how psLens provides a safer alternative with read-only browsing.
The Problem
Someone on the team needs to look something up in PeopleSoft. Maybe a business analyst is writing requirements and needs to see what fields are on a record. Maybe an auditor needs to understand how security is configured. Maybe a functional consultant needs to trace a component’s menu path.
The default answer is: give them App Designer.
This happens because App Designer is the only tool that lets you browse PeopleSoft object definitions. There is no read-only alternative built into PeopleSoft. So people who only need to look things up end up with the same tool that developers use to build and modify the application.
Walkthrough: Replacing App Designer with psLens for read-only metadata lookups
What App Designer Access Actually Grants
App Designer is a full development environment. When you give someone App Designer access, you are giving them the ability to:
Open and modify any object definition: records, pages, components, Application Engine programs, PeopleCode, and more
View all PeopleCode source across the entire application
Use SQL Editor to run arbitrary queries directly against the database
Create and migrate projects between environments
Connect directly to the database. App Designer requires a two-tier connection, which means the user’s workstation has network-level access to the database server.
Require specialized infrastructure. Because of the two-tier connectivity requirement, organizations often provision dedicated virtual machines or terminal servers just so users can run App Designer. That is additional infrastructure to maintain, patch, and secure, all so someone can look something up.
And critically: App Designer activity is difficult to audit. There is no built-in log of which objects a user opened, viewed, or modified through the tool. You are trusting that users will only do what they are supposed to do, with no way to verify.
App Designer Was Never the Whole Picture
App Designer covers development objects: records, pages, components, PeopleCode. A large part of what research users actually ask about was never in App Designer at all. Security configuration (user profiles, roles, permission lists), Integration Broker nodes and service operations, Process Scheduler definitions and run history, queries, and portal content references all live in PIA administration pages.
That creates a second access problem. The PIA components that display this configuration are, for the most part, the same components that edit it. Granting “just read” access means configuring and maintaining display-only settings across dozens of components, and some of those pages are risky on their own: Query Manager access to read a query’s SQL also grants the ability to run queries against application data.
psLens covers both halves in one read-only interface. An analyst can read a record definition, trace the security chain that guards it, see which process populates it, and read the SQL of the query that reports on it, without holding App Designer, PIA admin pages, or Query Manager.
The Principle of Least Privilege
Least privilege is straightforward: give people the minimum access they need to do their job. If someone needs to look up a record definition, they should not need a tool that can also modify that record, run SQL against the database, and view every line of PeopleCode in the system.
This is not a theoretical concern. Internal and external auditors (SOX, SOC 2, and others) increasingly ask about developer tool access:
Who has App Designer access?
Why do they have it?
What controls exist to prevent misuse?
When the answer is “they have it because they need to look things up and there is no other way,” that is a gap psLens removes by giving the same researchers a read-only browser UI with no SQL, no PeopleCode write access, and no database connection.
How psLens Compares
Capability
App Designer
psLens
View object definitions
Yes (plus can modify)
Yes (read-only)
View PeopleCode source
Yes
Yes (read-only)
View users, roles, and permission lists
No, separate PIA admin pages
Yes (read-only)
View Process Scheduler and IB configuration and runtime
No, separate PIA pages
Yes (read-only)
Modify PeopleSoft objects
Yes
No, by design
Run SQL queries
Yes (SQL Editor)
No
Database connectivity
Direct two-tier connection
None, uses web services API
Infrastructure
Desktop client, often a dedicated VM or terminal server
License savings. PeopleTools client licenses are not free. Every user who moves from App Designer to psLens is a license you do not need to maintain.
No desktop installation or VM access. App Designer requires installation on a workstation or access to a dedicated virtual machine or terminal server. psLens runs in any browser, no specialized infrastructure needed.
Immediate productivity. New team members can start researching PeopleSoft configuration on their first day. No App Designer training, no connectivity setup, no waiting for access provisioning.
Access from anywhere. psLens is a web application. No VPN or direct database connectivity required (depending on your network configuration).
Who This Applies To
Any role that uses App Designer primarily for research rather than development:
Business Analysts: researching components, records, and page structures for requirements
Functional Consultants: understanding configuration and tracing security chains
Auditors: reviewing security setup, permission lists, and access grants
Support Analysts: looking up object definitions during incident investigation
Project Managers: understanding scope and impact of proposed changes
New Team Members: learning the system during onboarding
If they are not writing PeopleCode or building projects, they probably do not need App Designer.
How psLens exports PeopleSoft metadata as Markdown so AI and LLM tools like ChatGPT and Claude can read objects, code, and projects.
The Problem: PeopleSoft Is a Black Box to AI
PeopleSoft hides its source code from the filesystem. Object definitions live in a relational database, not in files. PeopleCode is embedded in the runtime, not on a filesystem where tools can read it. There are no Git repositories, no IDEs with language server support, no standard ways to extract metadata programmatically.
This means AI tools like ChatGPT, Claude, and Copilot cannot see your PeopleSoft system. They have general knowledge of PeopleTools concepts, but they have no way to read your specific records, your PeopleCode, your component structure, or your security configuration. You cannot point an LLM at your PeopleSoft environment and ask it to help.
Unless you can get the data out first.
How psLens Exports PeopleSoft for AI
psLens exports PeopleSoft object definitions to structured Markdown. Every object type has a one-click export, and the output works in two places:
Web chat boxes like ChatGPT and Claude. Paste the Markdown into the conversation and the model reads the full object definition with structure preserved.
Local AI coding agents like Claude Code, Cursor, and Aider. Save the export as a file in your project and the agent reads it as context the same way it reads any other source file.
Both paths use the same Markdown artifact. Pick whichever your team already works in.
See the Artifact Before You Install
If you want to inspect the kind of plain-text output psLens produces before deploying anything, start with Sample Report Output. Those files are real exported Markdown documents from a development environment, with only hostnames and service-account names changed.
The export is structured Markdown, not a flat text dump, so AI tools keep the hierarchy, tables, and code context intact
What You Can Export
Object Type
What the Export Contains
Records
Field definitions, types, keys, lengths, descriptions, labels, sub-records, SQL definitions, related pages, PeopleCode events, project membership
Fields
Field metadata, translate values, labels, records using the field, PeopleCode references
Pages
Controls and fields, records used, subpages, parent pages, components using the page, PeopleCode events
Components
Pages, menu paths, portal navigation, search records, component interfaces, PeopleCode events, related records
Projects
All project items with counts, PeopleCode source inline, SQL definitions, stylesheets, HTML objects — everything in one document
Application Packages
Package hierarchy, all PeopleCode by class, service operations, references
PeopleCode
Full source code for any PeopleCode program, organized by event or method
Exports include links between related objects so the AI can understand how things connect, not just what a single object looks like in isolation.
Recursive Reference Resolution
For objects containing PeopleCode (such as records, components, application packages, or app engines), enabling Recursively resolve imports in the export card instructs psLens to scan the source code for:
Application Class imports (e.g. import PACKAGE:SubPackage:Class;)
External function declarations (e.g. Declare Function Name PeopleCode RECORD.FIELD Event;)
The exporter fetches the source code for each referenced package class and declared function from the database. It appends the resolved code to a ## Resolved PeopleCode References section at the end of the document. This generates a self-contained snapshot containing both the primary object and all its dependencies, providing the complete context required by AI models without manual retrieval.
What You Can Do With It
Code Review and Analysis
Export a project or application package and ask an LLM to:
Review PeopleCode for bugs, performance issues, or security concerns
Explain what a complex Application Engine does step by step
Identify unused variables, dead code paths, or redundant logic
Compare coding patterns across different programs
Flag SQL injection risks or other vulnerabilities in PeopleCode
PeopleSoft developers have always done code review by reading PeopleCode in App Designer one program at a time. With psLens exports, you can hand an entire project’s worth of code to an AI and get a full review in minutes.
Technical Documentation
Export objects and ask an LLM to generate:
Technical specification documents for existing customizations
Data dictionary entries from record and field exports
Component documentation including page flow, security, and data relationships
Migration guides based on project contents
Onboarding documentation for new team members unfamiliar with a module
This is especially valuable for undocumented customizations — the ones everyone is afraid to touch because nobody remembers what they do or why they exist.
Impact Analysis
Before making a change, export the relevant objects and ask an LLM:
“What would break if I added a field to this record?”
“Which components and pages use this record?”
“What PeopleCode references this field?”
“If I change this Application Engine step, what downstream effects should I test?”
psLens exports include the relationship data that makes this possible: which pages use a record, which components include a page, which projects contain an object, and where PeopleCode references exist.
Knowledge Transfer
PeopleSoft environments accumulate decades of customizations. The people who built them leave. Documentation is incomplete or nonexistent. New team members struggle to understand what exists and why.
Export key objects and projects to Markdown and use an LLM to:
Generate summaries of what a customization does and why it might exist
Create Q&A-style knowledge base articles from raw object definitions
Translate technical PeopleSoft structures into plain language for non-technical stakeholders
Build training materials from actual system configuration
Upgrade and Migration Planning
When preparing for a PeopleTools upgrade or a move to PeopleSoft Cloud:
Export projects containing customizations and ask an LLM to assess upgrade risk
Identify PeopleCode patterns that may be deprecated in newer PeopleTools versions
Generate a catalog of all custom objects with descriptions and dependencies
Compare pre- and post-migration exports to verify nothing was lost
Security Analysis
Export permission lists, roles, and security configuration and ask an LLM to:
Identify permission lists with unusually broad access
Find roles that combine conflicting duties (separation of concerns)
Generate audit-ready documentation of who has access to what
Recommend security consolidation opportunities
Using Exports With Local AI Coding Agents
The same Markdown export that works in a chat box works as a context file for a local agent. The usage pattern is:
Open the object detail page in psLens and click Export as Markdown. The file lands in your downloads folder.
Move it into the workspace your agent has access to. For Claude Code or Cursor, that is typically the repo you have open. A context/peoplesoft/ folder is a useful convention.
Reference the file in your prompt. For example, in Claude Code: Review @context/peoplesoft/PROJECT_HCM_CUST.md and flag any PeopleCode that does unbounded SQL. The agent reads the file as part of the conversation context.
This pattern works for any agent that reads files: Claude Code, Cursor, Aider, Continue, the local-MCP-host model in your IDE. The agent gets the same structured definition a chat user would paste, with the same one-click export workflow on the psLens side.
For repeated work against the same set of objects (a customization you maintain, an Application Engine you keep reviewing), keep the exported file in version control alongside the agent’s other context.
Why Markdown Matters
LLMs work best with structured text. Markdown gives them:
Clear hierarchy: headings, sections, and subsections that establish context
Tabular data: field definitions, metadata, and relationships in a format LLMs parse well
Inline code: PeopleCode and SQL in fenced code blocks that LLMs recognize as code
Links and references: relationships between objects that provide the context an LLM needs to give useful answers
Other export formats (CSV, PDF, screenshots) lose structure, context, or both. Markdown preserves everything.
The PeopleSoft AI Gap
Most enterprise platforms have moved toward open formats, APIs, and file-based source code that AI tools can access natively. PeopleSoft has not. Its metadata is locked in database tables, its source code is embedded in the runtime, and its object definitions require App Designer or direct SQL to access.
psLens bridges that gap. It reads PeopleSoft metadata through web services and exports it in the format that AI tools consume best. Your team does not need database access, App Designer, or custom SQL to feed PeopleSoft data to an LLM. They just click export.
Live AI Access: Embedded MCP Server
The export-and-paste workflow above works with any chat interface or file-based tool. To enable direct, autonomous agent workflows, psLens includes an embedded Model Context Protocol server.
The MCP server runs natively inside psLens over Streamable HTTP and HTTP+SSE. It exposes 20+ specialized tools across metadata exploration (search_objects, get_object_definition, get_peoplecode), security graphs (user_access_summary, who_has_access), and operational incident triage (get_system_health, triage_process_scheduler, triage_integration_broker). See the MCP Server Guide for configuration instructions and tool catalogs.
Why PeopleSoft teams use psLens for read-only metadata research, security review, and operational monitoring without broad App Designer or database access.
Read-Only by Design
Broader visibility into PeopleSoft, without broader access.
psLens gives PeopleSoft teams a read-only way to research metadata, review security, and monitor operations without handing out broad App Designer or database access.
It is built for the work that happens around production systems every day: understanding what exists, tracing access, sharing findings, and spotting issues early.
Most PeopleSoft teams use change tools for read-only work. They open App Designer to inspect a record, write SQL to trace security, or refresh Process Monitor and IB Monitor until a problem appears. That works, but it is slow, hard to share, and broader than many team members need.
psLens covers that day-to-day work in a browser. It gives teams one place to research object definitions, run repeatable audit reports, and watch for operational problems that should not wait for the next manual check.
What psLens Changes in Daily Work
Metadata Research Without App Designer
Search records, components, roles, permission lists, messages, and other PeopleSoft objects from a browser instead of opening a desktop client just to look something up. Each object page has a permanent URL, so the result can go straight into a ticket, wiki, or chat thread.
For teams that document configuration, psLens also exports object pages as Markdown. That removes the screenshot-and-copy-paste loop that usually follows App Designer or SQL research.
Security Review Without Custom SQL
Security review is one of the clearest gaps in standard PeopleSoft tooling. psLens ships with 14 on-demand reports, including Full Access Permission Lists, Nodes Without Passwords, and Web Service Access. Results are rendered in the browser, downloadable as Markdown, and stored for 90 days for follow-up and audit history.
The same UI also lets you trace the security chain in either direction. Start from a user, role, permission list, or component and click through the relationships instead of stitching together queries across PSROLEUSER, PSROLECLASS, and PSAUTHITEM. See Security Admins for the workflow.
Operational Monitoring Without Manual Page Checks
psLens runs 16 alert types on a 5-minute timer across connected databases. That covers Process Scheduler failures, long-running jobs, locked operator IDs, Integration Broker contract errors, stalled messages, sync exceptions, and volume anomalies.
Instead of waiting for a user ticket or refreshing monitoring pages by hand, the dashboard shows current findings and clears them automatically when the condition resolves.
Knowledge Sharing Without Screenshots
PeopleSoft knowledge usually gets trapped inside App Designer sessions, SQL results, or someone’s local notes. psLens makes that work easier to share because pages are read-only, linkable, and exportable.
That matters for onboarding, production support, and cross-team reviews. A developer can send the exact record or component page to an analyst. A security reviewer can attach a report result. A support lead can point a new team member at the same screen everyone else is using.
Where psLens Fits
psLens is not a replacement for App Designer. App Designer is still the right tool for:
Creating and modifying PeopleSoft objects (records, pages, components)
Writing and debugging PeopleCode
Building and deploying projects
Managing data migration
psLens is the better fit when the job is read-only and operational:
Researching object definitions and relationships
Auditing security configuration
Monitoring processes and Integration Broker
Onboarding new team members
Sharing PeopleSoft knowledge across teams
Day-to-day production support
App Designer requires a client install, training, and access to a tool that can modify the system. psLens runs in a browser and keeps the workflow read-only.
That matters because App Designer is a trusted-developer tool. It belongs in the hands of people who are expected to build, change, and migrate PeopleSoft objects. Handing it to a wider audience just so they can look something up expands risk in two directions at once: security exposure and system stability.
For team members who only need to inspect metadata, trace access, review operations, or answer audit questions, App Designer grants far more capability than the task requires. It opens the door to object changes, SQL access, and direct interaction with production systems through a tool designed for development work.
psLens is the safer way to widen visibility. Business analysts, auditors, support staff, project managers, and new team members can research PeopleSoft objects without getting the keys to the kingdom. They get read-only pages, reports, and links. They do not get object editing, SQL tooling, or direct database connectivity. In production environments, that separation is often the difference between broad understanding and broad risk. See Reducing App Designer Access for the full case.
Comparison at a Glance
The day-to-day question is not which tool can do everything. It is which tool is the best fit for research, audit, and monitoring work.
Capability
App Designer
Direct SQL
psLens
Runs in a web browser, no client install
✗
~
✓
Read-only by design (safe for broad team access)
✗
✗
✓
Browse security setup, process schedules & IB config (PIA-side objects)
✗
~
✓
Fast object search for read-only research
✗
~
✓
Built-in audit & security reports
✗
✗
✓
Background alerts for Process Scheduler & IB
✗
✗
✓
Markdown export for docs and AI workflows
✗
✗
✓
Permanent URL for every object page
✗
✗
✓
Cross-database project comparison
~
~
✓
Right tool for building & modifying objects
✓
~
✗
Legend:✓ Strong fit ·
~ Possible but awkward or partial ·
✗ Not supported
Why Teams Roll It Out Broadly
Read-Only Access for More Roles
The browser UI changes who can safely participate. Teams no longer need to choose between keeping PeopleSoft knowledge locked inside a small developer group or handing out a development tool that can change the system.
With psLens, business analysts, auditors, support staff, project managers, and new team members can inspect the same objects trusted developers use, especially in production-facing workflows, without getting change capability. That opens up the system to the people who need visibility while keeping development-grade access narrow.
There is a coverage point here too: much of what these roles ask about was never in App Designer to begin with. User profiles, roles, permission lists, process schedules, and Integration Broker configuration live in PIA administration pages, and the components that display that configuration are mostly the same components that edit it. psLens shows all of it read-only, alongside the development objects, so widening visibility does not mean widening admin-page access either.
Permanent URLs for Any Object
Every object page has a stable URL. That makes tickets, runbooks, and review notes easier to maintain because the source page is a link, not a screenshot.
Structured Markdown for Documentation and Analysis
Report results download as Markdown, and object pages can be exported the same way. Teams use that output for internal documentation, change records, and AI-assisted review workflows where plain text works better than image-based exports.
Repeatable Audit and Monitoring Workflows
The reports and alerts pages turn one-off checks into repeatable workflows. Reports keep 90 days of history. Alerts run every 5 minutes and clear automatically when the underlying issue resolves.
Those details matter during audits and during production support. The same page that helps an analyst look up a permission list can also help a security reviewer run Full Access or Node security checks, or help an operator spot a stalled message before users escalate it.
