A version of this question lands in my inbox a few times a year, almost always from an integration architect scoping a new project:
We want to stream student identity and enrollment changes out of PeopleSoft into our data lake. We need a one-time history pull and then incremental updates going forward. Does PeopleSoft have anything like Ellucian Ethos pub/sub, or Okta event hooks, where we can subscribe to a feed of changes? We want a minimal footprint in PeopleSoft—ideally no database triggers, and no Component Interfaces.
The short answer is no. PeopleSoft does not have a native event framework in the modern SaaS sense. There is no event bus to subscribe to, no auto-generated per-object change topics, and no “give me everything that changed on table X since timestamp Y” streaming API.
The more useful answer is that PeopleSoft gives you several building blocks, but you have to build the plumbing yourself. The hard part is deciding where the change signal comes from, how reliable it needs to be, and how much custom work you are willing to maintain.
Before looking at PeopleSoft’s workarounds, it’s worth laying out the mental model that modern integration teams bring to the table. They are used to SaaS platforms that offer out-of-the-box event hooks:
user.lifecycle.create, user.lifecycle.deactivate). Delivery is asynchronous and non-blocking.Account object, and Salesforce automatically streams AccountChangeEvent payloads containing creates, updates, and deletes.The common ingredients in all of these are:
flowchart LR
subgraph modern_saas ["Modern SaaS (Okta / Ethos / Salesforce CDC)"]
S1["Data Change"] --> S2["Native Event Bus"]
S2 --> S3["Subscriber A"]
S2 --> S4["Subscriber B"]
end
PeopleSoft has none of this natively. Integration Broker (IB) is a transport layer—it provides queues, routings, and target connectors—but it is not an event source. It can deliver events you have already generated, but it does not generate those events for you.
This isn’t a defect; it’s a consequence of the system’s architecture and history:
WORKFORCE_SYNC or PERSON_BASIC_SYNC) only fire when data is modified through a Component or Component Interface. If an Application Engine job, an SQR, a bulk loader, or a DBA script updates tables directly via SQL, the delivered events are completely bypassed.PS_PERSONAL_DATA table.” If you want to track changes, you have to write code or build database triggers.Here are the hooks available in PeopleSoft, along with their coverage gaps:
| Mechanism | What it does | Why it is not an “event stream” |
|---|---|---|
| SavePostChange PeopleCode | Fires when a component is saved. | Only catches writes going through the online PIA component or a CI. Bypassed by SQR, App Engine SQL, and bulk loaders. |
| Component Interface Events | Runs custom OnExecute or save code. | Same gap: only covers the CI write path. |
Delivered Sync Messages (WORKFORCE_SYNC, etc.) |
Pre-built publishers wired into delivered components. | Bypassed by direct SQL/batch writes. Payloads are massive and cannot be filtered easily. |
| App Engine Schedulers | Polls tables on a schedule. | This is polling, not event-driven. |
| Integration Broker Queues | Handles async messaging. | A transport mechanism for events, not an event generator. |
| Database Triggers | Row-level triggers on database tables. | High fidelity (catches everything), but lives outside PeopleTools. You own the DDL maintenance. |
When a partner asks for a change feed, we usually choose from these six patterns, ordered from the simplest footprint to the most robust:
| Approach | Footprint | Change Fidelity | Latency | Effort | Best For |
|---|---|---|---|---|---|
| 1. Plain Query REST Polling | Zero new objects | None (reads full tables) | Poll interval | Low | Low-volume reference tables; one-time history pulls. |
| 2. Audit-Column Query REST | Query + permission | Catches anything updating LASTUPDDTTM |
1–5 minutes | Medium | Default answer for most data syncs. |
| 3. Delivered Async Messages | Routings + handlers | Online component/CI writes only | Seconds | Medium | Bios/Jobs on systems that strictly use components. |
| 4. SavePostChange Publisher | Service + PeopleCode | Only the components you write code in | Seconds | Medium | Custom apps where you control 100% of write paths. |
| 5. Triggers + Daemon | Triggers + table + AE | 100% of all writes (including direct SQL) | Seconds | High | High-value, audit-critical syncs (e.g., identity). |
| 6. Full-Table Snapshot | None (or standard query) | None (diff happens downstream) | Hours / Days | Low | Slowly changing dimensions (e.g., term codes). |
When evaluating this matrix, keep two things in mind:
LASTUPDDTTM column every minute is operationally indistinguishable from event streaming for typical ERP volumes, and it carries much lower risk.This is the decision flow I walk through when designing these integrations:
How does data get into the target tables? If users only update records via online pages, Component-level hooks (SavePostChange, delivered sync messages) are safe. If batch App Engines, SQRs, or bulk loaders write directly to the database, you must use audit-column polling or database triggers to avoid missing updates.
If the security or DBA team bans database triggers, you are limited to audit-column polling. If you cannot create any new database objects at all, you must fall back to plain Query REST polling and let the consumer handle the diffing.
“Real-time” is rarely a hard requirement. Most data lakes, search indexes, and reporting platforms are perfectly happy with a 5-minute delay.
flowchart LR
Consumer["External Consumer\n(every N minutes)"] -->|Query REST| QAS["QAS Query Endpoint"]
QAS -->|Runs SQL| SQL["SELECT KEYS FROM AUDIT_TBL\nWHERE LASTUPDDTTM > LAST_RUN"]
SQL -->|Returns| Diff["Changed Key List"]
Diff -->|GET Detail| Detail["Fetch Full Records"]
For the majority of our integrations—including student records and HR bio/demo syncs—we land on Option 2: Audit-Column + Query REST Polling. It satisfies the “no triggers, no CIs” constraint, runs on standard delivered Query API endpoints, and captures every change that updates the standard LASTUPDDTTM fields.
Chris Malek is a PeopleTools® Technical Consultant with over two decades of experience. He is available for consulting engagements.
Work with ChrisSWS turns SQL into production REST APIs — ready for AI, modern apps, and partner integrations. One install, unlimited potential.
A powerful PeopleSoft bolt-on that makes REST web services easy. You bring the SQL, SWS handles the rest.
Traditional PeopleSoft web services cost $3,600–$13,000 each to develop. SWS deploys production REST APIs in under 5 minutes through configuration alone.
Turn PeopleSoft data into clean REST APIs for AI integrations, modern applications, and vendor data feeds. Configuration-driven — no PeopleCode required.
Look up any record, field, page, or component, audit security, and monitor Integration Broker across every database — in seconds.
A web console built for the PeopleSoft community — operational monitoring, security auditing, and metadata browsing in one tool.
On-demand security and operational reports for your PeopleSoft environment — no client install required.
Research any PeopleSoft object and monitor system health from a single browser tab — no App Designer, no SQL.