Microsoft Dynamics NAV and Asana integration

What moves between them

Purchase orders and sales orders from Microsoft Dynamics NAV flow into Asana as tasks, one document per task. The task name includes the document number and vendor or customer name. Custom fields in Asana hold the order amount, due date, vendor or customer ID, and item descriptions. The sync runs on a polling schedule configured per customer. Invoices may also be synced as tasks if the Asana workspace defines custom fields to carry invoice-specific metadata such as invoice number and GL account code. No data flows back from Asana to NAV; Asana is read-only for the GL account perspective since it cannot modify NAV ledger entries.

How ml-connector handles it

ml-connector reads the NAV instance URL, OAuth 2.0 client ID and secret, and tenant ID from your stored credentials and authenticates each request to NAV via the OAuth 2.0 flow. It polls NAV on your schedule for new or changed purchase orders and sales orders, filtering by the created or modified date. For each order, it retrieves the vendor or customer record to obtain the full name and maps fields into the Asana task schema: the document number becomes the task name, the vendor name and amount are stored in custom fields, and the due date is set on the task. Before writing tasks, ml-connector uses the Asana API to discover the custom fields available in your workspace, ensuring it does not write to fields that don't exist. It authenticates to Asana with your PAT or OAuth 2.0 credentials. If an order has been synced before, ml-connector updates the existing Asana task; otherwise it creates a new task in the project you assign. On error, tasks are retried according to the configured tier (Low, Med, or High) and every change is logged in the audit trail with the original order ID and any field mappings that were applied.

A real-world example

A mid-size manufacturing company runs Microsoft Dynamics NAV for procurement and finance and uses Asana for project management across engineering, production, and supply chain teams. Before the integration, procurement sent purchase order notifications by email, and team members had to manually create Asana tasks to track the orders, duplicating effort and losing the link between the PO and the work. When a PO was modified or invoiced, the Asana task went stale. With NAV and Asana connected, each new purchase order creates a task in the relevant project automatically, with the vendor name, amount, and due date in custom fields that the team can filter and sort on. Invoice notifications can also create or update tasks, letting supply chain track received goods and payment status without leaving Asana. The manual task creation step is gone and the PO is always current.

What you can do

• •Push purchase orders and sales orders from Microsoft Dynamics NAV into Asana tasks, updated whenever the order status or due date changes.
• •Map vendor and customer names, order amounts, and due dates into Asana custom fields so team members can view financial metadata without switching systems.
• •Authenticate to Microsoft Dynamics NAV via OAuth 2.0 with tenant and company ID scoping, and to Asana via Bearer token or OAuth 2.0.
• •Handle Asana custom field schema discovery automatically, ensuring ml-connector does not write to fields that do not exist in your workspace.
• •Maintain a full audit trail of every order synced, with task IDs, field mappings, and any errors, for compliance and troubleshooting.

Questions

Does the integration sync purchase orders back from Asana to Microsoft Dynamics NAV?

No. The sync is one-way, from NAV into Asana. Asana has no native finance objects and cannot modify NAV purchase orders or GL entries. However, you can update the custom fields in Asana tasks manually or via other workflows, and those updates remain in Asana only. NAV stays the source of truth for all procurement and financial data.

How does ml-connector handle Microsoft Dynamics NAV's 3-day webhook expiry?

ml-connector polls NAV on a schedule you configure rather than relying on webhooks, so the 3-day expiry does not affect the integration. Polling is more reliable for long-running integrations and allows you to control the sync cadence based on your procurement calendar, such as after weekly PO runs or daily end-of-shift batches.

What if an Asana custom field does not exist when ml-connector tries to write a purchase order?

ml-connector discovers your workspace's custom field schema at the start of each sync. If a field is missing, the task is created with the fields that do exist, such as task name and due date, and the missing field is reported in the audit log. You can add the custom field to your Asana workspace and re-sync the order to populate it, or leave the task with the basic fields and manually enter the financial metadata in Asana.