psLens for Developers

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.

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.

See Reducing App Designer Access for the full picture on access control.

What Developers Search Most

Get Started