GeoLocation in AL is possible, but not what you want?

If you poke around in Business Central, you might find a codeunit called GeoLocation. I Check out the video for what I found and let me know if you find a real use-case for this:

https://youtu.be/teNj-R3w95k

At some point in Business Central’s evolution, a Geolocation codeunit was added to the System App. When Erik first noticed it, he was excited — geolocation is the kind of thing that comes up frequently in customizations involving transport routing, customer locations, and distance calculations. But after digging in, he discovered that this codeunit might not actually do what most developers need. In this video, Erik demonstrates how the Geolocation codeunit works, what it actually returns, and why it may fall short of real-world requirements.

Using the Geolocation Codeunit in AL

The Geolocation codeunit lives in the System App and provides a straightforward API. You can set accuracy preferences, request a location, check status, and retrieve coordinates. Here’s a minimal example that Erik built as a page extension on the Customer List:

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage();
    var
        GeoLocation: Codeunit Geolocation;
        Lat, Long : Decimal;
    begin
        GeoLocation.SetHighAccuracy(true);
        if GeoLocation.RequestGeolocation() then begin
            GeoLocation.GetGeolocation(Lat, Long);
            Message('%1 %2', Lat, long);
        end;
    end;
}

The flow is simple:

  1. Call SetHighAccuracy(true) to request the most precise location available.
  2. Call RequestGeolocation() — this triggers a browser prompt asking the user for permission to share their location.
  3. If the request succeeds, call GetGeolocation(Lat, Long) to retrieve the latitude and longitude.
  4. Display or use the coordinates as needed.

Important: HTTPS is Required

One gotcha that Erik calls out: this will not work over plain HTTP. If you’re using a default Docker connection with just http://, your browser will block the geolocation request. You need an HTTPS connection. Erik demonstrated this by publishing to a cloud sandbox rather than a local Docker container.

What It Actually Returns

When Erik ran the extension, the browser popped up a permission request, and after accepting it, he got back coordinates that correctly placed him in North Vancouver. So the codeunit works — it successfully retrieves the location of the current user via the browser’s Geolocation API.

And that’s where the problem lies.

The Location of the User vs. the Location of an Entity

This codeunit returns where the Business Central user is sitting. It does not geocode an address. It does not take a customer’s street address and return coordinates. It queries the browser, which in turn queries the device’s GPS, Wi-Fi positioning, or IP-based location.

In Erik’s experience, the business need for geolocation in ERP systems is almost always about entities — customers, vendors, job sites, warehouses — not the user themselves. Typical requirements include:

  • Feeding customer addresses to transport companies for route optimization
  • Calculating distances between locations
  • Plotting vendors or customers on a map
  • Looking up land parcels or lot numbers and getting coordinates back

For all of these, you need a geocoding service — something like the Bing Maps API, Google Maps Geocoding API, or OpenStreetMap’s Nominatim — where you send an address and get coordinates back. The Geolocation codeunit in Business Central does not provide this.

Where This Codeunit Could Be Useful

Erik did come up with one solid use case: geofenced time entry on the mobile client. Imagine a scenario where field workers use the Business Central phone app to log hours against jobs. You could set up a geofence around a job site and only allow time registration if the user’s device is within those boundaries. Some dedicated timesheet applications already offer this functionality, and it would be feasible to build with this codeunit.

Another edge case: a field rep visiting customers could tap a button to say “I’m at this customer right now” and capture their current coordinates to update the customer record. But even this is a niche scenario.

There’s also the complication of remote work — in a post-COVID world where many users work from home or connect through VPNs, the user’s physical location may not be meaningful or accurate for business purposes.

Conclusion

The Geolocation codeunit in Business Central is a neat piece of technology — it correctly retrieves the browser-based location of the current user and makes it available in AL code. But for the vast majority of real-world geolocation requirements in ERP — geocoding addresses, calculating routes, determining where your customers and vendors are — you’ll still need to integrate with external geocoding APIs like Bing Maps, Google Maps, or OpenStreetMap. The built-in codeunit solves a much narrower problem: knowing where your user is, not where your data points to.

Picture of hougaard

hougaard