Run any local application from BC Web Client

In this video, I show how to create a protocol handler and be able to launch locally installed applications from the Microsoft Dynamics 365 Business Central web client.

https://youtu.be/5KLfAkrGilk

In this video, Erik demonstrates a technique for launching local applications from the Business Central web client using custom protocol handlers. This approach helps bridge the gap left when the Windows client was deprecated, restoring some ability to interact with locally installed software directly from AL code.

The Problem: Losing Local Application Access

One of the capabilities lost when Business Central moved away from the Windows client was the ability to easily interact with local applications installed on the user’s PC. While the web client is powerful, it runs in a browser sandbox that limits direct interaction with the local operating system. However, there are workarounds — and protocol handlers are one of the most practical options available.

Understanding Protocol Handlers

Protocol handlers are something you use every day, even if you don’t realize it. When you type a URL into your browser, there’s an implied protocol at work:

  • http:// or https:// tells the operating system to open the registered browser
  • zoommtg:// opens the Zoom application
  • Microsoft Teams links use a similar mechanism

The key insight is that you can type a URL with a protocol into the Windows Run dialog (Win+R), and Windows will figure out which application is registered to handle that protocol and pass along the parameters. This is exactly how Teams and Zoom meeting links work — when you click them in an email, the browser hands off to the locally installed application via a protocol handler.

The good news: creating your own custom protocol handler is not reserved for large software companies. Anyone can do it.

Creating a Custom Protocol Handler

Step 1: Register the Protocol in the Windows Registry

Open the Registry Editor (regedit) and navigate to HKEY_CLASSES_ROOT. Here you’ll find existing protocol handlers — for example, Zoom’s entries. To create your own, add a new key structure:

  • Create a key under HKEY_CLASSES_ROOT with your protocol name (e.g., runfrombc)
  • Mark it as a URL Protocol
  • Add the path: shell → open → command
  • Set the default value of command to your executable path, using %1 as a placeholder for the parameter that will be passed

Step 2: Create the Receiving Application

Erik demonstrates a minimal C# console application — just 16 lines of code — that receives and processes the protocol call:

using System;
using System.Web;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello Business Central");
        foreach (var arg in args)
        {
            Console.WriteLine(arg);
            var decoded = HttpUtility.UrlDecode(arg);
            Console.WriteLine($"Decoded: {decoded}");
            Console.WriteLine($"Parameter length: {arg.Length}");
            Console.WriteLine($"Decoded length: {decoded.Length}");
        }
        Console.ReadKey();
    }
}

This small executable writes out “Hello Business Central,” displays all parameters that were passed to it (URL-decoded), and waits for a keypress. The URL decoding step is important because the hyperlink call will URL-encode special characters (spaces become %20, etc.).

Step 3: Call It from AL Code in Business Central

On the Business Central side, the integration is surprisingly simple. You use the built-in Hyperlink procedure with your custom protocol:

pageextension 50100 CustomerListExt extends "Customer List"
{
    actions
    {
        addfirst(processing)
        {
            action(OpenExternal)
            {
                Caption = 'Open External';
                ApplicationArea = All;

                trigger OnAction()
                begin
                    Hyperlink('runfrombc:' + Rec.Name);
                end;
            }
        }
    }
}

When the user clicks the “Open External” action, the browser recognizes the runfrombc: protocol, prompts the user for permission, and then launches the registered local application with the customer name as a parameter.

Parameter Size Limitations

Erik conducted a live experiment to determine the practical limits of how much data can be passed through a protocol handler URL:

  • ~1,300 characters — works without issues
  • ~1,500 characters (decoded) — still works reliably
  • ~1,700 characters — fails; the receiving application doesn’t get called

The exact limit likely falls somewhere around 2,000 characters for the encoded URL (which translates to roughly 1,500–1,600 decoded characters). This is enough to pass identification data, record keys, or instructions — but not large datasets.

Practical Tips and Workarounds

Passing More Data

If you need to pass more data than the URL length limit allows, there are several strategies:

  • Web service callback: Pass enough information (like a record ID or authentication token) for the receiving application to construct a web service call back into Business Central to retrieve whatever data it needs.
  • Download folder trick: Use DownloadFromStream to save a file, then use the Hyperlink to launch your application. The receiving application can look in the user’s known Downloads folder to pick up the data file.

Security Considerations

Erik strongly recommends building your own small receiving application rather than pointing the protocol handler at cmd.exe. While using cmd.exe works as a proof of concept, it has significant drawbacks:

  • Parameter parsing is unreliable — you only get one parameter that includes the protocol prefix
  • It opens up potential security vulnerabilities since arbitrary commands could be injected

With a custom executable, you control the entire chain: you can validate all incoming parameters, decide exactly what actions to take, and prevent misuse.

Use Cases

This technique is particularly useful for scenarios like:

  • Printing to local label printers
  • Launching local utilities with context from Business Central
  • Interfacing with hardware devices connected to the user’s PC
  • Opening specialized local applications with relevant Business Central data pre-loaded

Summary

The key components for running local applications from the Business Central web client are:

  1. A registry entry that defines your custom protocol and points to your executable
  2. A receiving application (even a simple C# console app) that processes the incoming parameters
  3. A Hyperlink call in AL using your custom protocol prefix (e.g., runfrombc:)

While there are limitations — particularly around the amount of data you can pass (~1,500 decoded characters) and the browser permission prompt — this is a practical and accessible technique for bridging the gap between the Business Central web client and the local operating system. For scenarios requiring more data, consider having the local application call back into Business Central via web services, or use the download folder as an intermediary.

Picture of hougaard

hougaard