IFS Cloud and Twilio integration

What moves between them

Data flows from IFS Cloud into Twilio. ml-connector polls IFS on a configurable schedule (typically every 15 minutes) for new or updated purchase orders, invoices, goods receipts, and shipment records, filtering by modified timestamp. For each record that crosses a business event threshold (e.g., invoice amount exceeds a limit, PO is approved, goods receipt is confirmed), ml-connector formats a notification message and sends it to a Twilio phone number or email address associated with the owning department or cost center. Response status from Twilio is logged and stored in ml-connector's audit trail for compliance and retry. No data flows back from Twilio to IFS.

How ml-connector handles it

ml-connector stores the Twilio API Key encrypted and presents it via HTTP Basic Auth on every outbound message call. On the IFS side, ml-connector caches the OAuth 2.0 bearer token (valid for approximately 60 minutes) and refreshes it when calls fail with 401. It polls IFS at a cadence you control (15-minute intervals are typical) by querying PurchaseOrderSet, PostingProposalHeadSet, and related entities with $filter parameters on ModifiedDateTime to fetch only recent changes. Event logic lives in your flow configuration: which invoice thresholds trigger alerts, whether to alert on PO approval or only on receipt of goods, and which phone numbers or email addresses receive each notification. Because IFS uses OData ETags for optimistic concurrency, ml-connector captures the ETag when reading a record and includes it if a mutation is needed (e.g., updating a flag to mark the notification as sent). Twilio's HTTP status callbacks provide delivery confirmation (sent, delivered, failed), which ml-connector logs for audit and can trigger retries on failure.

A real-world example

A mid-sized electronics manufacturer uses IFS Cloud for procurement, inventory, and finance across three regional warehouses. The procurement team manually checks IFS multiple times daily for invoices from critical suppliers that need approval, and warehouse staff log into IFS to see which shipments arrived. With Twilio integrated, when a high-value invoice from a strategic supplier posts to IFS, the approver gets an SMS with the invoice amount and vendor name within seconds. When a goods receipt is confirmed, the receiving warehouse gets an email with the PO number and item counts so they can match the physical receipt. Alerts are routed by cost center and supplier criticality, so the supply chain manager sees urgent shipments while routine orders send lightweight summaries to warehouse terminals.

What you can do

• •Send SMS and email alerts from IFS Cloud purchase orders, invoices, and goods receipts through Twilio to operations and procurement staff.
• •Poll IFS OData APIs on a configurable schedule to detect new business events (invoice receipt, PO approval, shipment confirmation) and trigger notifications.
• •Route alerts by cost center, supplier priority, or user role so the right person sees the right message.
• •Track Twilio message delivery status (sent, delivered, failed) in ml-connector's audit trail for compliance and troubleshooting.
• •Handle OAuth 2.0 token refresh on IFS and HTTP Basic Auth on Twilio, with automatic retries and error logging.

Questions

What data moves from IFS Cloud to Twilio?

Purchase orders, supplier invoices, goods receipts, and shipment records flow from IFS to Twilio as formatted SMS and email notifications. No financial data (GL entries, payment records) is sent to Twilio. Data flows one way only: IFS to Twilio for alert delivery.

How does ml-connector know when to send an alert?

You configure business logic in ml-connector flows to define thresholds and triggers. For example, send an SMS when an invoice over USD 50,000 posts to IFS, or send an email when a goods receipt is confirmed. ml-connector polls IFS on your schedule (typically every 15 minutes), applies the logic rules, and sends the notification to Twilio when a condition is met.

How are Twilio API credentials stored and used?

Twilio API Keys are stored encrypted in ml-connector and presented via HTTP Basic Auth on every message call. OData tokens from IFS are cached and refreshed when they expire. All calls are logged with audit trails; Twilio delivery status callbacks (sent, delivered, failed) are tracked so you can see which alerts landed and which failed.