Three Ways to Integrate Dataverse in Real Time

Choosing the right integration interface for Power Platform database tables

The default answer to almost every Dataverse integration question used to be reassuringly simple. Pick a connector, wire it to a flow, and call it a day.

The connector catalogue has grown. The integration surface has expanded. And the question has shifted from whether you can connect to Dataverse to which layer should own the connection, the transformation, and the error handling.

This article compares three approaches for real-time integration with Dataverse tables: Azure Logic Apps, Azure Functions, and custom APIs that talk directly to the database. Each has a place. None of them is universally correct.

The integration boundary matters more than the tool

Before choosing a tool, define the boundary.

The integration layer sits between an external system and Dataverse. It receives a request, transforms data, enforces rules, and writes or reads from the database. Where that boundary falls determines which tool fits.

If the boundary is close to Dataverse and the logic is straightforward, the platform's native tools often suffice. If the boundary needs to reach further into external systems or apply complex transformation, you need something more flexible. If latency is critical and every millisecond counts, you need something faster.

The three approaches represent different points on a spectrum from convenience to control.

Azure Logic Apps: the convenience layer

Azure Logic Apps shares the same connector runtime as Power Automate. The distinction is not technical. It is operational. Logic Apps runs on Azure infrastructure with enterprise-grade monitoring, access control, and deployment pipelines. Power Automate runs on the Power Platform with maker-friendly tooling and governance controls.

For Dataverse integration, Logic Apps gives you the Dataverse connector, the HTTP trigger, and the full connector library in a single designer. You build a workflow with a visual interface, define the trigger, add the actions, and deploy.

Where Logic Apps works well:

The integration involves a handful of connectors. The workflow reads from one system, transforms the data, and writes to Dataverse. The logic is linear with maybe a branch or two. The response time of a few hundred milliseconds to a couple of seconds is acceptable.

Where Logic Apps struggles:

The workflow needs to perform complex data transformation that the visual designer cannot express cleanly. The integration must respond within tens of milliseconds. The workflow requires custom code that Logic Apps can only reach through an embedded Azure Function call, which defeats the purpose.

Concrete example:

A Logic App receives an HTTP request from an external ordering system. The request contains customer details and order items. The Logic App calls the Dataverse connector to create an account record, then creates a related order record, then writes the order items. The workflow completes in approximately 800 to 1500 milliseconds depending on the number of records and the connector load.

This is fine for order processing. It is not fine for a real-time inventory check that needs to return within 100 milliseconds.

Azure Functions: the performance layer

Azure Functions is a serverless compute service. You write code in C#, Python, JavaScript, or any of the supported languages, and the function runs in response to a trigger. For Dataverse integration, the HTTP trigger is the most common pattern.

The function receives the request, connects to Dataverse through the Web API or the SDK, performs the transformation, and returns the response. You control every line of code, every retry, and every timeout.

Where Azure Functions works well:

Latency matters. The function needs to respond within 100 to 200 milliseconds. The integration involves complex transformation logic, multiple API calls, or conditional branching that is awkward to express in a visual designer. The function needs to run custom authentication, handle specific error codes, or implement circuit breakers.

Where Azure Functions struggles:

The function requires a connector that does not have a direct HTTP API. You need to build the connector integration yourself, including authentication, pagination, and error handling. The development team does not have the skills or appetite to maintain custom code. The function needs to interact with Power Platform governance tools, which are designed around connectors and flows rather than standalone code.

Concrete example:

An Azure Function receives an HTTP request containing a product ID. The function queries the Dataverse Web API for the product record, checks inventory levels across three warehouses, applies business rules for availability, and returns a consolidated response. The entire operation completes in approximately 50 to 150 milliseconds.

This is the right tool when the external system expects a fast response and the integration logic is non-trivial.

Custom APIs directly to database: the control layer

This approach bypasses the connector runtime entirely. A custom API, typically built as an Azure Function or an API Management service, connects directly to Dataverse through the Web API or, in some cases, through a direct SQL connection to the underlying database.

The direct SQL path is available through the Dataverse database connection feature, which provides a read-only connection to the underlying SQL database. This is useful for reporting and analytics but comes with significant limitations: it is read-only, it does not respect the platform's business logic, and it bypasses the security model.

For write operations, the Web API remains the supported path. The custom API wraps the Web API calls and adds the transformation, validation, and error handling that the specific integration requires.

Where direct custom APIs work well:

You need full control over the integration contract. The API needs to enforce specific performance characteristics, custom authentication, or complex validation rules. The integration is a core part of the system architecture and needs to be versioned, monitored, and maintained as a first-class component.

Where direct custom APIs struggle:

The development overhead is significant. You build the API, deploy it, monitor it, and maintain it. The API needs its own authentication, rate limiting, error handling, and logging. If the API interacts with Dataverse, it still needs to respect the platform's security model, business rules, and licensing requirements.

Concrete example:

A custom API built as an Azure Function with API Management in front. The API receives requests from multiple client applications, validates the request against a schema, authenticates the caller, queries Dataverse through the Web API, applies business rules, and returns a response. API Management provides rate limiting, caching, and monitoring. The API is versioned and deployed through a CI/CD pipeline.

This is the most flexible approach. It is also the most expensive in terms of development and maintenance.

Latency: the decisive factor

Latency is the factor that separates these approaches in practice.

Logic Apps adds overhead. The workflow engine persists state between steps, even in stateless mode. Each connector call involves authentication, request formatting, and response parsing. A simple Logic App with three connector calls typically takes 500 to 2000 milliseconds.

Azure Functions with an HTTP trigger and a direct Web API call can respond in 50 to 200 milliseconds. The function runs in a warm instance, the Web API call is a single HTTP request, and the response is returned immediately. Cold starts add 1 to 5 seconds, but this is mitigated by the Premium plan or by keeping the function warm.

Custom APIs with API Management caching can respond in 10 to 50 milliseconds for cached responses. For uncached responses, the latency depends on the underlying operations but is typically 50 to 300 milliseconds.

The difference between 200 milliseconds and 2 seconds matters when the integration is part of a user-facing operation. It matters less when the integration runs on a schedule or in response to a background event.

Licensing: the hidden cost

Each approach has different licensing implications.

Logic Apps runs on Azure and is billed based on the plan and the number of actions. The Consumption plan charges per action, while the Standard plan uses Azure App Service pricing. The Logic App itself does not require a Power Platform licence, but if the Logic App uses the Dataverse connector from within Power Automate, the licence requirements of the Power Platform apply.

Azure Functions runs on Azure and is billed based on the plan. The Consumption plan charges per execution and memory usage. The Premium plan provides always-on instances with higher performance. The function itself does not require a Power Platform licence, but accessing Dataverse through the Web API requires appropriate permissions and authentication.

Custom APIs that access Dataverse through the Web API require the same authentication and permissions as any other API client. The API can use a service principal, a managed identity, or user delegation. The licensing depends on how the API authenticates and whether it acts on behalf of a user.

The critical licensing question is not about Azure. It is about whether the integration triggers Power Platform licensing for the end user. If a user interacts with an app or flow that uses Premium connectors, they need a Power Apps or Power Automate licence. If the integration runs as a background service using a service principal, the licensing model is different.

DLP governance: the governance boundary

Power Platform's Data Loss Prevention policies control which connectors can interact with which data. The DLP policy applies to connectors, not to Azure services.

Logic Apps uses the same connector runtime as Power Automate. The connectors used in a Logic App are subject to the same DLP policies as connectors used in Power Automate. If the Logic App runs in the Power Platform environment, the DLP policy applies. If it runs in Azure, the DLP policy does not apply, but the Azure environment has its own governance controls.

Azure Functions does not use the connector runtime. The function connects to Dataverse through the Web API, which is outside the scope of DLP policies. This means the function can access data that a DLP policy would block for a connector. This is a feature, not a bug, but it means the function needs its own governance controls.

Custom APIs have the same situation as Azure Functions. The API connects directly to Dataverse and is not subject to DLP policies. The API needs to implement its own data access controls, audit logging, and compliance measures.

The implication is clear. If your organisation relies on DLP policies to enforce data governance, Azure Functions and custom APIs create a governance gap. You need to compensate with other controls.

Error handling and failure modes

Each approach handles errors differently.

Logic Apps has built-in retry policies. You can configure the retry count, interval, and conditions for each connector action. The workflow engine tracks the execution state and can resume from the last successful step. This is powerful for handling transient failures but adds complexity when you need custom retry logic.

Azure Functions gives you full control over error handling. You implement the retry logic, the circuit breaker, the fallback path, and the error response. This is more work but gives you exactly the behaviour you need. The function can also use Durable Functions for long-running workflows with checkpointing.

Custom APIs need to implement their own error handling. The API should validate the request, handle authentication errors, manage rate limiting, and return meaningful error responses. API Management provides some of this functionality, but the API itself needs to handle business logic errors.

The common failure mode across all three approaches is the Dataverse Web API rate limit. The Web API enforces throttling, and a burst of requests can trigger rate limiting. Each approach needs to handle this gracefully, either through built-in retry (Logic Apps) or custom logic (Azure Functions and custom APIs).

