.png)
Microsoft Power BI Integration Guide
Microsoft Power BI integrates with enterprise systems primarily through REST APIs, Microsoft Entra ID authentication, semantic-model queries, refresh operations, imports, exports, and selected event mechanisms.
Microsoft Power BI integration options at a glance
Microsoft Power BI provides REST APIs for workspaces, reports, dashboards, semantic models, dataflows, refreshes, imports, exports, and administrative operations. Eligible semantic models can be queried through the Execute Queries API, while XMLA endpoints provide advanced model and metadata operations in supported Premium, Premium Per User, or Fabric-capacity scenarios. Power BI supports Microsoft Entra ID OAuth 2.0 through delegated or application permissions. Selected scenarios offer webhook-style notifications, but there is no universal outbound webhook for every object change. Martini can orchestrate scheduled or API-led workflows, poll asynchronous operations, map JSON responses, and expose controlled APIs for downstream applications.
| Integration point | Supported by Microsoft Power BI? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage workspaces, reports, dashboards, tiles, semantic models, dataflows, refreshes, imports, exports, permissions, and administrative metadata. | Martini can consume Power BI REST APIs over HTTPS, authenticate with OAuth 2.0, transform JSON, and orchestrate multi-step workflows. |
| XMLA endpoints | Limited | Perform advanced semantic-model metadata, model-management, and processing operations for eligible Premium, Premium Per User, or Fabric-capacity scenarios. | Martini can call supported XMLA-compatible endpoints when the target capacity, permissions, and authentication configuration allow access. |
| Webhooks / outbound callbacks | Limited | Receive notifications for selected Power BI scenarios where the relevant feature, object, tenant configuration, and licensing support it; there is no universal object-change webhook. | Martini can receive webhook-style notifications and use them to start workflows, but broad synchronization should use scheduled reads or Microsoft eventing where appropriate. |
| Bulk / async / batch APIs | Yes | Coordinate imports, exports, scans, refresh-related operations, and selected administrative or metadata processes that may complete asynchronously. | Martini can store operation identifiers, poll status endpoints, enforce timeouts, and apply bounded retries. |
| File / report content APIs | Limited | Import Power BI files and export supported reports to supported formats, subject to report type, capacity, licensing, tenant settings, permissions, and file constraints. | Martini can transfer exported files to approved repositories or downstream processes and keep file content out of logs. |
| Semantic-model query APIs | Yes | Execute approved DAX queries against eligible semantic models to extract governed analytical results for applications or operational workflows. | Martini can call Execute Queries, validate result size and structure, map responses to stable API contracts, and apply business rules. |
| Authentication | Yes | Use Microsoft Entra ID OAuth 2.0 with delegated permissions or application and service-principal permissions, subject to tenant, workspace, security-group, and capacity configuration. | Martini can store environment-specific OAuth configuration and secrets securely while applying least-privilege access to workflows and APIs. |
| Database access | Not applicable | Power BI is primarily an analytics and visualization service rather than a general-purpose operational database. | Martini should use Execute Queries or XMLA for supported semantic-model access and connect directly to the underlying warehouse, lakehouse, SQL database, or source application for transactional data. |
How Microsoft Power BI exposes data and business events
Microsoft Power BI REST APIs
Power BI REST APIs are the principal integration surface for workspaces, reports, dashboards, semantic models, dataflows, refreshes, imports, exports, permissions, and selected administrative operations. Most calls use JSON over HTTPS and require Microsoft Entra ID access tokens with operation-specific permissions.
Martini implementation pattern
Martini implementation pattern: A workflow authenticates with Microsoft Entra ID, calls the required Power BI resource, follows pagination or continuation tokens, maps the response into a canonical model, and writes the result to a target system or returns it through a Martini API.
Implementation sequence
Semantic-model queries
The Execute Queries REST API enables DAX queries against eligible semantic models. Query permissions, tenant settings, result limits, model configuration, and licensing or capacity constraints determine whether a particular query can run.
Martini implementation pattern
Martini implementation pattern: A controlled Martini API or scheduled workflow submits an approved query, validates the response structure and size, transforms analytical results into a stable contract, and avoids exposing Power BI credentials or model details to consuming applications.
Implementation sequence
Refresh and asynchronous operations
Power BI refreshes, imports, exports, scans, and related operations may be asynchronous. A successful request only indicates that Power BI accepted the operation, so the final status must be retrieved separately.
Martini implementation pattern
Martini implementation pattern: A workflow submits the operation, stores its identifier, polls the appropriate status or history endpoint, and routes success, failure, timeout, or overlapping-refresh conditions according to business rules.
Implementation sequence
Webhook-style notifications
Power BI provides notification capabilities for selected scenarios, but it does not expose a universal outbound webhook for every report, dashboard, workspace, semantic-model, membership, or data change. Exact event availability must be verified for the target scenario.
Martini implementation pattern
Martini implementation pattern: Martini can expose a receiving endpoint for a confirmed Power BI notification, validate the request, retrieve the current Power BI resource, and use scheduled reconciliation to cover changes that are not event-enabled.
Implementation sequence
XMLA endpoints
XMLA endpoints provide Analysis Services-compatible access to semantic-model metadata and advanced model operations in eligible Premium, Premium Per User, or Fabric-capacity scenarios. XMLA is not available for every Power BI workspace.
Martini implementation pattern
Martini implementation pattern: Where capacity and permissions support XMLA, Martini invokes the endpoint using Microsoft Entra authentication, isolates XMLA-specific operations in reusable workflow logic, and falls back to REST APIs when the required capability is available there.
Implementation sequence
Common Microsoft Power BI integration patterns
Pattern 1: Orchestrate semantic-model refreshes
When to use this pattern
Use this pattern when an upstream load in Azure Data Factory, Microsoft Fabric, Azure Synapse Analytics, or another source platform must complete before Power BI refreshes. It coordinates data readiness with reporting availability and avoids querying partially loaded data.
Integration direction
Example Mapping
| Microsoft Power BI Field | Canonical Field | Target Field |
|---|---|---|
| pipelineRunId | sourceLoadId | refreshCorrelationId |
| loadCompletedAt | sourceDataReadyAt | refreshRequestedAt |
| refreshStatus | reportingRefreshStatus | incidentOrNotificationStatus |
| errorMessage | failureReason | workNote |
Martini implementation pattern
A Martini workflow receives or polls the upstream completion status, validates the load, calls the Power BI refresh endpoint, stores the operation identifier, and polls until completion. It applies bounded retries for throttling, prevents overlapping refreshes, and creates an operational notification or ServiceNow record for terminal failures.
Martini capabilities used
- workflows
- scheduler triggers
- API consumption
- data mapping
- business rules
- error handling
- monitoring
Pattern 2: Expose governed analytical results
When to use this pattern
Use this pattern when applications need selected Power BI metrics without receiving direct Power BI credentials or model-specific access. The workflow provides a stable contract around an approved DAX query and can apply validation or enrichment before returning data.
Integration direction
Example Mapping
| Microsoft Power BI Field | Canonical Field | Target Field |
|---|---|---|
| CustomerId | customerId | customerId |
| TotalSales | totalSales | salesAmount |
| SalesDate | reportingDate | date |
| Region | salesRegion | region |
Martini implementation pattern
Martini exposes a controlled API, authenticates to Power BI, executes a narrowly scoped query against an eligible semantic model, validates row and result limits, and maps the response into a versioned consumer contract. Query failures, authorization errors, and schema changes are returned or routed according to the API policy.
Martini capabilities used
- APIs
- API consumption
- JSON handling
- data mapping
- validation
- business rules
- error handling
Pattern 3: Synchronize Power BI inventory
When to use this pattern
Use this pattern for governance, ownership reviews, report catalog maintenance, stale-content detection, or comparison of Power BI assets with an enterprise registry. It is appropriate when broad change events are unavailable or incomplete.
Integration direction
Example Mapping
| Microsoft Power BI Field | Canonical Field | Target Field |
|---|---|---|
| workspaceId | containerId | configurationItemId |
| reportId | assetId | externalReference |
| name | assetName | displayName |
| lastRefreshTime | lastSuccessfulRefreshAt | lastActivityAt |
Martini implementation pattern
A scheduled Martini workflow retrieves workspaces, reports, dashboards, semantic models, dataflows, and refresh metadata using paginated APIs. It normalizes identifiers, upserts inventory records, detects stale or failed assets, and routes exceptions for review while retaining checkpoints and request diagnostics.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- database integration
- upsert logic
- error handling
Pattern 4: Export and distribute approved reports
When to use this pattern
Use this pattern when supported Power BI reports must be delivered to SharePoint Online, a document process, Microsoft Teams, or another approved destination. Export eligibility, capacity, licensing, format, and file-size constraints must be evaluated first.
Integration direction
Example Mapping
| Microsoft Power BI Field | Canonical Field | Target Field |
|---|---|---|
| reportId | reportReference | sourceReportId |
| requestedFormat | exportFormat | fileExtension |
| operationStatus | exportStatus | deliveryStatus |
| fileContent | reportFile | documentContent |
Martini implementation pattern
Martini requests the supported export, stores the asynchronous operation identifier, polls for completion, validates the returned file and destination policy, and transfers the file securely. It prevents duplicate delivery using a correlation key and routes unsupported formats, failed exports, or expired operations to an operational queue.
Martini capabilities used
- workflows
- API consumption
- asynchronous orchestration
- file handling
- data mapping
- idempotency
- error handling
Applications commonly integrated with Microsoft Power BI
Microsoft Power BI is commonly positioned alongside Microsoft data services, business applications, operational platforms, and collaboration tools. Martini can coordinate these systems through their documented APIs, scheduled workflows, file exchanges, and controlled API contracts rather than treating Power BI as a transactional database.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Microsoft Fabric | Coordinate Power BI semantic models and reports with Fabric lakehouses, warehouses, notebooks, pipelines, and capacity resources. | Microsoft Fabric → Martini → Microsoft Power BI | Use REST API workflows to coordinate upstream data loads, trigger semantic-model refreshes, poll completion, and publish refresh or inventory status to governance processes. |
| Azure Data Factory | Load and transform source data before triggering Power BI semantic-model refreshes and monitoring completion. | Azure Data Factory → Martini → Microsoft Power BI | Receive or poll pipeline completion, validate the source load, call the Power BI refresh API, and apply bounded polling, timeout, and notification rules. |
| Azure Synapse Analytics | Publish governed warehouse or lake data to Power BI semantic models and coordinate reporting refreshes. | Azure Synapse Analytics → Martini → Microsoft Power BI | Orchestrate the upstream load and Power BI refresh through separate API calls, storing environment-specific workspace and semantic-model identifiers in configuration. |
| Microsoft Dynamics 365 | Combine customer, sales, service, or finance information with Power BI reporting and refresh workflows. | Microsoft Dynamics 365 → Martini → Microsoft Power BI | Consume Dynamics 365 or intermediary data-platform APIs, map source data into the analytical loading contract, and trigger or monitor the related Power BI refresh. |
| Salesforce | Consolidate Salesforce sales and service information into Power BI dashboards and governed semantic models. | Salesforce → Martini → Microsoft Power BI | Retrieve Salesforce data through its APIs or an established data pipeline, validate and transform the payload, then coordinate Power BI refresh and status reporting. |
| ServiceNow | Report on incidents, requests, changes, and service operations in Power BI while routing refresh failures into IT operations workflows. | ServiceNow → Martini → Microsoft Power BI | Use workflows to retrieve or receive ServiceNow data, coordinate Power BI refreshes, and write refresh failures or stale-report alerts back to ServiceNow. |
| SharePoint Online | Analyze SharePoint list or document metadata in Power BI and distribute exported reports through Microsoft 365 repositories. | SharePoint Online → Martini → Microsoft Power BI | Coordinate SharePoint or Microsoft Graph API calls with Power BI imports or exports, securely transferring files and recording operation status. |
| Microsoft Teams | Surface Power BI reports to teams and coordinate notifications around refresh completion or report availability. | Microsoft Power BI → Martini → Microsoft Teams | Monitor Power BI operations, apply notification rules, and call the appropriate Microsoft Teams API or intermediary workflow to publish status messages. |
How to build a Microsoft Power BI integration in Martini
Objective
Configure Microsoft Entra ID OAuth 2.0 access for the selected Power BI operations and keep environment-specific identifiers and secrets outside workflow logic.
Instructions in Martini
- Choose delegated or application/service-principal access based on the operating model
- Request only the required Power BI permissions
- Store client credentials, tokens, workspace IDs, and capacity references in secure environment configuration
- Confirm tenant settings, workspace roles, security-group access, and capacity prerequisites
Objective
Select an event, inbound API request, or schedule that matches the reliability needs of the integration.
Instructions in Martini
- Use a Martini API or trigger for an upstream completion signal when available
- Use a scheduler for refresh, inventory, and reconciliation workflows
- Treat Power BI webhook-style notifications as selective rather than universal
- Define a polling interval and checkpoint strategy for event gaps
Objective
Call the relevant Power BI REST, Execute Queries, import, export, refresh, or XMLA endpoint and account for pagination and asynchronous responses.
Instructions in Martini
- Call the required endpoint with the Microsoft Entra bearer token
- Follow continuation tokens or pagination until the collection is complete
- Store operation identifiers for imports, exports, scans, and refreshes
- Use narrow DAX queries and validate query limitations before processing results
Objective
Coordinate Power BI calls with upstream systems, downstream applications, notifications, and operational state.
Instructions in Martini
- Separate request acceptance from final operation completion
- Poll status with bounded timeouts
- Prevent overlapping refreshes and duplicate exports
- Persist correlation IDs, checkpoints, and terminal status
Objective
Transform Power BI JSON, metadata, query results, and file information into stable canonical and target-specific models.
Instructions in Martini
- Map workspace, report, dashboard, semantic-model, dataflow, and refresh identifiers explicitly
- Validate required fields and expected query-result schemas
- Keep model and workspace mappings environment-specific
- Apply business validation before writing results or exposing API responses
Objective
Deliver refreshed status, analytical results, inventory, or exported files to the target system while protecting sensitive content.
Instructions in Martini
- Upsert inventory and refresh status into the target store
- Transfer supported report exports only to approved destinations
- Create operational notifications or ServiceNow records for actionable failures
- Avoid logging bearer tokens, full query results, or report contents
Common Microsoft Power BI data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Workspaces | Contain reports, dashboards, semantic models, dataflows, permissions, and related Power BI content. | Governance databases, configuration-management systems, Microsoft Fabric, ServiceNow | Martini retrieves workspace inventories, maps identifiers and ownership metadata, and stores environment-specific references for downstream workflows. |
| Reports | Define interactive report pages and visualizations that reference one or more semantic models. | Governance catalogs, SharePoint Online, Microsoft Teams, document repositories | Martini can inventory reports, request supported exports, track asynchronous operations, and distribute approved report files. |
| Dashboards | Present collections of dashboard tiles and summarized visual information. | Governance catalogs, Microsoft Teams, operational registries | Martini retrieves dashboard and tile metadata, maps it into catalog models, and applies ownership or stale-content rules. |
| Semantic models | Provide modeled data for reports and support governed analytical queries and refresh operations. | Data warehouses, lakehouses, business applications, governance databases | Martini can trigger and monitor refreshes, execute approved queries, validate response schemas, and use XMLA when supported. |
| Dataflows | Provide reusable data-preparation assets that load and transform data for Power BI consumption. | Microsoft Fabric, Azure Data Factory, data warehouses, governance systems | Martini can inventory dataflows and coordinate upstream processing or downstream refresh workflows where the required APIs are available. |
| Refreshes | Represent semantic-model refresh operations and refresh history, including status and failure details. | Monitoring platforms, ServiceNow, notification workflows, governance databases | Martini records request and operation identifiers, polls status, applies timeout and retry rules, and routes failures for operational follow-up. |
Authentication and security considerations
Microsoft Entra ID and OAuth 2.0
Power BI uses Microsoft Entra ID OAuth 2.0. Martini workflows can use delegated access for user-driven operations or application and service-principal access for unattended processing when tenant settings, workspace roles, security groups, and capacity configuration permit it.
Least privilege
Configure only the Power BI permissions required for each workflow. Administrative operations and XMLA access may require elevated authorization beyond ordinary workspace access.
Secrets and analytical data
- Store client secrets, tokens, and environment-specific identifiers in secure Martini configuration.
- Do not log bearer tokens, complete DAX results, report exports, or other sensitive analytical content.
- Restrict Martini APIs that expose Power BI results and apply authorization to downstream consumers.
Operational considerations for Microsoft Power BI integrations
Throttling and pagination
Power BI APIs can return throttling responses and paginated collections. Martini workflows should honor retry information, use bounded exponential backoff, follow continuation tokens, and avoid repeatedly retrieving unchanged inventories.
Asynchronous operations
Imports, exports, scans, and refreshes may return before the operation is complete. Store operation identifiers, poll with a timeout, and distinguish request acceptance from successful completion.
Refresh and idempotency
Refresh requests can overlap or be rejected while another refresh is running. Use correlation identifiers, checkpoints, and duplicate-prevention rules before retrying a request whose response may have been lost.
Models and environments
Workspace, report, dashboard, and semantic-model identifiers differ across environments. Keep identifiers and mappings configurable, validate expected query fields, and plan for schema, measure, and model changes.
Testing and monitoring
Test permissions, query limits, export eligibility, failure responses, and capacity behavior in each target environment. Monitor refresh history, operation latency, throttling, failed mappings, and workflow logs without recording sensitive content.
Why use Martini instead of scripts or point-to-point integrations?
Coordinate complete business processes
Scripts often implement one API call, while Martini workflows can coordinate upstream loads, Power BI operations, polling, transformations, notifications, and downstream writes in a maintainable integration flow.
Separate vendor APIs from enterprise contracts
Martini can expose a controlled API around Power BI queries or metadata, map vendor-specific responses into stable contracts, and keep Power BI credentials and model details away from consuming applications.
Make operational behavior explicit
- Apply consistent authentication, validation, retry, timeout, and idempotency policies.
- Reuse workflow logic for refresh orchestration, inventory synchronization, and report distribution.
- Monitor failures and route actionable events to operational systems instead of relying on isolated scripts.
Frequently asked questions
Power BI can be integrated primarily through its REST APIs for workspaces, reports, dashboards, semantic models, dataflows, refreshes, imports, exports, queries, and administration. Microsoft Entra ID OAuth 2.0 provides delegated or application authentication. XMLA can support advanced semantic-model operations in eligible capacities, while webhook-style notifications are available only for selected scenarios.
Yes. Martini can integrate with Microsoft Power BI by consuming its REST APIs, executing supported semantic-model queries, coordinating refreshes and asynchronous operations, transferring supported report exports, and using XMLA or selected notification mechanisms where the tenant, capacity, permissions, and licensing support them.
No dedicated Microsoft Power BI connector is required. Martini can use Power BI's native REST APIs, Microsoft Entra ID authentication, supported XMLA endpoints, selected webhook-style notifications, and file or export operations to implement the integration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Microsoft Power BI with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Microsoft, cloud infrastructure, or other third-party systems based on licensing, usage, capacity, and deployment model.
REST APIs are the primary choice for current integrations. Use Execute Queries for governed analytical extraction, refresh and status APIs for orchestration, import and export APIs for supported file operations, and XMLA for advanced semantic-model capabilities in eligible Premium, Premium Per User, or Fabric-capacity scenarios.
Power BI provides webhook-style or notification capabilities for selected scenarios, but it does not provide a universal webhook for every object or data change. Martini can receive confirmed notifications, while scheduled polling, refresh history, activity APIs, or Microsoft eventing services may be required for broader synchronization.
Synchronization commonly uses scheduled REST API reads, refresh-status polling, inventory checkpoints, and targeted Execute Queries calls. Power BI should not generally be treated as a transactional change-data-capture source; the underlying warehouse, lakehouse, database, or source application is usually better for data-level change events.
Martini can capture HTTP errors and Power BI operation failures, honor throttling responses, use bounded exponential backoff, poll asynchronous operations with timeouts, and apply idempotency keys or correlation identifiers. Workflows can prevent duplicate refreshes or exports and route terminal failures to monitoring or service-management processes.
Related Martini documentation
Workflows
Data Processing
Connect Microsoft Power BI with Martini
Use Martini to build secure, maintainable Power BI integrations for refresh orchestration, governed analytical access, inventory synchronization, and report distribution.