AL Dependency and AppSource Apps

In this video, I talk about how to use objects from AppSource in a Per-Tenant-Extension (aka a customization).

Even though AppSource apps are distributed by Microsoft you can still use them as normal apps and use the objects within as normal objects (because they are).

https://youtu.be/4NSq0lj74Zc

This is a video in my series AL for beginners.

In this video, Erik walks through the process of taking AL dependencies on AppSource apps in Business Central. A developer asked how to reference a table from an AppSource app in Visual Studio Code — something that was trivially available back in the NAV days but requires explicit dependency management in the AL development workflow. Erik demonstrates the full process using a cloud sandbox, from configuring the launch settings to downloading symbols and writing code against an AppSource extension.

The Challenge: AppSource Apps Aren’t Automatically Available

In the old NAV world, all objects were always available to you. In AL, however, you need to explicitly declare dependencies on the apps you want to reference. This is especially important when working with AppSource apps, because:

  • You cannot use Docker images or local installations for AppSource apps
  • You must work against a cloud sandbox environment
  • Dependencies must be declared in your app.json before you can download the symbols

Setting Up Your Cloud Sandbox Connection

Before doing anything, Erik emphasizes a critical step: when working against a cloud sandbox, you need to specify the exact environment and tenant in your launch.json. Without this, you run the very real risk of deploying your app to the wrong sandbox. Make sure to update the environment name and add the tenant ID to the launch configuration.

Downloading Symbols — The Default Behavior

After running AL: Download Symbols, the default download gives you:

  • Base Application
  • System Application
  • System

That’s it. None of the other installed extensions — including AppSource apps — come along for the ride. To get symbols for additional apps, you need to explicitly add them as dependencies.

Adding Dependencies in app.json

To reference an AppSource app, you add it to the dependencies array in your app.json. Each dependency requires four properties: id, name, publisher, and version. You can find these values in the Extension Management page in Business Central.

Here’s the full app.json with dependencies on both the Microsoft Image Analyzer and the E Foqus SharePoint Connector:

{
  "id": "36233408-5186-4449-89eb-c56276181dfc",
  "name": "DependencyAppSource",
  "publisher": "Default publisher",
  "version": "1.0.0.0",
  "brief": "",
  "description": "",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "",
  "dependencies": [
    {
      "id": "63ca2fa4-4f03-4f2b-a480-172fef340d3f",
      "publisher": "Microsoft",
      "name": "System Application",
      "version": "16.0.0.0"
    },
    {
      "id": "437dbf0e-84ff-417a-965d-ed2bb9650972",
      "publisher": "Microsoft",
      "name": "Base Application",
      "version": "16.0.0.0"
    },
    {
      "id": "e868ad92-21b8-4e08-af2b-8975a8b06e04",
      "name": "Image Analyzer",
      "version": "16.5.0.0",
      "publisher": "Microsoft"
    },
    {
      "id": "23ebd065-b289-4a68-85e3-b8410e360157",
      "name": "SharePoint Connector",
      "version": "1.0.0.0",
      "publisher": "E Foqus Canada Inc."
    }
  ],
  "screenshots": [],
  "platform": "16.0.0.0",
  "idRanges": [
    {
      "from": 50100,
      "to": 50149
    }
  ],
  "contextSensitiveHelpUrl": "https://DependencyAppSource.com/help/",
  "showMyCode": true,
  "runtime": "5.0"
}

A few things to note about the version number: you don’t need to specify the exact build. For example, Erik specified 16.5.0.0 for the Image Analyzer, and the symbol download pulled in a specific build that satisfied that minimum version requirement. For the SharePoint Connector, specifying 1.0.0.0 effectively means “any version.”

All four fields (id, name, publisher, version) are required. Miss one and it won’t work.

Using AppSource App Objects in Your Code

Once the symbols are downloaded, you get full IntelliSense for the AppSource app’s public objects — tables, codeunits, pages, page extensions, and more. Here’s an example of calling the SharePoint Connector’s upload function from a page extension:

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage();
    var
        SP: Codeunit "SharePoint EFQ";
        InS: InStream;
        FileName: Text;
    begin
        SP.UploadFile('/shared documents/folder/', Ins, Filename);
    end;
}

Note the EFQ prefix on the codeunit name. When an ISV submits an app to AppSource, they’re required to apply a prefix or postfix to all their public object names. In E Foqus’s case, that prefix is EFQ.

What You Get in the Symbol Files

When you download symbols for an AppSource app, you’re only getting the public symbols — not the full source code. Erik notes that the SharePoint Connector symbols were about 13 KB and the Image Analyzer about 7 KB. These are lightweight files containing just the public interface: table definitions, codeunit procedure signatures, page structures, and so on.

This is enough to:

  • Write code that references the app’s objects
  • Get full IntelliSense and compilation support
  • Include the symbol files in a build pipeline for CI/CD

However, you cannot navigate into the source code of the AppSource app — you’re working against the interface only.

Practical Pattern: Extending AppSource App Functionality

Erik shares a practical pattern used at E Foqus. The SharePoint Connector inserts a fact box on many standard pages through page extensions (customer, vendor, employee, opportunity, campaign, etc.). Rather than modifying the AppSource app itself for specific customer needs, they take a dependency on their own AppSource app and create custom page extensions that insert the same SharePoint fact box into additional custom pages.

This means they use the exact same AppSource version of the app that every other customer gets — and then layer customizations on top through the standard dependency mechanism.

Deployment Considerations

There’s an important constraint to keep in mind: you can build your extension anywhere you have the symbol files, but you can only deploy it to an environment where the dependency app is actually installed. Since AppSource apps can only be installed on cloud sandboxes (unless the vendor also offers an on-premises version), this effectively means your extension that depends on an AppSource app is limited to cloud environments.

Summary

Taking dependencies on AppSource apps in Business Central is straightforward once you understand the process:

  1. Set up your launch.json to target the correct cloud sandbox and tenant
  2. Find the app’s ID, name, publisher, and version from the Extension Management page
  3. Add the dependency to the dependencies array in app.json
  4. Run AL: Download Symbols to pull the public symbols
  5. Use the app’s objects in your code with full IntelliSense support

Don’t be afraid to use AppSource apps this way. Good ISVs design their apps with extensibility in mind, providing events and public APIs so that other developers can integrate with them. It’s the intended pattern for building layered solutions in the Business Central ecosystem.

Picture of hougaard

hougaard