Recommending Power Platform features for on-premises ERP integration

The core constraint is that data must remain within the existing ERP application due to privacy concerns. This explicitly rules out Dataverse (A), as Dataverse stores data in its own cloud-based database, which would violate the requirement for data residency. Similarly, Dataflows (E) are ETL tools designed to extract and load data into Dataverse or other destinations, making them incompatible with the 'data stays in ERP' rule. Power BI reports (C) are primarily for visualization and do not provide the read/write application interface requested.

The correct solution involves building a user interface that interacts directly with the source system without moving the data. Power Apps (D) provides the capability to build custom applications (such as Canvas Apps) that serve as the new web interface. To connect this app to the legacy SQL Server/ERP backend, you need a mechanism to communicate with it. Standard connectors might not support the outdated interface, so a Connector (B)—specifically a custom or On-premises Data Gateway-enabled connector—is required to bridge Power Apps with the on-premises SQL Server. This approach minimizes costs by leveraging existing infrastructure and ensures data privacy by keeping records in place.

This question tests the ability to distinguish between platform services based on data architecture constraints. The key trap is assuming Dataverse is always the default storage solution; however, when data sovereignty or specific integration needs dictate otherwise, direct connectivity via Connectors becomes necessary. Getting this wrong leads to solutions that either move data unnecessarily (increasing compliance risk) or fail to provide the required application functionality.