Connecting n8n to Power BI: pushing real-time data with the push dataset API

A Power BI dashboard fed by a manual CSV export every Friday is a dashboard that's lying to you by Monday. Plenty of teams already automating email, support, or CRM work with n8n still fill their Power BI reporting by hand — because n8n has no native Power BI node, and Microsoft's documentation on the topic is scattered across three products (push dataset, streaming dataset, Fabric). A landmark study by Brynjolfsson, Hitt, and Kim (Strength in Numbers: How Does Data-Driven Decisionmaking Affect Firm Performance?, 2011 — see on Google Scholar) found that companies driving decisions with data show productivity 5 to 6% higher than what their technology investments alone would predict — provided, of course, the data on screen is actually current. This guide covers how to wire n8n into Power BI so your dashboards update themselves, no manual export required.

Why there's no "Power BI" node in n8n

Unlike HubSpot or Notion, Power BI has no dedicated node in n8n's core. You have two options:

• HTTP Request + Microsoft Entra ID credential (native, built into n8n): the method described here — it works on n8n Cloud and self-hosted alike, with nothing to install.
• The community node n8n-nodes-powerbi: faster to configure once installed, but it requires enabling community nodes on your instance — not possible on some restricted n8n Cloud plans, and one more dependency to maintain over time.

For an integration meant to stay stable, HTTP Request + Entra ID is the more robust choice: it relies solely on Power BI's official REST API, documented and versioned by Microsoft.

Registering the Azure AD (Microsoft Entra ID) application

Everything starts with an application registered in Microsoft Entra ID (formerly Azure Active Directory), which acts as n8n's technical identity:

1. On portal.azure.com, go to Microsoft Entra ID → App registrations → New registration.
2. Give it a name (e.g. "n8n-powerbi-push") and keep the default account type.
3. Under API permissions, add the Power BI Service API with the delegated Dataset.ReadWrite.All permission, then grant admin consent.
4. Under Certificates & secrets, create a client secret and copy it immediately — it's never shown in full again.
5. Note the Application (client) ID and the Directory (tenant) ID from the Overview tab.

One detail that's costly to debug if skipped: by default, any Entra ID application can call the Power BI API on behalf of a given user. In the Power BI admin portal, under Tenant settings → Developer settings, you can restrict API usage to a specific security group — a least-privilege practice worth applying before going to production, in the same spirit as our guide on securing API credentials in n8n.

Setting up the credential in n8n

In n8n, create a new credential of type Microsoft Entra ID (Azure Active Directory) — native, no community node needed for this part. Fill in the Client ID, Client Secret, and Tenant ID from the previous step, and set the scope to https://analysis.windows.net/powerbi/api/.default. Test the connection: n8n should retrieve a valid OAuth2 token.

Then add an HTTP Request node, set authentication to "Predefined Credential Type" → Microsoft Entra ID, and you're ready to call any Power BI API endpoint.

Creating the push dataset

A push dataset is created with a single API call, describing its schema in JSON. From an HTTP Request node doing a POST to https://api.powerbi.com/v1.0/myorg/datasets, with a body like:

{
  "name": "n8n_support_tickets",
  "defaultMode": "Push",
  "tables": [{
    "name": "tickets",
    "columns": [
      { "name": "id", "dataType": "String" },
      { "name": "priority", "dataType": "String" },
      { "name": "ai_score", "dataType": "Int64" },
      { "name": "timestamp", "dataType": "DateTime" }
    ]
  }]
}

The response returns a dataset id to reuse for every subsequent row push. It's the same principle as an ingestion pipeline into Supabase pgvector: define a strict schema first, then feed it continuously.

Pushing rows from an n8n workflow

Picture a scenario close to what our guide on AI-scored support tickets covers: an n8n workflow classifies and scores every incoming ticket, then pushes the result to Power BI for a live dashboard the whole support team can see, instead of a Google Sheet checked once a week.

After the AI scoring node, a second HTTP Request node doing a POST to .../datasets/{datasetId}/tables/tickets/rows with a {"rows": [...]} body is enough. Three limits to respect, per Microsoft's documentation:

Limit	Value
Rows per POST request	10,000 max
Rows added per hour per dataset	1,000,000
POST requests per minute per dataset	120
Concurrent pending POST requests	5 max

For a one-ticket-at-a-time flow, a single row per run stays well under these limits. For a bulk import or a full resync, split the upload with a Loop Over Items node and a Wait step between each batch of a few thousand rows, exactly as recommended in our guide on handling 429 errors.

Push dataset or streaming dataset: which retention policy

Power BI offers three profiles, chosen when the dataset is created:

Profile	History kept	Queryable in a report	Use case
Push, no retention (none)	5,000,000 rows/table	✅ Yes	Analytical dashboard with full history
Push, FIFO retention	200,000 rows/table (rolling)	✅ Yes	Rolling window (last 30-90 days)
Pure streaming	~200,000 rows cached, not persisted	❌ Live tile only	Instant metric (counter, gauge)

For a support or compliance dashboard that needs to keep a usable trail over time — in the spirit of what the Compliance & Audit Pack (€149) covers — the no-retention push mode is the right call: you keep full history on the Power BI side, rather than relying solely on the audit trail stored in Supabase.

Limits to know before you start

A push dataset isn't a general-purpose data warehouse: a maximum of 75 columns and 75 tables per dataset, no relationships between tables or advanced DAX measures like in classic import mode, and using the API requires a Power BI Pro or Premium Per User (PPU) license on the target workspace — a free account isn't enough. If your need goes beyond this scope (complex joins, large historized volumes, a star schema), feed a real database instead — see our comparison of n8n Data Tables vs Supabase or Postgres — then connect Power BI to it in classic import or DirectQuery mode, which is beyond this guide.

Wrapping up

Without a native node, Power BI stays reachable from n8n through HTTP Request and a standard Microsoft Entra ID credential: register the Azure AD application, define the push dataset's schema, then push rows as your workflows run, respecting the quotas (10,000 rows/request, 120 requests/minute). That's enough to turn any pipeline you already run in n8n — email triage, ticket scoring, an audit trail — into a Power BI dashboard that updates itself, no more Friday-night manual export.