Oracle PeopleSoft and Twilio integration

What moves between them

Employee phone numbers and contact preferences flow from PeopleSoft to Twilio on a polling schedule. When a PeopleSoft event occurs such as payroll posting or a shift change, ml-connector reads the affected employees and their contact information from PeopleSoft REST endpoints, then sends an SMS or voice notification via Twilio. Twilio sends back status callbacks as messages are queued, delivered, or fail, and ml-connector logs each notification attempt and final delivery status. The data flows one direction: PeopleSoft is the source of employees and triggering events, and Twilio is the messenger. No financial data or business transactions flow to Twilio.

How ml-connector handles it

ml-connector accepts the PeopleSoft hostname, port, node name, and credentials (OPRID and password, or OAuth2 client ID and secret for PeopleTools 8.58+) per customer, then queries REST endpoints for employee phone numbers and business events on a polling schedule. For each event or batch, it reads the relevant employee records from PeopleSoft using date-range filters to avoid duplicate reads, then constructs Twilio SMS or voice messages and sends them with an idempotency key to prevent duplicate sends if a retry occurs. Twilio webhooks return status callbacks to a registered endpoint as messages are sent, delivered, or fail, and ml-connector persists those callbacks so every notification has a full delivery record. Because PeopleSoft is self-hosted, ml-connector requires the unique hostname and may need a reverse proxy or IP whitelist on the customer's firewall. OAuth2 bearer tokens for PeopleTools 8.58+ require fewer credentials in long-running code compared to Basic Auth with embedded passwords. Every message and callback is logged with an audit trail so compliance teams can verify that notifications were sent and delivered on time.

A real-world example

A mid-sized healthcare company runs Oracle PeopleSoft for HR, payroll, and scheduling. They employ 800 nurses, technicians, and administrative staff across three hospitals, and shift changes and payroll cycles happen frequently. Before connecting PeopleSoft to Twilio, shift notifications were sent via email and were often missed by front-line staff, and payroll alerts went unread. The finance team received calls from employees asking whether payroll had posted. With Twilio integrated, PeopleSoft sends an SMS to each employee's registered phone number when a shift change is added or when payroll posts, and the integration logs which messages were delivered. Employees see shift updates immediately via text, payroll questions drop, and the HR team has a verified record of notifications for compliance audits.

What you can do

• •Send SMS notifications to employees when payroll posts or shift schedules change, read directly from PeopleSoft employee records.
• •Deliver voice alerts for urgent onboarding deadlines or benefits enrollment windows, with full delivery status tracking.
• •Integrate two-factor authentication via Twilio Verify for secure access to employee self-service portals tied to PeopleSoft identity data.
• •Maintain an audit trail of every notification sent, including phone number, message content, and delivery status, for compliance and support.
• •Handle PeopleSoft's self-hosted architecture and varied authentication methods across PeopleTools versions without exposing credentials.

Questions

What employee data flows from PeopleSoft to Twilio?

Phone numbers, names, employee IDs, department names, and job titles flow from PeopleSoft REST endpoints to Twilio so notifications reach the right person. No financial data, compensation, or sensitive HR records are sent to Twilio. The integration is triggered by business events in PeopleSoft such as payroll posting or shift changes.

Does ml-connector support both PeopleSoft's REST and SOAP APIs?

ml-connector reads employee and event data via REST endpoints for simplicity and consistency across PeopleTools versions. Write operations and integration logic that require SOAP Component Interface calls are handled within PeopleSoft itself, not via Twilio. If a use case requires SOAP connectivity, ml-connector can be extended.

How does the integration handle PeopleSoft's self-hosted infrastructure and lack of webhooks?

Each PeopleSoft customer provides their unique hostname, port, node name, and credentials, and ml-connector polls REST endpoints on a configurable schedule. Because PeopleSoft has no webhooks for cloud connectors, polling is the standard approach. The customer's firewall may require a reverse proxy or IP whitelist to allow ml-connector to reach the PeopleSoft instance.