Frequently Asked Questions

This page collects the questions we hear most often on demos and discovery calls. The answers cross-link into the deeper documentation where appropriate. If you have a question that is not answered here, contact Chris Malek.

Buyer questions first

Is SWS used in production?

Yes. SWS has been developed and refined over more than 15 years across multiple PeopleSoft client environments — universities, public companies, and system integrators. The patterns in SWS come from real production integrations with student information systems, payroll feeds, vendor portals, and conversion projects. The publicly released SWS is the consolidated, hardened version of those patterns.

Why would I buy SWS instead of building web services myself?

You absolutely can write a one-off bespoke web service for every integration. SWS is about velocity, consistency, and the things SQL alone does not give you:

• A common JSON, XML, and CSV response format with no extra encoding code
• Automatic prompt table description lookups so VENDOR_ID = 12345 arrives as Acme Corporation for the consumer
• Built-in pagination, parameter binding, and effective-date handling
• Nested parent-child structures across joined tables — without writing PeopleCode
• Configuration that lives in a PeopleSoft setup table, not in migrated code, so you can stand a service up, iterate, and tear it down without an Application Designer migration

A traditional bespoke web service costs $3,600 to $13,000 to develop. SWS turns that into a configuration step. See SWS Alternatives for the full comparison.

How quickly can we get value from SWS?

For standard read-oriented use cases, very quickly. SWS installs as a standard PeopleSoft Application Designer project, and many production endpoints can be configured in under 5 minutes once the product is installed. The value is usually immediate because the first few integrations often justify the purchase on their own.

Do I need a PeopleSoft developer to use SWS?

For most SWS GET use cases, no. SWS is designed so a PeopleSoft power user who understands the data model and can write SQL can configure services without writing PeopleCode. Deep PeopleSoft development skills are still useful for exceptional cases, but SWS reduces how often you need them for routine data exposure.

What does SWS replace, and what does it not replace?

SWS replaces much of the repetitive work involved in creating custom read-oriented PeopleSoft web services. It does not replace PeopleSoft itself, an iPaaS platform, an LLM platform, or every possible custom integration pattern. Think of it as a reusable data-exposure layer for PeopleSoft.

Is SWS faster than the PeopleSoft Query Tool?

For exposing data over REST, yes. Query Tool requires query manager security, query tree access, and a UI workflow. SWS gives you better field naming, richer output encodings (JSON/XML/CSV), nested data, and skips the data security / query tree machinery that often gets in the way. See the PeopleSoft Query Tool & Query Access Web Services section of the alternatives page for the detailed comparison.

Security and operations

How does authentication work?

SWS uses HTTP Basic Authentication tied to PeopleSoft PSOPRDEFN OPRIDs and passwords, layered with PeopleSoft service operation security and per-endpoint permission lists. The full mechanics, including a recommended best-practice account model, are documented in SWS Security Setup.

How do I flow a user’s identity from a frontend or chatbot through to PeopleSoft?

The supported pattern is a trusted server that authenticates the end user through your SSO and then calls SWS as a service account, passing the end-user identity as a request parameter. The configured SQL or PsoftQL binds that parameter (for example :oprid) to filter the data, so the same endpoint can scope its response to whichever user the trusted server is acting on behalf of. For cases where the trusted-server pattern is not enough — typically when delivered PeopleSoft APIs require the session to run under the actual end user — SWS supports a second pattern based on minting a PS_TOKEN for the target user. Both patterns, with a decision matrix, are documented in Identity Flow & User Context.

Does SWS support OAuth 2.0 on REST?

No. PeopleSoft Integration Broker does not support OAuth 2.0 cleanly on REST services, and SWS does not work around that constraint. The supported pattern for end-user identity is the trusted-server model described in Identity Flow & User Context. For multi-database installations or token-based scenarios that require execution under a specific user’s PeopleSoft session, PS token minting from a trusted server is the documented path.

Does SWS modify delivered PeopleSoft objects?

No. SWS is delivered as a standalone Application Designer project with its own custom objects. Zero delivered PeopleSoft objects are modified, which means SWS will not conflict with PeopleSoft updates or patches.

What happens if Cedar Hills Group is unavailable, or if we stop renewing support?

SWS is a perpetual, per-environment license, and the installed code is standard PeopleSoft Integration Broker technology — no external runtime, no phone-home, no SaaS dependency. Once SWS is installed in your environment, it keeps running whether or not Cedar Hills Group is reachable. If you choose to stop renewing annual support, SWS continues running on the version you installed; you simply forgo future patches and upgrades. See Purchase SWS for the full license terms.

