Introduction

Completed

Solution architects are responsible for identifying integrations within and outside of Microsoft Power Platform and guiding how those integrations are implemented as part of the overall architecture.

This module introduces integration options in Microsoft Power Platform and explains the solution architect's role in planning and managing integrations. You'll also:

  • Learn about integration and why it's needed
  • Discover Microsoft Power Platform features that enable integration
  • Use the capabilities of Microsoft Azure

Business apps built on Microsoft Power Platform are often part of a broader enterprise ecosystem. From a user's perspective, the app connects to other enterprise systems and participates in larger business processes that span multiple systems.

Diagram showing that the app is part of a bigger picture.

Integration overview

Integration connects one or more system components to create a unified experience or ensure consistent process outcomes. It results in a system that operates as a cohesive whole rather than disconnected parts.

Consider integration as the stitching together of distinct systems to achieve broader functionality. Integration promotes data integrity, improved user adoption, and higher return on investment (ROI).

Components can be connected or disconnected, and integration involves determining how best to enable coordinated operation.

Why integration is necessary

Six common challenges often indicate a need for integration:

  • Usability – Users often interact with multiple systems to complete tasks. Integration can unify these experiences in a single interface, reducing training costs and improving consistency.
  • Volume – When dealing with large or frequently updated datasets, duplication can become inefficient. Integration enables direct access to shared data sources instead of relying on copies or migrations.
  • Real-time – Business processes often require immediate access to current customer data, which may reside in multiple systems. Integration allows real-time access to up-to-date data across teams or regulatory contexts.
  • Cost – Some functionality is more cost-effective when accessed externally. For example, integrating with an external address lookup service is often cheaper than maintaining postal data internally.
  • Duplication – Data consistency is critical. For example, assigning service resources without integration may lead to double-bookings. A centralized system that coordinates resource allocation can serve multiple business areas through integration.
  • Reuse – Rebuilding common functionality increases cost and maintenance. Integration supports reuse, which reduces development effort and improves consistency across solutions.

Types of integration

Integration typically occurs across three categories:

  • Data – Combines information from multiple sources to present a unified view.
  • Application – Connects systems at the application level to exchange data or services.
  • Process – Coordinates multiple systems to support end-to-end business processes.

Diagram showing the types of integration.

How solution architects can help

Solution architects contribute by:

  • Identifying where integration is required.
  • Leading the design of integration patterns and ensuring they align with the overall architecture.
  • Evaluating third-party integration tools.
  • Ensuring integration strategies are resilient and not overly fragile.
  • Incorporating integrations into the disaster recovery plan.

When evaluating integrations, solution architects must assess the cost of doing nothing. Before deciding to integrate data, applications, or processes, consider the cost of the current approach or manual alternatives. For example, determine how frequently a problem occurs and the potential value of automation. Some integrations may require significant effort but deliver minimal benefit—such as synchronizing only a few customer records daily after months of development.