Use Power Apps' native geospatial controls first when they meet the requirement. They provide an interactive map, pins, routing and address input without embedding a Google key in a Power Fx formula. A Google Maps Static image remains possible, but the old pattern of concatenating an unrestricted key into every client request needs a security review.
Option 1: the native Power Apps map
The Power Apps geospatial controls include an interactive map and address input. A Power Platform administrator must enable the geospatial features for the environment, and the organisation must review the feature's data-sharing and terms.
Insert a Map control, then bind Items to a table with the expected latitude, longitude and label columns. The exact property names are documented in the Interactive map control reference.
Check delegation before binding a large remote table. Filter the records server-side where the connector supports it. A map can display only the rows that the app retrieves.
This option is normally easier to govern because it avoids a separate Google credential. It still needs environment enablement, licensing review, accessibility testing and a privacy decision about location data.
Option 2: a Google static map image
Google's Maps Static API returns an image from an HTTPS URL. It requires an API key and a billing-enabled Google Cloud project. Google also recommends a digital signature for Static API requests. See the current Maps Static API start guide.
In Power Apps, an Image control can display a URL returned by a trusted service. Set the control's Image property to:
varSignedMapUrl
The important part is where varSignedMapUrl comes from. For a production app, generate the signed, narrowly scoped URL on a trusted server or controlled flow rather than storing a signing secret in the canvas app.
Google's API security guidance recommends restricting keys by application and API, using separate keys for separate applications, monitoring usage and signing Static API URLs server-side. A signing secret must never be placed in client code.
Why the old formula is risky
A legacy formula often looked like this:
"https://maps.googleapis.com/maps/api/staticmap?center=" &
EncodeUrl(txtAddress.Text) &
"&zoom=14&size=600x400&key=" & varGoogleKey
It is simple, but the key is sent from the user's device and can be inspected. Website referrer restrictions may also behave differently in browsers, webviews and mobile clients. Do not describe that approach as secret or inherently secure.
If a limited prototype uses a client-visible key, use a separate project and key, restrict it to the required API and allowed application context, apply conservative quotas and alerts, and accept that the credential is visible. Do not reuse the key for server-side APIs.
Build a server-side URL service
A stronger design is:
- Power Apps sends a record ID or validated coordinates to an authenticated endpoint.
- The endpoint checks the caller and the requested location.
- It builds the allowed Static API request.
- It signs the URL using a secret stored outside source code.
- It returns only the signed image URL or the image response.
Do not let the client relay an arbitrary Google Maps request through the proxy. Allow only the parameters the app needs. Log failures without recording unnecessary precise location data.
Power Automate may be able to broker this pattern, but HTTP, custom connector and secret-store actions can affect licensing. Verify the current connector classification and service terms for the tenant rather than publishing a universal licence answer.
Privacy and accessibility
An address or pair of coordinates can identify a person, customer or sensitive site. Minimise what is sent, document the provider, set retention rules and obtain the necessary organisational approval.
A map image also needs a text alternative. Show the formatted address or location name outside the map and set an appropriate accessible label. Do not make a pin's colour the only way to convey status.
Test and recover
Test:
- blank and malformed coordinates
- an address with special characters
- a denied or rotated key
- quota or billing failure
- the provider being unreachable
- users without permission to see the location
- mobile and browser rendering
Show a useful fallback such as the address and a retry option. A rendered test map proves only that the selected request worked with the current keys, provider account and device. It does not prove future cost, availability or privacy compliance.
For more practical location patterns with the security boundaries kept visible, join the Power Apps Builders Space.