Sage 100 and Jira integration

What moves between them

Purchase orders and vendor records flow from Sage 100 into Jira on a poll schedule (recommended every 15 to 30 minutes for POs). ml-connector creates a Jira issue for each purchase order, mapping the vendor name, PO number, line items, and expected delivery date into the issue fields. Status changes and comments on the Jira issue are logged and can be audited back to the source PO in Sage 100. Vendor master data is synced daily to keep vendor names and contact info aligned. Data flows one direction only; Jira issues are read-only mirrors of Sage 100 records and do not flow back into procurement.

How ml-connector handles it

ml-connector stores Sage 100 credentials (Windows service account and agent API key) encrypted and polls the BOI COM layer through the customer's local Windows agent, passing the required company code on every call. For Jira, it authenticates via OAuth2 (storing the refresh token encrypted) and creates issues in a designated project, mapping PO header fields to Jira issue type, summary, and custom fields. Because Sage 100 has no webhooks, ml-connector polls on a fixed schedule and maintains idempotency by checking for existing issues before creating duplicates. Jira webhooks expire every 30 days, so ml-connector tracks expiry and refreshes the webhook registration before it lapses, avoiding outages from stale webhook endpoints. Retries handle transient network failures between the polling schedule and either system, and every record carries an audit entry linking back to the source Sage 100 transaction.

A real-world example

A mid-sized distributor uses Sage 100 to manage purchase orders and inventory across three warehouses, and uses Jira to track the delivery projects and warehouse receiving workflows for their team. Before the integration, the warehouse managers manually re-entered PO numbers and vendor names into Jira issues, creating a duplicate record-keeping burden and a risk of data drift. With Sage 100 and Jira connected, each new purchase order appears in Jira automatically, assigned to the relevant warehouse project, so the team can track expected deliveries and mark them received without leaving Jira. Finance gets a complete audit trail of which POs are on order, in Jira, without asking the warehouse managers to export reports.

What you can do

• •Create Jira issues automatically for each purchase order in Sage 100, mapped to the correct project and workflow.
• •Sync vendor master records from Sage 100 into Jira so team members see current vendor names, terms, and contact information.
• •Maintain idempotent polling by checking for existing Jira issues before creating duplicates, avoiding spam and stale data.
• •Refresh Jira webhooks every 30 days before they expire, keeping the audit trail live and preventing outage from webhook registration lapses.
• •Encrypt Sage 100 Windows agent credentials and Jira OAuth2 tokens, and track Sage 100 company codes per customer to ensure multi-tenant isolation.

Questions

Does data flow in both directions between Sage 100 and Jira?

No, data flows one direction only, from Sage 100 into Jira. Purchase orders and vendor records are polled from Sage 100 and created as issues in Jira. Status changes and comments on Jira issues are logged in the audit trail but do not update the purchase orders back in Sage 100, since Jira has no native financial entities.

How does ml-connector handle Sage 100's requirement for a local Windows agent?

ml-connector stores the Windows service account credentials and agent API key encrypted and makes authenticated calls to the BOI COM layer through the customer's local agent. The agent must be running on the customer's Sage 100 server; ml-connector cannot bypass the agent requirement or operate without it.

Why do Jira webhooks require special handling in this integration?

Jira webhooks expire after 30 days from creation or last refresh. ml-connector tracks the expiry date and refreshes the webhook registration before it lapses, ensuring that audit notifications continue to flow without interruption. Without this refresh logic, the webhook would silently stop working and outages would go unnoticed until records stopped syncing.