Capabilities and fit

What output formats does SWS support?

JSON, XML, and CSV — automatic, no extra configuration. The client picks the format on the request. The same SWS configuration can return any of the three.

Can I use my own custom tables with SWS?

Yes. Custom records work exactly the same as delivered records. Add the record to the SWS whitelist for the API user’s permission list and the engine will read it the same as any delivered table. Custom views and views over database links work the same way — if PeopleSoft can resolve the metadata, SWS can serve it.

Can I join tables that do not share the same key field name?

Yes. The default SWS behavior is to auto-join on shared key fields (the common case: PSOPRDEFN.EMPLID to PERSON.EMPLID). For records where the field names do not match — for example, joining a custom view that exposes ID to a PeopleSoft record that uses EMPLID — PsoftQL supports explicit parentField and childField mappings with doNotAutoJoinToParent. See the PsoftQL syntax reference and the worked example in Campus PsoftQL Examples.

How does SWS know which prompt table to use for descriptions? What if it picks the wrong one?

SWS reads PeopleTools metadata — the same record/field definitions that drive PIA prompts — and resolves descriptions automatically. For delivered records and most custom records this just works.

If you are pointing SWS at a staging table or a custom record where the PeopleTools metadata does not point at the correct description source, the description will not resolve. An explicit prompt table override syntax is on the SWS roadmap so you can override the lookup per field without changing the PeopleTools metadata.

Performance

Can SWS handle millions of rows?

Yes. SWS is running SQL against your database — the same SQL you would write yourself — so the performance characteristics are the database’s. Customers point SWS at ledger tables, journal lines, and PeopleSoft Process Scheduler history without issue.

Two things matter for large-table endpoints:

1. Use a selective WHERE clause in the configured SQL or PsoftQL. SWS does not auto-restrict.
2. Use pagination for the response. SWS provides offset-based pagination via pageNumber and rowLimit query string parameters. The handler still runs the full underlying query and skips rows for earlier pages, so pagination is not a substitute for a good WHERE clause — it controls response size, not query cost. See Pagination for SQL endpoints for the full parameter list.

Are there hard row-count limits in SWS?

No. There is no fixed row cap baked into the engine. You set a per-endpoint Row Limit in the configuration (and clients can override at request time within that ceiling). Beyond that, the limit is whatever your SQL and the database can return.

AI, analytics, and modernization

Can I use SWS to feed an AI agent, RAG pipeline, or chatbot?

Yes — this is one of the highest-leverage SWS use cases. Agent teams typically need to iterate quickly on which PeopleSoft data the model can see, and SWS lets you stand up REST endpoints in minutes via configuration instead of running each request through a development cycle. See AI Agent Integration for the reference architecture and the specific patterns that make SWS responses LLM-friendly.

How do I hide PeopleSoft fields I do not want an LLM to see?

PsoftQL lets you list the fields to include or explicitly exclude on a per-record basis. PeopleSoft tables often carry dozens of administrative fields that are not relevant to a user-facing answer; excluding them keeps the response narrow and prevents the model from fixating on a field that looks important but is not. See the field include/exclude options in PsoftQL syntax.

Can SWS support modern portals, mobile apps, and analytics workloads too?

Yes. AI is a timely use case, but it is not the only one. SWS is equally useful for vendor integrations, React or Vue applications, mobile-friendly self-service experiences, reporting feeds, data warehouses, and internal dashboards. The core value is the same: clean, governed access to PeopleSoft data through APIs.

Pricing, trial, and purchase fit

How do I get a trial?

Cedar Hills Group maintains demo PeopleSoft environments that we can grant prospects access to so you can exercise SWS end-to-end without installing anything in your own environment first. This avoids the “we have not bought it yet, but you have already shipped us the code” problem. To request trial access, contact Chris Malek and mention which PeopleSoft pillar (Financials, HCM, Campus) is most relevant — we can match the demo environment to your use case.

Is pricing negotiable?

The published tiers on the Purchase page are the standard offering. For system integrators, multi-environment institutions, or unusual web-service volumes, contact Chris Malek to discuss.

Which tier is right for my institution?

If you have a small number of targeted integrations, start with Junior. If you have an active integration program with multiple vendors, Pro is a strong fit. If you are pursuing digital transformation with broad data access needs, Enterprise gives you unlimited capacity. System Integrator is designed for consulting firms managing multiple client environments.