Microsoft Dynamics 365 Business Central and Jira integration

What moves between them

The main flow runs from Microsoft Dynamics 365 Business Central into Jira. ml-connector reads new and changed purchase invoices and vendor records and creates or updates a matching Jira issue, putting the Business Central document number, vendor name, amount, and status into the issue summary and mapped custom fields. Resolution flows the other way: when the Jira issue is transitioned to a done status, ml-connector flags the source document in Business Central, for example posting an approved draft purchase invoice with the bound post action or unblocking a vendor. Invoice issues can be driven by Business Central push subscriptions, while purchase orders, which have no webhook, are polled on a schedule you set, and Jira issue transitions are received through a Jira webhook filtered by JQL.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Business Central side it requests an OAuth2 client-credentials token from Microsoft Entra ID with the Business Central scope, and builds the base URL from the tenant and environment name held as a credential field, since the environment, often production, is part of the path. On the Jira side it completes the three-legged OAuth flow, stores the rotating refresh token, and calls the accessible-resources endpoint to resolve the cloudId used in every request URL. Purchase invoices can be driven by Business Central subscriptions, which only signal a change, so the connector fetches the document and then upserts the Jira issue; purchase orders have no webhook and are polled with an OData lastModifiedDateTime filter. Business Central subscriptions expire every three days and Jira REST webhooks expire after thirty days, so cron jobs renew both before expiry. Custom field IDs are discovered from the Jira field list and mapped at connect time rather than hardcoded, because they differ per site, and users are matched by Jira accountId, never by name. The issue description is written in Atlassian Document Format, not plain text or Markdown. Inbound Jira webhooks are verified with HMAC-SHA256 against the X-Hub-Signature header before being trusted. Neither API has an idempotency-key header, so the connector stamps the Business Central document number into a Jira custom field and searches for it with JQL before creating, and uses a stable BullMQ jobId, to avoid duplicate issues. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized electronics distributor with around three hundred staff runs Microsoft Dynamics 365 Business Central for purchasing and finance, and its operations and IT teams run everything they work on in Jira. Before the integration, purchase invoices that failed a match or vendors flagged as blocked sat in Business Central waiting on someone to notice, and the AP clerk emailed around for answers and re-typed the outcome back into the ERP. With Business Central and Jira connected, each exception becomes a Jira issue assigned to the right owner, with the vendor, amount, and document number in issue fields, and moving the issue to done posts or unblocks the document in Business Central. Exceptions get worked in the tool the team already uses, invoices stop aging, and finance no longer re-keys the result.

What you can do

• •Turn Business Central purchase invoices and blocked vendor records into Jira issues with vendor, amount, and document number in issue fields.
• •Post or unblock a Business Central document when its Jira issue is transitioned to a done status, including posting a draft purchase invoice with its bound action.
• •Authenticate Business Central with OAuth2 client credentials and Jira with three-legged OAuth, resolving the cloudId and custom field IDs per site.
• •Use Business Central subscriptions for invoices and OData polling for purchase orders, and receive Jira transitions through a JQL-filtered webhook.
• •Match Jira users by accountId, write descriptions in Atlassian Document Format, and dedupe with jobId, retries, and a full audit trail.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Jira?

The main flow is Business Central into Jira: purchase invoices and blocked vendor records become Jira issues with their details in issue fields. Resolution flows back the other way, so transitioning the issue to a done status can post or unblock the source document in Business Central. Jira has no invoice, purchase order, or GL objects, so the accounting stays in Business Central and Jira is used for the tracking and resolution.

How does Jira hold financial data when it has no invoice or GL objects?

Jira has no native invoice, purchase order, vendor, or GL account entities, so ml-connector carries that data in the issue summary, the description, and per-instance custom fields, such as document number, vendor, and amount. Those custom field IDs are discovered from the Jira field list and mapped per site up front, because they differ per instance and must not be hardcoded. The description is written in Atlassian Document Format rather than plain text.

How does the integration authenticate to each system?

Business Central uses OAuth2 client credentials against Microsoft Entra ID with the app registered inside Business Central, which suits an unattended connector. Jira does not offer client credentials, so ml-connector uses the recommended three-legged OAuth flow, stores the refresh token that Atlassian rotates on every use, and resolves the site cloudId from the accessible-resources endpoint before building any request URL. Both credential sets are stored encrypted.