Production pitfalls

Five pitfalls that appear in production regardless of the approach:

The integration works in development and fails in production. The most common cause is a DLP policy that blocks the connector in the production environment. Test in an environment that mirrors production governance before deployment.

The authentication token expires. OAuth tokens expire. If the integration does not handle token refresh, it fails after a period of inactivity. Test the integration after a weekend or a holiday.

The response schema changes. Dataverse evolves. A field is renamed, a relationship is modified, or the API version changes. The integration needs to handle schema drift gracefully. Version your API calls and pin them to specific API versions.

The rate limit is hit. The Web API enforces throttling. Under load, the integration receives 429 responses. Without proper retry logic, the integration fails silently. Implement exponential backoff and monitor the rate limit headers.

The integration bypasses business logic. Direct database access bypasses the platform's business rules, plugins, and workflows. Data written through a direct connection does not trigger the same platform events as data written through the Web API. Understand the difference and design accordingly.

Comparison table

A practical decision framework

Ask these questions in order:

Is latency critical? If the integration needs to respond within 100 to 200 milliseconds, use Azure Functions or a custom API. Logic Apps will not meet the requirement.

Is the integration logic simple? If the workflow involves a handful of connector calls with minimal transformation, Logic Apps is the right choice. It is faster to build, easier to maintain, and subject to existing governance controls.

Do you need custom transformation? If the integration requires complex data transformation, conditional logic, or multiple API calls, Azure Functions gives you the flexibility without the overhead of a full API.

Does the integration need to be versioned and governed as a first-class API? If the integration is a core part of the system architecture and needs versioning, rate limiting, caching, and comprehensive monitoring, build a custom API with API Management.

Does your organisation rely on DLP policies? If the DLP policy is the primary governance control, Logic Apps keeps the integration within the governance boundary. Azure Functions and custom APIs require compensating controls.

The decision is not binary. A mature integration architecture often uses all three approaches for different parts of the system. Logic Apps for the straightforward workflows, Azure Functions for the performance-critical paths, and custom APIs for the core integration contracts.

Where the binary breaks

The distinction between these approaches is not as clean as the table suggests.

Logic Apps can call Azure Functions through a connector, combining the visual designer with custom code. Azure Functions can use the Dataverse connector through the Power Platform SDK, gaining some of the connector benefits. Custom APIs can wrap Logic Apps, using the workflow engine as a backend service.

The composition is possible. The question is whether it is useful.

Adding Azure Functions to Logic Apps increases complexity without necessarily improving performance. The Logic App still adds overhead before and after the function call. If the function is the bottleneck, put the function in front of the workflow, not inside it.

Wrapping Logic Apps in a custom API gives you versioning and rate limiting but adds another layer to maintain. If the API is simple, the API Management features may be sufficient without the Logic App.

The rule is simple. Each layer should add value. If a layer merely passes data through, it is overhead.

The better question

The question is no longer which tool connects to Dataverse. They all do.

The better question is which layer should own the integration contract, the transformation logic, the error handling, and the governance boundary. The answer depends on the latency requirement, the complexity of the logic, the governance model, and the team's capacity to maintain the integration.

Logic Apps for straightforward workflows where latency is not critical. Azure Functions when performance matters and the logic is non-trivial. Custom APIs when the integration is a core architectural component that needs versioning, monitoring, and full control.

The integration is not a feature. It is a boundary, and boundaries need maintenance.

Sources and further reading

• Azure Logic Apps overview - Microsoft Learn. Documents the Logic Apps service, its plans, and its integration capabilities.
• Azure Functions overview - Microsoft Learn. Documents the Functions service, triggers, bindings, and hosting plans.
• Integration and automation platform options in Azure - Microsoft Learn. Official comparison of Logic Apps, Power Automate, and Azure Functions.
• Power Automate vs Logic Apps - Microsoft Learn. Documents the relationship between Power Automate and Logic Apps and when to use each.
• Dataverse Web API overview - Microsoft Learn. Documents the Web API for Dataverse, authentication, and supported operations.
• Custom connectors overview - Microsoft Learn. Documents how custom connectors work across Power Platform and Logic Apps.
• Power Platform licensing FAQs - Microsoft Learn. Confirms licensing requirements for Premium connectors and automation.
• Data Loss Prevention policies - Microsoft Learn. Documents DLP policy design and enforcement for Power Platform environments.
• Implement a data policy strategy - Microsoft Learn. Guidance on designing and implementing DLP strategies across environments.
• Comparing Azure Functions and Logic Apps performance - Independent analysis. Benchmarks showing the latency difference between stateful Logic Apps and Azure Functions.