Getting Started With the Azure Maps Visual in Power BI - What It Does Well and Where It Still Frustrates

Every Australian business that reports on anything geographic eventually hits the map question. Sales by state, deliveries by postcode, sites by region, customers by suburb. Someone wants it on a map, and the map they get is usually worse than they hoped. The older Power BI map visuals were passable for a coloured-in picture of Australia and not much beyond that. The Azure Maps visual is the answer to a lot of those old frustrations, and it is now the default map when you drop geographic data onto a report.

I have rebuilt enough client dashboards from the old maps to the Azure Maps visual to have opinions about where it is a genuine upgrade and where it still makes you work. So this is a get-started guide with the honest bits left in, rather than a feature tour. Microsoft's getting started documentation for the Azure Maps visual covers the setup steps. I want to cover what actually matters when you use it in anger.

What the Azure Maps visual actually is

The short version: Azure Maps is Microsoft's mapping platform, the same tiles and geocoding engine that sits behind a lot of Microsoft's location features, and the Power BI visual is a way to render your data on top of it. Where the old maps gave you a fairly flat plot-points-on-a-map experience, Azure Maps gives you proper layers. Bubbles, heat maps, filled regions, cluster grouping, reference layers, all sitting on a real interactive base map that you can style.

For most business reporting the practical difference is that it looks like a modern map instead of something from 2012, and it can show more than one kind of geographic story at once. You can have bubble sizes representing revenue while colour represents a category, on a base map that people can actually zoom and pan around sensibly.

Turning it on is the first thing to know. Depending on your tenant, the Azure Maps visual may need enabling at the admin level before it shows up properly, and geospatial features sometimes need a switch flipped in the admin portal. If yours is greyed out or acting like it has no rendering, that admin setting is the first place to look, not your data. I have watched people spend an afternoon debugging their data model when the actual problem was a tenant setting nobody had turned on.

Getting your first map on screen

The core workflow is refreshingly simple once the visual is available. You drop a geographic field into the Location bucket, latitude and longitude into their fields if you have them, and a measure into Size or into the bubble colour, and you have a map. The visual will geocode text locations for you, so "Brisbane" or a postcode becomes a point, without you needing coordinates in your data.

That geocoding is convenient and it is also where the first real friction shows up. Australian place names are not always unambiguous to a global geocoder. There are plenty of duplicated town names across states, and a bare suburb name can land in the wrong place. If you feed it "Richmond" with no other context, you are trusting the geocoder to pick the right Richmond, and it does not always pick the Melbourne one. The fix is to give it more to work with. A field categorised properly as State or Country, or a combined location string that includes the state, dramatically improves accuracy. If you have actual latitude and longitude, use them and skip the guessing entirely.

This is the single most common Azure Maps problem I see on client work: points landing in the wrong spot because the location data was ambiguous and the geocoder did its best with too little. The map looks broken. The data is fine. The location fields just were not specific enough. Categorising your geographic columns correctly in the data model, telling Power BI "this is a State, this is a Postcode", fixes most of it before it starts.

The layers are the actual point

If all you want is dots on a map, the Azure Maps visual is overkill and the old maps would have done. The reason to use it is the layers, and this is where it earns its place.

The bubble layer is the workhorse: points sized and coloured by your measures, with clustering so that a hundred overlapping points in Sydney collapse into a single readable cluster that expands as you zoom in. That clustering alone solves the classic problem of a map where every metro area is an unreadable blob of overlapping dots.

The heat map layer is good for density, showing where activity concentrates rather than individual points, which suits things like foot traffic, incident density, or where your customers actually are versus where you assumed they were.

The filled map, or choropleth, colours in regions, states, postcodes, defined areas, by a measure. This is the one people ask for most, "colour Australia by state sales", and it works well as long as your regions match boundaries the visual understands.

You can also add a reference layer, bringing in your own boundary data as GeoJSON, which is how you get maps of regions that are not standard, sales territories, delivery zones, franchise areas, drawn accurately instead of approximated. That capability is quietly one of the most useful things the visual can do and one of the least used, because it takes a bit of setup. When a client has custom territories, this is usually the feature that makes the map genuinely theirs.

Where it still frustrates

I like the Azure Maps visual and I still hit walls with it, so here is the honest list.

Performance with large point counts is real. Throw tens of thousands of individual points at it without clustering and it gets sluggish. Clustering and heat maps are the answer, but it means you sometimes cannot show every individual point the way a stakeholder pictures. Aggregate first, plot second.

Custom region boundaries are powerful but fiddly. Getting your own GeoJSON in, correctly projected, matching your data keys, is not a five-minute job. When it works it is excellent. Getting there involves more trial and error than the docs suggest.

Styling has limits. It is far more flexible than the old maps, but if you have a strict brand style guide and someone wants the map to match it exactly, you will find edges you cannot round off. It is a business map, not a cartography studio.

And the admin and licensing side occasionally surprises people. Azure Maps as a service has usage considerations at scale, and in a large deployment that is worth understanding up front rather than discovering later. For most single-report use it is a non-issue, but it is not zero, and a big rollout deserves a proper look before you commit.

How we approach maps on client work

When we build geographic reporting through our Power BI consulting engagements, the map is usually the last thing we build, not the first, and that order matters. The quality of a map is almost entirely determined by the quality of the location data underneath it. A beautiful Azure Maps visual sitting on top of ambiguous, uncategorised location fields is a beautiful way to be wrong. So we sort the geography in the model first, categorise the columns, resolve the ambiguous place names, get real coordinates where accuracy matters, and only then build the visual. The map is the easy part once the data knows where things are.

For clients with genuinely custom geography, delivery zones, service territories, mining tenements, catchment areas, the reference layer work is where the real value sits, and it is also where most people give up too early. Getting custom boundaries rendering correctly is worth the effort because it turns a generic map into one that actually reflects how the business is organised. This kind of location-heavy modelling often overlaps with the broader data platform work our Microsoft Fabric consultants do, since the map is only ever as good as the pipeline feeding it clean geographic data.

The short version

The Azure Maps visual is the right default for mapping in Power BI now, and it is a real step up from the old maps: proper layers, clustering that makes dense areas readable, heat maps, filled regions, and custom boundaries if you put the work in. Its weak spot is location data quality. Ambiguous place names geocode to the wrong place, and Australian names are especially prone to it, so categorise your geographic columns and use real coordinates where accuracy counts. Aggregate before plotting large point counts, and treat custom boundaries as a proper task rather than a quick tweak.

If your maps look great and land things in the wrong suburb, or you want custom territories rendered accurately instead of approximated, that is squarely the kind of work we do. Have a look at our services or get in touch and tell us what you are trying to put on the map.