Can Asana hold QAD invoices, POs, or GL accounts directly?

No. Asana is a work and project management tool with no native invoice, purchase order, payment, or GL account objects. ml-connector carries that financial detail in Asana custom fields the customer configures, mapping PO numbers, cost codes, and amounts onto tasks and projects. The authoritative finance records stay in QAD.

Which direction does data move between QAD and Asana?

The main flow is QAD into Asana, creating tasks and projects from purchase orders, suppliers, and receipts. The return flow reads approval status, completion, and cost-code custom fields from Asana back into the matching QAD records. User rosters are read from Asana for assignee mapping but never written, since Asana manages users outside the REST API.

How does the integration handle updates given QAD has no webhooks?

Asana supports push webhooks, so ml-connector registers one, completes the X-Hook-Secret handshake, and verifies the HMAC-SHA256 signature on each event to pick up task changes within about a minute. QAD cloud has no push, so ml-connector polls purchase orders and receipts on a schedule you set. If Asana auto-deletes a webhook after a delivery outage, the connector detects it and re-registers.

QADAsana

QAD and Asana integration

QAD runs manufacturing, procurement, and finance. Asana runs the work and project tracking that surrounds those processes. Connecting the two lets QAD purchase orders, supplier records, and goods receipts show up as Asana tasks that operations and approvers can follow, while the custom fields people fill in on those tasks feed status back to QAD. Asana has no native invoice, PO, payment, or GL objects, so the financial detail rides in custom fields the customer configures, and ml-connector maps those fields to QAD on a schedule you control.

How QAD works

QAD Adaptive ERP exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, items, goods receipts, and AP payments through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname, public sandbox, or developer portal. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD cloud has no native webhook system for connectors, so records are read by polling on a schedule.

How Asana works

Asana exposes tasks, projects, portfolios, teams, users, goals, and custom fields through a REST JSON API at app.asana.com, using a personal access token or OAuth 2.0 authorization-code bearer token. It has no native finance objects, so PO numbers, cost codes, GL accounts, and budget amounts are carried in customer-defined custom fields on tasks and projects. Asana supports real push webhooks, delivered as signed POSTs with an HMAC-SHA256 signature keyed by the handshake secret, and uses offset-based pagination with per-token rate limits. Users and workspaces are read-only over the API.

What moves between them

The main flow runs from QAD into Asana. ml-connector reads QAD purchase orders, supplier records, and goods receipts and creates or updates Asana tasks and projects, writing PO numbers, suppliers, and amounts into the matching custom fields. The return flow runs from Asana into QAD: when a task is completed or its approval and cost-code custom fields change, ml-connector reads those values and updates the related QAD record. QAD is polled on a schedule because it has no push, while Asana task and project changes arrive over webhooks within about a minute. User rosters are read from Asana for assignee mapping but never written, since Asana manages users through admin and SCIM rather than the REST API.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the Asana personal access token or OAuth bearer token on every call, refreshing the OAuth token when a request returns 401. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and validates entity paths against that instance. Because QAD cloud is pull-only, it polls purchase orders and receipts on a schedule, while it registers an Asana webhook, completes the X-Hook-Secret handshake, and verifies the HMAC-SHA256 signature on each incoming event. Custom fields are mapped by GID rather than name, since names can be renamed, and the connector requests opt_fields so responses are not sparse. Asana GIDs are stored after first create so a re-sync updates instead of duplicating, which covers the missing idempotency key, and a BullMQ jobId dedups the queue. Asana rate limits return 429 with a Retry-After header per token, so ml-connector backs off and retries, and it re-registers any webhook that Asana auto-deletes after a delivery outage. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer with about 300 employees runs QAD Adaptive ERP for procurement and finance, but its operations and facilities teams live in Asana and have no QAD logins. Before the integration, a buyer raised a PO in QAD and then re-typed it into an Asana task so the shop floor and approvers could track delivery, and status updates made in Asana never found their way back to the ERP. With QAD and Asana connected, each new QAD purchase order and goods receipt appears as an Asana task carrying the PO number and supplier in custom fields, and when an approver marks the task done in Asana the approval flows back to QAD. The double entry is gone and both teams see the same state.

What you can do

Create and update Asana tasks and projects from QAD purchase orders, suppliers, and goods receipts.
Carry QAD PO numbers, cost codes, and amounts in Asana custom fields mapped by GID.
Read approval status and completion from Asana tasks back into the related QAD records.
Authenticate Asana with a personal access token or OAuth 2.0 bearer token and QAD with its tenant-specific login.
Receive Asana task changes over signed webhooks while polling QAD on a schedule, with retries and a full audit trail.

Questions

Can Asana hold QAD invoices, POs, or GL accounts directly?: No. Asana is a work and project management tool with no native invoice, purchase order, payment, or GL account objects. ml-connector carries that financial detail in Asana custom fields the customer configures, mapping PO numbers, cost codes, and amounts onto tasks and projects. The authoritative finance records stay in QAD.
Which direction does data move between QAD and Asana?: The main flow is QAD into Asana, creating tasks and projects from purchase orders, suppliers, and receipts. The return flow reads approval status, completion, and cost-code custom fields from Asana back into the matching QAD records. User rosters are read from Asana for assignee mapping but never written, since Asana manages users outside the REST API.
How does the integration handle updates given QAD has no webhooks?: Asana supports push webhooks, so ml-connector registers one, completes the X-Hook-Secret handshake, and verifies the HMAC-SHA256 signature on each event to pick up task changes within about a minute. QAD cloud has no push, so ml-connector polls purchase orders and receipts on a schedule you set. If Asana auto-deletes a webhook after a delivery outage, the connector detects it and re-registers.

Connect QAD and Asana

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started