Microsoft Dynamics 365 Business Central and Asana integration

What moves between them

The main flow runs from Microsoft Dynamics 365 Business Central into Asana. ml-connector reads new and changed purchase invoices and purchase orders and creates or updates a matching Asana task, putting the Business Central document number, vendor name, amount, and due date into Asana custom fields. Completion flows the other way: when the Asana task is marked complete, ml-connector flags the source document in Business Central, for example posting a draft purchase invoice with the bound post action once it is approved. Employee records flow from Business Central toward the Asana user roster so tasks are assigned to the right person. Invoice creation can be driven by Business Central push subscriptions, while purchase orders, which have no webhook, are polled on a schedule you set.

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 Asana side it sends the Personal Access Token or a refreshed OAuth2 bearer token and scopes calls to the configured workspace GID. Purchase invoices can be driven by Business Central subscriptions, which only signal a change, so the connector fetches the document and then upserts the Asana task; purchase orders have no webhook and are polled with an OData lastModifiedDateTime filter. Business Central subscriptions expire every three days, so a cron job renews them before expiry, and the connector verifies its Asana webhook still exists because Asana silently deletes it after twenty-four hours of failed delivery. Custom fields are resolved by GID, not name, because Asana fields can be renamed, and Asana list calls pass opt_fields so the custom fields are actually returned. Neither API has an idempotency-key header, so the connector dedupes on the Business Central document number and a stable BullMQ jobId to avoid duplicate tasks. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized construction subcontractor with around two hundred staff runs Microsoft Dynamics 365 Business Central for purchasing and finance, and the project teams live in Asana all day. Before the integration, supplier invoices piled up in Business Central waiting on a project manager to confirm the work was done, and the finance clerk chased approvals over email and re-typed the answers back into the ERP. With Business Central and Asana connected, each new purchase invoice becomes an Asana task assigned to the right manager, with the vendor, amount, and due date in custom fields, and completing the task posts the invoice in Business Central. Approvals happen in the tool the team already uses, invoices stop aging, and finance no longer re-keys the outcome.

What you can do

• •Turn Business Central purchase invoices and purchase orders into Asana tasks with vendor, amount, and due date in custom fields.
• •Post a completed Asana approval back to Business Central, including posting a draft purchase invoice with its bound action.
• •Keep the Asana user roster aligned with Business Central employees so tasks reach the right assignee.
• •Authenticate Business Central with OAuth2 client credentials and Asana with a bearer token, resolving custom fields by GID.
• •Use Business Central subscriptions for invoices and polling for purchase orders, with jobId dedup, retries, and a full audit trail.

Questions

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

The main flow is Business Central into Asana: purchase invoices and purchase orders become Asana tasks with their details in custom fields. Completion flows back the other way, so finishing the task can flag or post the source document in Business Central. Asana has no invoice, purchase order, or GL objects, so the accounting stays in Business Central and Asana is used for the work tracking.

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

Asana has no native invoice, purchase order, payment, or GL account entities, so ml-connector carries that data in customer-defined custom fields on the task, such as document number, vendor, and amount. Those fields are mapped per customer up front and resolved by GID, because Asana lets fields be renamed. List calls also request opt_fields so the custom field values are actually returned rather than left out.

Does the integration rely on webhooks or polling?

It uses both. Business Central purchase invoices can drive task creation through push subscriptions, but those signal a change without data, so the connector then fetches the record, and the three-day subscriptions are renewed by a cron job. Purchase orders are not webhook-supported in Business Central, so they are polled on a schedule using an OData lastModifiedDateTime filter.