IFS Cloud and Slack integration

What moves between them

The primary flow routes IFS events into Slack. When supplier invoices, purchase orders, payment proposals, or GL vouchers are created or changed in IFS Cloud, ml-connector polls for those records on a configurable interval (every 5-15 minutes for standard operations), formats them with business context (vendor name, order total, GL account, approval status), and posts formatted messages into designated Slack channels. Team members can react to or thread on these notifications for coordination. Optional reverse flow: Slack users can trigger IFS workflows via slash commands (e.g., /approve-invoice <ID>) which ml-connector routes back to IFS as authenticated API calls.

How ml-connector handles it

ml-connector continuously reads IFS Cloud using OData filters on ModifiedDateTime to find new and updated records, respecting the 5000-element page limit and exponential backoff on HTTP 429 rate-limit responses. On each poll cycle, changed records are formatted with human-readable details (vendor name, amount, GL account name, approval workflow state) and posted to Slack using the conversations.post method. Each Slack post includes the record ID as metadata, allowing threaded replies to be traced back to the source transaction. ml-connector validates every inbound Slack webhook signature using HMAC-SHA256 constant-time comparison against the X-Slack-Signature header to prevent spoofed events. OAuth2 tokens are refreshed automatically before expiry on both sides. For mutations back to IFS (e.g., marking an invoice as approved), ml-connector first reads the current record to capture its ETag, then submits the PATCH or POST action with that ETag value to enforce optimistic concurrency. All events are logged with full audit context: who triggered it, when, what changed, success or error.

A real-world example

A manufacturing operations team uses IFS Cloud for supply chain and finance, and Slack for daily team coordination. Before the integration, procurement staff checked IFS manually each morning for new supplier invoices and matching POs, logged status changes in spreadsheets, and flagged approvals in email chains. With IFS and Slack connected, every new invoice and PO appears in the procurement channel with context (vendor, amount, GL account), and approvers can respond in-thread without logging into IFS. Month-end close becomes more transparent: finance staff see all GL postings from payment runs appear in the finance channel, with full drill-down detail, so discrepancies surface immediately instead of during manual reconciliation.

What you can do

• •Post supplier invoices, purchase orders, and payment proposals from IFS Cloud into Slack channels with full business context and approval status.
• •Deliver GL voucher postings and journal entries from IFS to finance teams in Slack, linked back to the IFS transaction for traceability.
• •Allow Slack users to trigger IFS workflows (approve invoices, acknowledge POs, mark payments) via slash commands, with changes synchronized back into IFS.
• •Validate all Slack webhook signatures using HMAC-SHA256 and enforce OData ETag concurrency on IFS mutations to prevent conflicts.
• •Poll IFS OData API with modified-timestamp filtering, respect rate limits and page sizes, and maintain a complete audit trail of every message posted.

Questions

How does the integration detect new IFS transactions without webhooks?

ml-connector polls the IFS Cloud OData API on a regular schedule (every 5-15 minutes by default) using filters on ModifiedDateTime to fetch only records that have changed since the last poll. This avoids the need for IFS Event Actions configuration. The poll respects IFS page-size limits (5000 elements) and automatically backs off when rate limits are hit.

Can Slack users interact with IFS from within Slack?

Yes. ml-connector supports Slack slash commands and interactive buttons that route back to IFS as authenticated API calls. For example, a procurement manager can type /approve-invoice <ID> in a thread, and ml-connector will submit an approval action to IFS using the correct OAuth2 credentials and ETag concurrency headers. Changes flow back into Slack as confirmation messages.

What happens if an IFS record changes while Slack is posting it?

IFS uses OData ETag headers for optimistic concurrency. ml-connector reads each record to capture its current ETag before posting to Slack, and if a mutation is needed later (e.g., approval via Slack), ml-connector re-reads the record, gets the fresh ETag, and uses that value in the PATCH to ensure no intermediate changes are silently overwritten. If the ETag is stale, IFS returns 412 Precondition Failed, and ml-connector surfaces the conflict rather than forcing an update.