Power Apps: Stop Location Tracking

Key insights

• This video explains why a PowerApps form connected to a SharePoint list can prompt for your Location permission even when the column is plain text.
  It shows the surprising link between the column name and the permission request.
• The issue is not a Model-Driven App bug; it only happens in canvas forms tied to a SharePoint list.
  Recreating the form reproduces the prompt reliably.
• Behind the scenes, PowerApps or linked Power Automate flows can treat a field named "Location" as a geolocation trigger, which causes the browser location prompt to appear.
  This mapping, not data collection intent, drives the permission request.
• To stop the prompt, rename the column or change its type, remove location-dependent components, or disable related flows.
  You can also block site access in your browser/device permissions to prevent requests.
• Admins can limit or block apps that request sensitive data using the Power Platform admin center and app access control settings.
  These controls reduce unexpected permission prompts across an environment.
• Practical advice: test the form after renaming, check your browser settings, and remove unused location logic.
  Doing so avoids user confusion and reduces support tickets.

Summary of the video

In a recent YouTube video, author Alireza Aliabadi demonstrates an unexpected behavior in Power Apps forms that are connected to a SharePoint - Lists. Specifically, if a SharePoint column is named Location, the form may prompt users for location permission even when the column is just plain text. This surprising interaction is not present in Model-Driven App scenarios and appears tied to how the canvas form interprets certain field names and components. Consequently, the video aims to explain why this happens and how administrators and makers can avoid unnecessary permission prompts.

Reproducing the behavior

Aliabadi walks viewers through a clear reproduction of the issue by creating a simple SharePoint list with a text column named Location and then building a connected PowerApps form. After publishing the form and opening it in a browser, the app requests access to the device or browser location even though no explicit geolocation control was added to the form. The presenter verifies that the prompt disappears when the same field is used in other app types, which narrows the problem down to the canvas form plus SharePoint combination. As a result, developers can recreate the problem in their environments to test fixes and confirm the root cause.

Why the prompt appears

Behind the scenes, Aliabadi suggests that certain names and metadata can trigger built-in behaviors or component heuristics within the canvas form renderer, which then signals the host browser to request location permission. In other words, the issue looks less like deliberate data collection and more like an unintended mapping between field identifiers and client-side features that expect geolocation data. Moreover, this mapping can interact with Power Automate flows or embedded components that implicitly reference location capabilities, which further complicates diagnosis. Therefore, the field name becomes a key factor in whether the browser asks for permission.

How to stop the permission prompt

The video outlines several practical ways to stop or control the prompt. First, renaming the SharePoint column to avoid the exact string Location can prevent the form renderer from making the connection that triggers the permission request, though renaming may require updates to existing views and flows. Second, adjusting browser settings to block location access for the PowerApps domain stops the prompt for end users, but this approach risks breaking legitimate apps that need geolocation. Finally, administrators can use the Power Platform admin center to manage app access and environment-level controls, which helps reduce surprise prompts at scale while requiring careful governance to avoid disrupting valid application behavior.

Tradeoffs and operational challenges

Each mitigation comes with tradeoffs. For example, renaming a column is a quick fix, yet it can cascade into broken formulas, Power Automate flows, or integration points that expect the old name. Conversely, blocking location at the browser level protects privacy and reduces support tickets, but it also disables genuine location-based features that some teams rely on. In larger organizations, imposing strict controls via admin policies reduces individual risk but increases central overhead and may delay development. Consequently, teams must weigh the immediate user experience against the long-term maintenance and feature requirements.

Recommendations and next steps

Aliabadi recommends a measured approach: start by reproducing the issue in a test environment, then try a non-destructive solution such as renaming a copy of the column to confirm the behavior. If renaming is not viable, apply browser-based restrictions for troubleshooting and communicate the effects to end users so they can report any broken features. Lastly, document any changes and update flows or integration points as needed, and consider adding this scenario to governance checklists so future canvas forms avoid ambiguous field names. By combining testing, communication, and controlled governance, organizations can reduce surprise prompts while preserving needed functionality.

Keywords

PowerApps location permission, disable location PowerApps, stop PowerApps from accessing location, PowerApps location access settings, turn off location PowerApps, PowerApps geolocation privacy, block location access PowerApps, why PowerApps asks for location