IFS Cloud and Jira integration

What moves between them

The main flow is IFS Cloud into Jira. ml-connector polls IFS for purchase orders and work orders on a daily or hourly schedule, creates matching Jira issues in the mapped project, and sets priority and assignee based on IFS supplier tier or work category. Jira issue status updates are written back into IFS custom fields or workflow state fields. Projects in IFS map to Jira projects via configuration; users and suppliers in IFS map to Jira assignees via email or username lookup. GL accounts and cost centers from IFS can be stored in Jira issue custom fields for audit and cost allocation.

How ml-connector handles it

ml-connector stores IFS OAuth2 credentials and polls the IFS OData API for purchase orders and work orders using filters on creation date or status state, respecting the 5000-element page limit and handling HTTP 429 rate-limit backoff with exponential jitter. On the Jira side, it refreshes OAuth2 tokens as needed and maps custom field IDs per Jira instance, since IFS entity codes (e.g. PurchaseOrderSet, WorkOrderSet) do not directly correspond to Jira issue types. For mutations in IFS, ml-connector reads the record first to capture the ETag header, then POSTs or PATCHes with that etag value to satisfy optimistic concurrency. Status changes in Jira are detected either by polling Jira's issue API or via webhook (if enabled), then POSTed into IFS custom fields. Since IFS Event Actions require manual per-customer configuration and are not API-registerable, webhooks are not used from IFS; only Jira webhooks are optional. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturing company runs IFS Cloud for production, procurement, and project management across three plants. The maintenance and procurement teams use Jira to track work requests, repairs, and capital projects. Before the integration, the procurement team created purchase orders in IFS but then re-keyed them into Jira as work items, and field teams updated Jira issues without that status flowing back into IFS for historical records. With IFS Cloud and Jira connected, each new PO in IFS automatically creates a Jira issue in the Procurement project, tagged with supplier and cost center, and when the team marks it Resolved in Jira, that status flows back into an IFS custom field for audit and month-end reconciliation. The duplicate entry step is gone and both systems reflect the true state.

What you can do

• •Poll IFS Cloud purchase orders and work orders on a schedule, creating matching Jira issues with priority and assignee mapped from IFS supplier tier and work category.
• •Map IFS project codes to Jira projects, and sync supplier and user records so issues land in the right project and are assigned to the correct team members.
• •Write Jira issue status updates back into IFS custom fields or workflow state, keeping procurement and project records in both systems synchronized.
• •Handle IFS OAuth2 token refresh, ETag-based optimistic concurrency for mutations, and the 5000-element OData page limit without skipping records.
• •Track every record with a full audit trail, detect and deduplicate on IFS purchase order number or work order ID, and retry failed syncs.

Questions

Which direction does data move between IFS Cloud and Jira?

The main flow is IFS Cloud into Jira. Purchase orders and work orders from IFS create Jira issues. Jira issue status updates flow back into IFS custom fields for tracking and audit. IFS GL accounts and cost center codes are stored in Jira issue custom fields for cost allocation and reconciliation.

How does the integration handle IFS's lack of webhooks?

ml-connector polls the IFS OData API on a schedule (hourly or daily) for purchase orders and work orders, using creation date or status filters. For Jira, webhooks are optional; status updates can be detected by polling Jira's issue API or via webhook if you enable Jira webhooks. IFS Event Actions require manual per-customer configuration and are not used by the integration.

Does the integration handle IFS ETag concurrency and page limits?

Yes. ml-connector reads each IFS record first to capture its ETag header, then mutates with that etag value to satisfy optimistic concurrency. It respects the 5000-element page limit on OData requests, paginates large result sets, and retries on HTTP 429 rate-limit responses with exponential backoff and jitter.