FAQ

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.

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 myself?

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 dedicated, managed deployment per customer. For pricing and contracting details, request a demo or email chris.malek@cedarhillsgroup.com.

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?

Dependencies are pinned in go.mod and reviewed by hand at each release; automated SCA (govulncheck, Dependabot) in CI is on the roadmap, not in place today. See Code & Supply Chain.

How do you handle vulnerability reports?

Email security@cedarhillsgroup.com. We acknowledge within one business day and coordinate disclosure with the reporter. See Code & Supply Chain → Vulnerability Disclosure.

Authentication & Access

Can we use our existing SSO?

Yes. Front psLens with a reverse proxy that handles SSO (Cloudflare Access, oauth2-proxy, Pomerium, Tailscale, nginx/Traefik with OIDC). This is the recommended production pattern today. Native OIDC inside psLens is on the roadmap. 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 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 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’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.