Roadmap

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. The biggest direction is live, read-only AI access through MCP, followed by targeted improvements in authentication, auditability, and operational visibility.

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.

psLens as an MCP Server

The largest planned area is exposing psLens through the Model Context Protocol so AI tools (Claude Code, Claude Desktop, Cursor, Continue, and any other MCP-aware host) can query PeopleSoft live, without anyone running an export by hand first.

The current AI Enablement story documented at AI Enablement is the export-and-paste workflow. MCP removes the manual step. The same whitelisted read surface that backs the dashboard becomes the surface the agent calls.

The design

The first cut is spec’d as a read MCP: a single read-only MCP server embedded in your psLens instance. Same process, same single-tenant deployment, mounted at /mcp over the Streamable HTTP transport with API-key authentication. Nothing writes to PeopleSoft, and every query goes through the same SWS query layer and table whitelist as the dashboard, so nothing becomes reachable over MCP that the UI cannot already see.

The tool surface is deliberately small — roughly a dozen tools in three groups:

• Generic object tools. search_object, get_object, get_related, and get_peoplecode cover every object type the dashboard browses (30+ types) without needing a tool per type. A catalog resource documents the valid object types and relations so the agent can discover the surface before calling it.
• Composed shortcuts. Single calls for the questions people actually ask. user_access takes one OPRID and returns the full role and permission-list chain. who_has_access takes one object and returns everyone who can reach it. ib_monitor and audit_dangerous wrap the Integration Broker and dangerous-permission surfaces.
• Operational tools. run_report invokes any of the 14 existing reports and streams progress back to the agent, with an async job variant for long runs. list_alerts and list_databases round it out.

Alongside the tools, the server exposes resources the agent can read passively (per-database connection status, the table whitelist, the object-type catalog) and prompt templates for repeatable workflows such as user-access audits, impact analysis, and IB failure triage.

The use cases below show what this surface is for.

1. Metadata research

The core case. Every PeopleSoft object psLens browses becomes a tool the agent can call: records, fields, projects, application packages, app engines, components, pages, menus, queries, service operations, permission lists, users, message catalog entries, SQL objects.

Example agent prompt:

Open my customization repo. For every Application Engine in project HCM_CUST_2026, summarize what it does in two sentences, list its temp tables, and flag any that reference deprecated meta-SQL.

Today this requires exporting each AE to Markdown, copying them into the workspace, and prompting against the saved files. The generic object tools let the agent walk the project itself and pull each AE on demand.

2. Security and access questions

Surfaces the same data the security dashboard exposes (users, roles, permission lists, web service authorizations) as a question-and-answer tool for ad-hoc audit conversations.

Example agent prompt:

Does the user J_PETERS have access to the PROCESS_MONITOR component on PROD? Show me the role-and-permission-list chain that grants it, or confirm there is none.

The agent traces the access path live without the operator pulling a full report or writing the 4-table join by hand.

3. Operations and alert triage

The Process Scheduler, Integration Broker, and alert history surfaces are exposed as live tools.

Example agent prompt (2am triage):

Production looks sick. Pull the last 30 minutes of alert history, the current Process Monitor failure list, and the IB queue depth on PROD. Tell me what is most likely the root cause and the next thing to check.

The agent correlates across surfaces (a queued process plus a locked OPRID plus a stalled IB dispatcher) faster than a person clicking through three different pages.

4. Report automation

The 14 on-demand reports already available in the dashboard (Full Access, Stale Passwords, Node Security Audit, Dangerous Permissions, and the rest) become tools the agent can invoke and consume.

Example agent prompt (recurring cadence):

Run the security report bundle against PROD. Compare the findings to last week’s run, summarize what changed, and write a one-page Slack-ready summary highlighting any new account that gained broad access.

This is the highest-value case for security teams that want a weekly or monthly audit cadence without writing the orchestration themselves.

5. Cross-environment comparison

Project Compare and Recurring-Process Compare are already in psLens. As MCP tools they let an agent answer drift questions across DEV, TEST, and PROD without anyone clicking through the comparison UI.

Example agent prompt (post-migration):

A migration ran last night moving project HCM_RELEASE_42 from TEST to PROD. Pull the project compare, list every object that differs between TEST and PROD now, and tell me which differences are expected (newly added) versus suspicious (changed in a way that suggests a botched merge).

What this is not

• Not a write path to PeopleSoft. No tool exposes a way to change PeopleSoft data. psLens is read-only against PeopleSoft today and stays that way.
• Not a SaaS shared MCP. The MCP endpoint is part of your psLens instance, same single-tenant model as the dashboard.
• Not coupled to a specific AI vendor. MCP is an open protocol. Any client that speaks it works.

Other Roadmap Items

These are documented in context on the page where the reader is likely asking the question. The roadmap page lists them here so a reviewer can see the full surface in one place.

Authentication

• Native OIDC inside psLens. Configure your IdP directly in config.yaml without a reverse-proxy hop. See Authentication & Access → Native SSO.
• Admin-facing “kill all sessions” UI. Today the path is nats kv del auth-sessions. See Authentication & Access → Session Management.

Audit and Logging

• First-class user-action audit log. Structured per-user event log written to NATS KV with configurable retention, exportable to your SIEM. Targeted to land alongside native SSO. See Data Handling & Logging → Audit Logging.

Observability

• Prometheus /metrics endpoint. For customers who want metric-based monitoring in addition to the existing /healthz + log stream. See Deployment & Operations → Monitoring.

Compliance

• SOC 2 certification. Cedar Hills Group is not SOC 2 certified today. See Compliance & Vendor → SOC 2.

Missing a report, alert, or automation?

We are open for product feedback. New reports and alerts are modules in an existing framework (the 14 reports and 16 alerts 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:

1. It blocks a deal. Tell us during contracting.
2. It blocks a deployment in progress. Tell us in the customer Slack channel or via the contact page.
3. 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.