web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

Community site session details

Community site session details

Session Id :
Small and medium business | Business Central, N...
Suggested Answer

Securing AL Source Code for Per-Tenant Extensions in Business Central SaaS

(6) ShareShare
ReportReport
Posted on by 50

I am developing customizations in Microsoft Dynamics 365 Business Central (SaaS) using per-tenant extensions.

My current delivery approach is as follows:

  • ISV solutions are developed as AL extensions
  • The extension is packaged as a .app file
  • The .app file is provided directly to the customer
  • The customer installs the extension using Extension Management in a cloud-hosted Business Central environment
  • After installation, the Download Source option is disabled in Extension Management

Despite this, I have concerns regarding intellectual property and source code protection.

Even though the Download Source option is disabled in Business Central, when the .app file is distributed directly to the customer, it can still be accessed locally. Using development tools such as Visual Studio Code, the customer can inspect the symbols and metadata contained within the .app package.

I am aware that:

  • Runtime packages (-packageType Runtime) provide stronger source-code protection
  • Runtime packages are supported only for On-Premises deployments
  • Runtime packages are not supported for Business Central SaaS

Requirement

My objective is to:

  • Protect my AL source code
  • Deliver a per-tenant extension for Business Central SaaS
  • Allow customers to install and use the extension
  • Prevent access to, or reverse engineering of, the underlying AL source code

Questions

  1. Is there any supported mechanism to convert a .app file into a more secure/ binary format or protected format for Business Central SaaS, comparable to runtime packages?
  2. What is the recommended and supported approach for ISVs to protect AL source code when distributing per-tenant extensions in SaaS?
  3. Are there any Microsoft-recommended best practices or official guidance for IP protection in this scenario?
I have the same question (0)
  • Suggested answer
    Kamal Khakhkhar Profile Picture
    1,409 on at
    hii there,
    as per requirement you can assign these 3 policies allowDownloadingSource, includeSourceInSymbolFile, allowDebugging So if you wan to not share your logic you can assign allowDownloadingSource, includeSourceInSymbolFile false . through that source code is not able to flow while downloading . developer can check table and page fields only .
     
    If you found answer mark it answered.
    Thank You . 
    Kamal Khakhkhar.
  • Suggested answer
    Pallavi Phade Profile Picture
    4,335 on at
     
    Ensure you set below policies in app.json file at first primary check for your custom app. 
     
     
    If ISV is handled at Microsoft Marketplce as Transactable app then it is taken care by Microsoft. 
     
    Usually we deploy our apps in other tenants . Hence AL code is at our environment . I m not fully sure of code security .
     
     
    Warm Regards
    Pallavi Phade
    www.linkedin.com/in/pallaviphade131116
  • Suggested answer
    Assisted by AI
    Sumit Singh Profile Picture
    10,574 on at
     
    1) Can a SaaS .app be converted to a more secure/binary format (like runtime packages)?
    No. Runtime packages (which hide AL source) are supported only for on‑premises and not available for Business Central SaaS. [learn.microsoft.com]
    2) Recommended approach to protect AL source for per‑tenant SaaS
    • Use resourceExposurePolicy in app.json and keep all options false:
      allowDownloadingSource, allowDebugging, includeSourceInSymbolFile, and (if applicable) applyToDevExtension. This is Microsoft’s built‑in IP protection for SaaS packages. [learn.microsoft.com]
    • Do not distribute raw .app files broadly. Instead, deploy directly to the customer tenant (Partner Center / admin API / controlled PTE publish) and maintain distribution via your pipeline; customers can install/use but won’t have source access. (Community and docs consistently note .app files can be inspected; protection relies on policy + controlled distribution.) [community….namics.com], [simplanova.com]
    • Digitally sign your app and follow AppSource/PTE validation practices (even for private distribution) to avoid accidental exposure. [learn.microsoft.com]
    3) Microsoft‑recommended best practices / official guidance
    • IP protection = resource exposure policies (replacement for ShowMyCode)—Microsoft Learn is explicit that code is protected against downloading/debugging by default, and exposure can be controlled only via these settings. [learn.microsoft.com]
    • If you need stronger obfuscation, SaaS has no runtime equivalent; Microsoft’s guidance is to use the policies above and manage delivery through AppSource or controlled PTE publishing (no public file sharing). [learn.microsoft.com], [learn.microsoft.com]
    Bottom line:
    For BC SaaS PTEs, there’s no binary runtime package; protect IP via resourceExposurePolicy = all false, code signing, and controlled tenant publishing (avoid handing out .app files). [learn.microsoft.com], [learn.microsoft.com], [learn.microsoft.com]

     
  • Suggested answer
    TAHER Mehdi Profile Picture
    173 on at

    Short answers to your questions

    1) Can I convert a .app for SaaS into a more secure/binary format like runtime packages?
    No. Runtime packages (-packageType Runtime) exist only for on‑premises deployments; there is no supported runtime/binary packaging for Business Central SaaS.

    2) Recommended, supported approach to protect AL source when distributing PTEs on SaaS
    Use resource exposure policies to lock down source availability (debugging, download, symbols):
    "resourceExposurePolicy": {
      "allowDebugging": false,
      "allowDownloadingSource": false,
      "includeSourceInSymbolFile": false,
      "applyToDevExtension": true 
    }
    • allowDownloadingSource: false disables “Download Source” in Extension Management.
    • includeSourceInSymbolFile: false prevents embedding source in symbols (customers can still see metadata—object names/types/captions—but not your source).
    • allowDebugging: false blocks stepping into your code from dependent extensions.
     
    3) Microsoft‑recommended guidance
    Microsoft’s Learn articles explicitly describe IP protection for extensions via the resourceExposurePolicy (which supersedes showMyCode) and confirm the on‑prem‑only nature of runtime packages. They also emphasize keeping apps compatible and maintained, especially for AppSource/PTE lifecycle.
  • Suggested answer
    OussamaSabbouh Profile Picture
    6,628 on at
    Hello,
     
    There is no supported way in Business Central SaaS to ship a protected/binary extension like runtime packages. If you give a customer a .app file, you must assume it can be inspected. Microsoft’s recommended approach is not technical obfuscation, but distribution control (AppSource), moving sensitive logic to external services (Azure APIs), and legal/licensing enforcement. Runtime packages are on-prem only and will not come to SaaS.
     
    Regards,
    Oussama Sabbouh
  • Suggested answer
    YUN ZHU Profile Picture
    95,840 Super User 2025 Season 2 on at
    I think this need is related to the contracts you sign with your clients.
    For example, some of our clients include source code in their deliverables because they paid for its development.
    If our support is insufficient for them, they can hand over the support to another partner.
    This is the significance of PTE.
    If you want full protection, it is recommended that you submit to AppSource.
     
    Hope this helps.
    Thanks.
    ZHU

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

News and Announcements

Season of Giving Solutions is Here!

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1
OussamaSabbouh Profile Picture

OussamaSabbouh 1,594

#2
Khushbu Rajvi. Profile Picture

Khushbu Rajvi. 745 Super User 2025 Season 2

#3
Sumit Singh Profile Picture

Sumit Singh 530

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans