IFS Cloud and Asana integration

What moves between them

The main flow is IFS Cloud into Asana on a daily or weekly schedule aligned with your procurement cycle. Purchase orders and supplier invoices from IFS Cloud are fetched via OData polling and created or updated as Asana tasks within designated projects. GL accounts, cost centers, and supplier names are mapped to Asana custom fields. When an Asana task is marked complete or approved by a procurement user, webhooks flow the status change back into IFS Cloud journal entries or payment proposal records if those records were already created by prior flows. GL posting is read-only in Asana, so ml-connector does not write financial GL entries into Asana; it only reads and maps them.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the IFS OAuth client ID and secret are refreshed before each polling cycle (OAuth tokens expire in 60 minutes), and Asana personal access tokens are stored as Bearer headers. When polling IFS Cloud, ml-connector reads the OData entity set (e.g., PurchaseOrderSet), filters by modified timestamp and company code to find new or changed records, respects the 5000-element page limit, and captures the ETag header to support future mutation operations if approval status updates are needed. For each purchase order or invoice, it creates or updates a matching Asana task in the configured project, mapping IFS Cloud GL account and cost center codes to Asana custom fields by name. Asana webhooks are registered for the target project, and when a task status changes (e.g., marked complete), ml-connector receives the webhook, validates the authenticity via Bearer token verification, and POSTs the approval status back to IFS Cloud's journal entry or payment proposal endpoint with the original ETag to avoid concurrency conflicts. Retries use exponential backoff with jitter when IFS returns 429 rate-limit responses. Every record carries an audit trail including the webhook payload, the IFS OData query timestamp, and any mutation failures.

A real-world example

A mid-market manufacturing company runs IFS Cloud for procurement and asset management, and uses Asana for cross-functional project planning and procurement oversight. Before the integration, the procurement team exported purchase orders and incoming invoices from IFS Cloud daily, manually created Asana tasks to track approval status, and re-entered approval decisions back into IFS Cloud, creating delays and transcription errors. With IFS Cloud and Asana connected, each new purchase order automatically appears as an Asana task in the procurement project, vendors and GL codes are included in custom fields for context, and when the Asana task is marked approved, the approval flows back into the IFS Cloud payment proposal workflow. Month-end invoice reconciliation is faster, approval bottlenecks are visible in Asana, and the manual re-entry step is eliminated.

What you can do

• •Poll IFS Cloud purchase orders and supplier invoices on a daily or weekly schedule and create or update Asana tasks in a designated project.
• •Map IFS Cloud GL accounts and cost center dimensions to Asana custom fields so procurement context is visible in work tasks.
• •Authenticate IFS Cloud with OAuth 2.0 client credentials and handle 60-minute token refresh automatically on every poll cycle.
• •Receive Asana webhook notifications when task status changes and POST approval decisions back to IFS Cloud journal entries with ETag-based concurrency safety.
• •Respect IFS Cloud rate limits (1000 requests per minute) and page size limits (5000 elements), with exponential backoff retries and full audit trail on every record.

Questions

Which direction does data move between IFS Cloud and Asana?

The primary flow is IFS Cloud into Asana: purchase orders and supplier invoices are pulled via OData polling and created as Asana tasks with GL and cost center metadata in custom fields. Task status updates and approvals are pushed back from Asana webhooks into IFS Cloud journal entries or payment proposals. GL posting remains read-only in Asana.

How does ml-connector handle IFS Cloud's lack of push webhooks?

IFS Cloud has no standard push-based webhook API (Event Actions require manual per-customer configuration and are not self-registerable via API). ml-connector uses pull-based polling of the OData API with filters on modified timestamps and company code, scheduled daily or weekly to align with your procurement cycle. Asana webhooks handle the reverse flow (approval status back to IFS Cloud).

What are the key constraints on IFS Cloud and Asana data synchronization?

IFS Cloud enforces a 5000-element page limit per OData request, rate-limits at 1000 requests per minute (return 429 on exceeded), and requires ETag headers on PATCH operations for optimistic concurrency. Asana has no native financial objects, so GL accounts and cost centers must be represented via custom fields. Asana webhooks auto-delete after 24 hours of failed delivery, so the receiving endpoint must respond with 2xx within that window.