• If your Azure Databricks workspace uses private networking (like VNet injection or Private Link), Power Apps cannot connect to it by default due to restrictive network access.
• To allow Power Apps to reach your Databricks endpoint:
  • You need to set up VNet peering or Private Link between the Databricks virtual network and the one that Power Platform uses.
  • Make sure authentication is done using Microsoft Entra ID—either OAuth or a service principal.
  • Once network connectivity is enabled and the right authentication is configured, you can add the Databricks connection in Power Apps.
• If further restrictions exist (e.g., firewalls), you may need special components like an Azure Data Gateway, although this is more commonly documented for Power BI than Power Apps.

• The connector provides real-time data access by running queries on a Databricks SQL Warehouse, not by launching dedicated Spark clusters for each query.
• If the SQL Warehouse is already running, results are returned quickly (seconds).
• If the SQL Warehouse is paused or idle, the initial query after idling can take several minutes due to startup time. After it’s running, latency is minimal for subsequent queries.
• You can minimize these delays by keeping the SQL Warehouse always running (using configuration to disable or extend auto-pause), but this increases compute cost.

• For private networks: Ensure proper VNet peering/Private Link and use Entra ID authentication.
• For real-time: All queries execute via SQL Warehouse; no Spark clusters are started. Keeping the SQL Warehouse active avoids cold-start delays.

Hope this helps, Lou.