Hello! Welcome to the fifth lesson in our module on Azure and Power Platform Integration Patterns.
Over the last four lessons, you've gained hands-on experience with several powerful integration technologies. We configured Azure Service Bus for asynchronous messaging, registered Webhooks for real-time notifications, developed C# Azure Functions for custom processing, and orchestrated workflows with Azure Logic Apps.
Now, we will synthesize this knowledge. Your learning outcome for this lesson is to choose an appropriate integration technology (Custom Connector, Webhook, Service Bus, Logic Apps) for a given scenario. This is a critical architectural skill that moves beyond implementation details and into solution design—a core competency for a senior Power Platform developer and a key topic for the PL-400 exam. We will establish a decision-making framework to help you confidently select the right tool for the job.
1. A Framework for Integration Decisions
When integrating with the Power Platform, the fundamental question is how to get data to and from external systems. Dataverse provides a rich set of eventing capabilities to communicate outwards.
To make an informed choice, we need a consistent set of criteria. Consider these factors for any integration scenario:
- Direction: Is data flowing out of Dataverse to an external system (outbound), or is a Power App/Flow calling an external API (inbound)?
- Synchronicity: Does the calling process need to wait for a response (synchronous), or can it fire off the request and continue without waiting (asynchronous)?
- Reliability: What happens if the receiving system is temporarily unavailable? Do you need guaranteed delivery, retries, and a dead-letter queue for failed messages?
- Orchestration vs. Notification: Is the goal to simply notify another system that something happened, or is it to kick off a multi-step business process involving several different services?
- Scale and Throughput: Are you dealing with a few events per hour or thousands per minute?
- Development & Maintenance: Who will build and maintain the integration? Does it require a pro-developer, or should it be accessible to a low-code maker?
Let's use this framework to analyze our options.
2. Outbound Integration Patterns: Pushing Data from Dataverse
Outbound integrations are triggered by an event within Dataverse, such as the creation, update, or deletion of a row. The goal is to inform an external system about this change. The primary technologies for this are Webhooks, Azure Service Bus, and using the Dataverse connector trigger in Power Automate or Logic Apps.
The following article from the Microsoft ISE Developer Blog provides an excellent comparison of these options from a data-export perspective.
Plugins in Dataverse - ISE Developer Blog
Please read the following sections from the article 'Plugins in Dataverse' to understand the different options for getting data out of Dataverse and how they compare on key parameters.
First, read the section 'Data Export Options' for a brief description of each technology (Logic Apps, Power Automate, Custom Azure-aware Plugins, Webhook Plugin, Service Bus Plugins). Then, carefully study the 'Comparison of Data-Export Options' section and the final 'Conclusion' paragraph. Focus on the trade-offs they highlight regarding scalability, complexity, and real-time processing.
Building on that article, let's crystallize the roles of our key technologies.
Webhooks
A webhook is a direct, lightweight HTTP call from Dataverse to an endpoint you specify.
- Ideal Scenario: Simple, real-time notifications to a custom API (like an Azure Function) that is highly available.
- Synchronicity: Can be configured as synchronous (up to 2 minutes) or asynchronous. A synchronous webhook makes the Dataverse operation wait for the endpoint to respond, which can be useful for external validation.
- Reliability: Lower. It's a point-to-point call. If your endpoint is down and the asynchronous webhook fails after its internal retries, the message is lost. There is no built-in dead-lettering mechanism.
- Choose Webhooks when: You need the fastest possible notification to a single, custom-built endpoint that you control, and you are prepared to handle reliability at the receiving end.
Azure Service Bus
Service Bus integration posts the Dataverse execution context as a message to a Service Bus Queue or Topic.
- Ideal Scenario: Decoupled, mission-critical enterprise integrations where guaranteed delivery is paramount.
- Synchronicity: Strictly asynchronous. The Dataverse transaction completes once the message is successfully handed off to Service Bus.
- Reliability: High. Service Bus provides durable messaging. If the downstream listener is offline, messages are safely stored in the queue. It supports retries, poison message handling, and dead-letter queues (DLQ), ensuring no data is lost.
- Choose Service Bus when: You cannot afford to lose a single event, the receiving system may not always be available, or you need to distribute an event to multiple independent subscribers (using a Topic). This is the canonical choice for decoupling Dataverse from other backend systems.
To deepen your understanding of Azure's messaging services, the following video explains the difference between Service Bus, Event Grid, and Event Hubs. For Dataverse integration, you'll most often choose between Service Bus (for reliable commands) and Event Grid (for reactive notifications), but it's good to know the whole landscape.
Compare Azure Messaging Services | How to Chose | Azure Service Bus vs Event Hub vs Event Grid
This video from Sri Gunnala explains the different Azure messaging services. Pay close attention to the distinction between 'commands' (for Service Bus) and 'facts/events' (for Event Grid).
Watch the sections explaining Commands/Service Bus (03:19 - 04:43), Discrete Facts/Event Grid (07:07 - 08:38), and the direct comparison between them (08:38 - 11:48). This will clarify why Service Bus is the go-to for reliable, transaction-like integrations from Dataverse.
Logic Apps / Power Automate
Here, the integration is a Logic App or Power Automate cloud flow that uses the Dataverse trigger "When a row is added, modified or deleted."
- Ideal Scenario: Automating a business process that involves coordinating multiple systems (e.g., Dataverse, SharePoint, Teams, SAP).
- Synchronicity: Asynchronous. The flow runs after the Dataverse transaction is committed.
- Reliability: Medium-High. The platform manages the trigger execution and provides robust retry policies for actions within the flow. You can inspect run history to see failures.
- Choose Logic Apps/Power Automate when: The primary task is orchestration, not just notification. If you need to apply business logic, call several different APIs, and perform actions based on conditions, a Logic App is a superior choice to writing a complex Azure Function to be triggered by a simple webhook. Given your background and the need for enterprise ALM, you would typically favor Azure Logic Apps over Power Automate for production integrations.
3. Inbound Integration Patterns: Calling External Services
Inbound integrations happen when a Power App user clicks a button, a Power Automate flow needs data from an external source, or an external system needs to push data into Dataverse.
Custom Connectors
A custom connector wraps an existing REST API, making it available as a set of pre-defined triggers and actions within Power Apps and Power Automate.
- Ideal Scenario: Empowering low-code makers to securely and easily use an external or internal API within their apps and flows.
- Direction: Acts as a proxy for outbound calls from an app/flow to an external API.
- Usefulness: Its primary value is reusability and abstracting away the complexities of HTTP requests and authentication. You define the API's operations, inputs, and outputs once, and any maker can then use it like any standard connector (e.g., SharePoint, Twitter).
- Choose Custom Connectors when: You have a specific API that needs to be consumed repeatedly across many different apps and flows within your organization. It's about packaging an API for easy consumption inside the Power Platform.
Logic Apps (HTTP Request Trigger)
A Logic App can also be configured to start with an HTTP Request trigger. This instantly exposes the entire workflow as a REST API endpoint.
- Ideal Scenario: Creating a simple, serverless API endpoint that orchestrates a complex backend process. It can be called from anywhere, including an external system.
- Direction: Can be used to create an endpoint for inbound calls into your Azure environment, which can then interact with Dataverse or any other service.
- Usefulness: This is a powerful way to create a facade. An external system can make a simple POST request to a Logic App endpoint, and the Logic App can then perform multiple steps: validate the data, create a record in Dataverse, send a notification, and log the transaction.
- Choose a Logic App with an HTTP trigger when: You need to provide a single API endpoint for an external system to call to initiate a business process. It's an excellent receiver for a webhook from another service.
4. Summary and Decision Matrix
To bring it all together, here is a decision matrix to guide your choice.
| Technology | Direction from Power Platform's perspective | Synchronicity | Reliability | Core Purpose | Key Phrase |
|---|---|---|---|---|---|
| Webhook | Outbound from Dataverse | Sync or Async | Point-to-Point | Notification | "Tell a single system something happened, right now." |
| Service Bus | Outbound from Dataverse | Asynchronous | Guaranteed Delivery | Decoupling | "Send a message reliably, even if the receiver is offline." |
| Logic App | Bidirectional | Asynchronous | High (Managed) | Orchestration | "Coordinate a multi-step process across different services." |
| Custom Connector | Inbound to External API | Sync or Async | Depends on API | Consumption | "Make an external API easy to use inside Power Apps and flows." |
Test your understanding!
You are tasked with designing four separate integrations. For each scenario, choose the single best technology from the list (Webhook, Service Bus, Logic App, Custom Connector) and briefly explain your reasoning based on the framework we've discussed.
Scenario 1: When a sales "Opportunity" is marked as "Won" in Dataverse, the order details must be sent to your company's proprietary, on-premise ERP system to generate a customer invoice. The ERP system has a nightly maintenance window where it is offline for one hour. Data loss is not acceptable.
Scenario 2: You are building a model-driven app for the customer service team. On the Case form, you need to add a button that, when clicked, calls a third-party weather API (based on the customer's address) and displays the current temperature. This functionality will be reused in several other apps.
Scenario 3: When a new "Account" record is created in Dataverse, a complex onboarding process must begin. This involves: 1) adding the customer to a mailing list in Mailchimp, 2) creating a new folder for them in SharePoint, and 3) assigning a welcome task to the account owner in Microsoft Planner.
Scenario 4: Your public-facing website has a "Contact Us" form. When a user submits this form, you need to perform a duplicate check in Dataverse. If a duplicate is found, the existing contact's record should be updated; otherwise, a new contact should be created. The website development team just wants a single REST endpoint they can call.
Show answer
Scenario 1: Azure Service Bus
- Reasoning: The key requirements are guaranteed delivery ("Data loss is not acceptable") and handling receiver downtime ("nightly maintenance window"). Service Bus is designed for this. It will queue the message from Dataverse and hold it safely until the on-prem ERP system is back online to process it.
Scenario 2: Custom Connector
- Reasoning: The integration is an inbound call from a Power App to an external API. The requirements for reusability ("reused in several other apps") and ease of use for the app maker make a Custom Connector the perfect fit. It abstracts the weather API into a simple action that can be called via Power Fx.
Scenario 3: Logic App (or Power Automate)
- Reasoning: The key word here is "process." This is not a simple notification; it's a multi-step orchestration involving several distinct services (Mailchimp, SharePoint, Planner). A Logic App is the ideal tool to visually design and manage this workflow.
Scenario 4: Logic App (with an HTTP Request trigger)
- Reasoning: You need to expose a single REST endpoint to an external system (the website). A Logic App with an HTTP trigger provides this endpoint and allows you to build the backend orchestration (duplicate check logic, create/update actions in Dataverse) without writing a full custom API from scratch.
Conclusion
You have now built a mental model for selecting the right integration tool within the Power Platform and Azure ecosystem. The choice is rarely about which technology is "best" in a vacuum, but which is most appropriate for the specific constraints of your scenario.
Key Takeaways:
- First, determine the direction of the integration: is it data leaving Dataverse (outbound) or calls being made to external systems (inbound)?
- For outbound events from Dataverse, choose Webhooks for simple, real-time notifications, Service Bus for reliable, decoupled messaging, and Logic Apps for process orchestration.
- For inbound calls from apps/flows, use a Custom Connector to make an external API reusable and easy to consume.
- To expose a workflow as an endpoint for an external system to call, use a Logic App with an HTTP trigger.
- Always consider the trade-offs between synchronicity, reliability, complexity, and scale.
What's Next?
Now that we've established what technologies to use for connecting systems, our next lesson will focus on how to do it securely and professionally. We will cover how to secure API calls between Power Platform and Azure using Azure AD app registrations and managed identities. This is a fundamental skill for building enterprise-grade, secure integrations.