Inbound data integration

Inbound data integration involves bringing external data into Microsoft Dataverse so that it's accessible to apps and cloud flows.

API

Microsoft Dataverse provides two web services for working with data and metadata: the Web API and the Organization Service.

The Dataverse Web API supports cross-platform development using RESTful methods and follows the OData (Open Data Protocol) 4.0 standard. This open standard enables integration across various programming languages, platforms, and devices.

All data operations through the Dataverse APIs are translated into messages processed by the platform's event framework. This supports automation scenarios using Power Automate cloud flows or classic workflows, and allows developers to add plug-ins for validation or custom business logic.

Event vs. batch

Solution architects should classify incoming data as event-driven or batch-based to determine appropriate integration patterns. The following diagram compares these two approaches:

Push pattern

When integrating with Dataverse, determine whether data will be pushed from external systems or pulled by Dataverse on demand.

In the push pattern, an external system sends data directly to Dataverse using the Web API. This requires the external system to understand the Dataverse data model and business logic.

Create an abstraction layer to manage external access to Dataverse tables. This approach helps isolate external systems from internal changes and supports the following methods:

• Event-based processing – Power Automate or Microsoft Azure Logic Apps can handle individual transactions triggered by events in source systems.
• Batch processing – Use tools like KingswaySoft or Azure Data Factory to handle large data transfers in batches.
• Microsoft Azure Functions – Abstract business logic into reusable Azure Functions for integration.
• Custom API – Build a custom API for external systems to interact with.

When designing integrations, consider using multithreading to reduce latency and manage service limits.

Pull pattern

Use the pull pattern when data is needed on demand, such as during real-time data augmentation scenarios. This approach retrieves data from external systems as needed when records are accessed in Dataverse.

Virtual entities are well-suited for pull scenarios where real-time access to external data is required without storing it in Dataverse.

Alternate keys

In Dataverse, rows are uniquely identified using a GUID. External systems typically need to store or retrieve this GUID, which can be inefficient.

Alternate keys allow external systems to read or write data without needing the Dataverse GUID, enabling more efficient integration. For example, if an external accounting system uses a unique alphanumeric account number, this field can be defined as an alternate key in Dataverse. This enables direct access to records using the external system’s identifier.

Upsert

Use the Upsert message to simplify integration logic when it's unclear whether a row already exists in Dataverse.

Instead of querying first and then choosing between Create or Update, you can send an Upsert message. When used with an alternate key, Dataverse will automatically determine whether to create a new row or update an existing one.

Custom APIs

Custom APIs allow you to define and expose grouped operations for external systems to consume as a single callable interface.

Create a custom API record in Dataverse to define the structure. A custom API can be a function (for read operations) or an action (for write operations). Plug-ins can be used to implement the API logic.

Azure Functions

Azure Functions allows developers to implement complex custom logic that can be reused across systems. They can be triggered via webhooks, wrapped in custom connectors, and accessed from other applications or services.

Use Azure Functions to push or pull data into Dataverse, or to create APIs with custom server-side logic. These APIs can be exposed securely through Microsoft Azure API Management.