Oracle PeopleSoft and Asana integration

What moves between them

The primary flow runs from Oracle PeopleSoft into Asana. ml-connector reads AP invoices and requisitions that need a review or approval through the PeopleSoft inquiry endpoints and creates or updates an Asana task for each, writing the invoice or requisition ID, business unit, vendor or requester, amount, due date, and status into Asana custom fields. When an Asana approval task is completed, the completion flows back so ml-connector records the decision against the matching PeopleSoft voucher or requisition through a Component Interface. Employee directory records can also sync into the Asana user-facing roster reference. Because PeopleSoft is effectively pull-only, the cadence is a scheduled poll on the PeopleSoft side, with Asana webhooks driving the return path as task changes occur.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the PeopleSoft side it accepts the customer's full base URL, port, and Integration Broker node name, since the platform is self-hosted and has no shared address, and it sends Basic Auth with the OPRID and password, or an OAuth2 bearer token where an identity provider is configured. The auth bridge matters because the two sides are unrelated: a per-customer PeopleSoft server behind a firewall on one side, an Asana workspace GID on the other, so the customer typically whitelists the connector egress range. Field mapping is the core of this pair. Because Asana has no finance objects, each PeopleSoft field maps to an Asana custom field resolved by GID, set up once per customer, and every Asana read passes opt_fields so the custom field values come back rather than sparse objects. PeopleSoft has no webhooks, so its inquiry endpoints are polled on a schedule with date-range filters to avoid saturating the Tuxedo queue, and writes back use the AP_VOUCHER or PO Component Interface, which rejects a duplicate by its natural key such as the voucher or requisition ID. On the Asana side ml-connector registers a webhook, echoes the X-Hook-Secret during the handshake, verifies the HMAC-SHA256 signature on every event, and re-checks and re-registers the webhook on a schedule because Asana deletes it after 24 hours of failed delivery. Neither API offers an idempotency key, so ml-connector tracks the stored Asana task GID and the PeopleSoft record key before creating, so a retry does not duplicate. Asana rate limits per token return 429 with Retry-After and PeopleSoft has no published limit, so both are throttled with backoff and exponential retry, and every record carries a full audit trail and can be replayed.

A real-world example

A regional health system with about 4,000 employees runs Oracle PeopleSoft Financials for accounts payable and eProcurement on its own servers, while department managers and clinical leads coordinate their work in Asana. Before the integration, accounts payable emailed lists of vouchers and requisitions waiting on a manager's sign-off, the managers approved them late or lost them in their inbox, and month-end close stalled while finance chased approvals one at a time. With Oracle PeopleSoft and Asana connected, each invoice or requisition that needs review becomes an Asana task assigned to the right manager with the business unit, vendor, amount, and due date in custom fields. The manager completes the task, the decision is recorded back in PeopleSoft automatically, and finance sees an approved queue instead of an email thread.

What you can do

• •Create and update Asana tasks from Oracle PeopleSoft AP invoices and requisitions that need review or approval.
• •Carry the PeopleSoft invoice or requisition ID, business unit, vendor, amount, and status in mapped Asana custom fields.
• •Record Asana task completion back to PeopleSoft against the matching voucher or requisition through a Component Interface.
• •Bridge PeopleSoft Basic Auth on the customer base URL and node with the Asana bearer token.
• •Poll PeopleSoft on a schedule with date-range filters, verify Asana HMAC-SHA256 webhooks, and re-register dropped webhooks.

Questions

Can Asana hold the invoices and GL accounts from Oracle PeopleSoft?

Not as native objects. Asana has no invoice, purchase order, or GL account entities, so ml-connector carries that financial detail in Asana custom fields that map to the PeopleSoft fields. The fields are set up once per customer and resolved by their Asana GID, since field names can be renamed.

Which direction does data move between Oracle PeopleSoft and Asana?

The primary flow is PeopleSoft into Asana, creating tasks for AP invoices and requisitions that need a review. Asana task completion then flows back so ml-connector records the decision against the matching PeopleSoft voucher or requisition through a Component Interface. Employee directory records can also sync into the Asana roster reference.

How are events handled when PeopleSoft has no webhooks?

PeopleSoft has no conventional webhooks, and its outbound Integration Broker messages are XML and unsigned, so ml-connector treats it as pull-only and polls the read-only inquiry endpoints on a schedule with date-range filters. The Asana side does push events, signed with HMAC-SHA256 and verified on every delivery, and because Asana deletes a webhook after 24 hours of failed delivery, ml-connector re-checks and re-registers it on a schedule.