Business Central: Extension oder Anpassung im Standard?

In Business Central lässt sich vieles ohne Programmierung anpassen: Seiten personalisieren, Rollen einrichten, Berichtslayouts ändern, Workflows konfigurieren. Eine Extension in AL braucht ihr erst, wenn neue Daten, neue Logik oder eine Anbindung an ein anderes System gefragt sind. Die Faustregel: Was der Standard über Einrichtung abbildet, bleibt im Standard. Was viele Firmen genauso brauchen, kauft ihr als AppSource-App. Nur was wirklich euer eigener Prozess ist, wird eine eigene Per-Tenant-Extension, sauber gebaut und nicht als Workaround.

Ich entwickle seit 2014 für Navision und Business Central und prüfe vor jeder neuen Extension, ob der Standard die Anforderung schon abdeckt. Dieser Artikel stellt die drei Wege für Microsoft Dynamics 365 Business Central gegenüber, also Anpassung im Standard, Per-Tenant-Extension (PTE) in AL und AppSource-App, mit Entscheidungstabelle und Folgen für Updates. Stand: Oktober 2026.

Extension, Anpassung im Standard oder AppSource-App: die drei Wege

Business Central lässt sich auf drei Wegen an euer Unternehmen anpassen: im Standard, mit einer eigenen Per-Tenant-Extension (PTE) oder mit einer fertigen App aus Microsoft AppSource. Die Wege schließen sich nicht aus, in vielen Systemen laufen alle drei nebeneinander.

Achtung beim Begriff „Customizing“: Im Business-Central-Umfeld meint er je nach Gesprächspartner die Einrichtung im Standard oder die Programmierung einer Extension. Klärt deshalb früh, welcher der drei Wege gemeint ist.

Anpassung im Standard: was ohne Programmierung geht

Im Standard ändert ihr, wie Business Central aussieht und wie vorhandene Funktionen eingerichtet sind, aber nicht, welche Daten es speichert oder welche Logik dahinter läuft. Das ist mehr, als viele denken.

Personalisierung und Anpassung von Seiten

Microsoft unterscheidet zwei Ebenen. Bei der Personalisierung richtet jeder Benutzer seine eigenen Seiten ein: Felder ein- und ausblenden, verschieben, Spalten fixieren. Bei der Anpassung für Profile macht ein Administrator dasselbe für eine Rolle, sodass alle Benutzer dieser Rolle die gleiche Oberfläche sehen. Dabei lassen sich laut Microsoft auch Felder anzeigen, die in der Tabelle existieren, aber nicht auf der Seite vorgesehen sind.

Einrichtung, Layouts und Workflows

Über die Einrichtungsseiten steuert ihr einen großen Teil der Geschäftslogik: Buchungsgruppen, Nummernserien, Mahnstufen, Lagerplatzlogik und vieles mehr. Berichts- und Dokumentlayouts könnt ihr in Word, Excel oder RDLC selbst anpassen, etwa für Rechnung oder Auftragsbestätigung. Genehmigungen und einfache Abläufe lassen sich über Workflows konfigurieren. Einen Überblick über alle Standard-Optionen gibt Microsoft unter Anpassen von Business Central.

Wo der Standard endet

Der Standard endet, sobald ihr etwas braucht, das in den Tabellen oder im Code von Business Central nicht vorgesehen ist. Typische Grenzen:

• Ein Feld, das es nicht gibt, etwa eine interne Klassifizierung am Artikel.
• Eine Regel, die BC nicht kennt, etwa eine Prüfung vor dem Buchen, die mehrere Bedingungen kombiniert.
• Automatischer Datenaustausch mit einem anderen System, etwa Shop, Versanddienstleister oder Payment-Anbieter.
• Ein Bericht, für den die Daten im Standard-Dataset fehlen. Das Layout könnt ihr ändern, das Dataset nicht.

Der Designer im Client ist dafür keine Dauerlösung. Microsoft beschreibt, dass der Designer nur in Sandbox-Umgebungen verfügbar ist und damit erstellte Erweiterungen beim Update der Sandbox entfernt werden. Für Produktivsysteme ist er also ein Werkzeug zum Ausprobieren, nicht zum Ausliefern.

Wann braucht ihr eine Per-Tenant-Extension?

Eine Per-Tenant-Extension braucht ihr, wenn eure Anforderung neue Daten, neue Logik oder eine Schnittstelle erfordert und es dafür keine passende fertige App gibt. Eine PTE ist eine in AL entwickelte App, die nur in eurem Mandanten installiert ist. Ihr bestimmt laut Microsoft selbst, wann sie veröffentlicht, installiert oder aktualisiert wird (Erweiterungstypen und Gültigkeitsbereich).

Technisch verändert eine Extension den Microsoft-Code nicht direkt. Sie ergänzt ihn:

1. Neue Felder an bestehenden Tabellen über Tabellenerweiterungen, zum Beispiel tableextension auf die Artikeltabelle.
2. Anzeige dieser Felder über Seitenerweiterungen.
3. Eigene Logik über Events: Die Extension abonniert definierte Ereignisse im Standard, etwa vor oder nach dem Buchen, und hängt sich dort ein.
4. Eigene Tabellen, Seiten, Berichte und Codeunits für alles, was im Standard gar nicht existiert.
5. Schnittstellen über APIs, Webservices oder eigene Codeunits. Mehr dazu im Artikel Business Central Schnittstellen: API und OData.

Beispiel: Ein Hersteller möchte Sendungen automatisch einer Versandklasse zuordnen, abhängig von Gewicht, Ziel und Artikelmerkmalen, und die Daten an einen Versanddienstleister übergeben. Das geht nicht über Einrichtung, weil es weder die Felder noch die Regel noch die Anbindung im Standard gibt. Genau so ein Fall war die Versandanbindung für einen Tierfutterhersteller. Wie diese Abwägung in der Fertigung aussieht, zeigt der Ratgeber Produktionssteuerung in Navision und Business Central.

Wie ich PTEs aufbaue, beschreibe ich auf der Seite AL-Extension-Entwicklung.

Wann ist eine AppSource-App die bessere Wahl?

Eine AppSource-App ist die bessere Wahl, wenn eure Anforderung nicht spezifisch für euer Unternehmen ist, sondern viele Firmen dasselbe Problem haben. Typisch sind Anbindungen an verbreitete Dienste, Dokumentenmanagement oder Branchenfunktionen. Dann hat jemand die Lösung oft schon gebaut, und ihr teilt euch die Entwicklungs- und Wartungskosten mit anderen Kunden.

AppSource-Apps durchlaufen eine technische Validierung durch Microsoft. Dazu gehören laut Checkliste unter anderem registrierte Präfixe bzw. Suffixe (Affixe) für Objektnamen und eigene Berechtigungssätze, sodass niemand SUPER-Rechte für die Nutzung braucht. Das sagt etwas über technische Mindeststandards aus, aber nichts darüber, ob die App euren Prozess wirklich abdeckt.

Worauf ich bei der Auswahl achte:

• Deckt die App den Prozess ohne Workarounds ab, oder nur teilweise und mit manueller Nacharbeit?
• Wie aktiv pflegt der Anbieter die App, und wie schnell ist sie nach einer neuen Hauptversion verfügbar?
• Lässt sich die App erweitern, wenn ihr später doch etwas Eigenes braucht? Das hängt davon ab, ob der Anbieter Events bereitstellt.
• Was kostet sie dauerhaft pro Benutzer oder Mandant im Vergleich zu einer einmaligen Entwicklung?

Entscheidungstabelle mit Beispielen

Die folgende Tabelle ordnet typische Anforderungen dem passenden Weg zu. Sie ersetzt keine Analyse eures Systems, zeigt aber, wie ich die Frage angehe.

Eure Anforderung passt in keine Zeile? Beschreibt sie mir im kostenlosen Erstgespräch in zwei Sätzen, ich sage euch, welcher Weg passt und warum.

Upgrade-Sicherheit, Kosten und Wartung im Vergleich

Der wichtigste Unterschied zwischen den Wegen liegt nicht in der Einführung, sondern im Betrieb über Jahre.

Upgrade-Sicherheit

Business Central Online erhält laut Microsoft zwei Hauptversionen pro Jahr, im April und Oktober, dazu monatliche Nebenversionen (Stand: Oktober 2026). Anpassungen im Standard laufen dabei einfach mit. Eine PTE muss dagegen zu jeder neuen Version passen. Gelingt das nicht, kann Microsoft inkompatible Extensions nach Ablauf der Update- und Kulanzfrist deinstallieren, damit das Update durchläuft. Die Daten der Extension bleiben laut Microsoft erhalten, die Funktion fehlt aber, bis eine kompatible Version installiert ist.

Wie upgrade-sicher eine PTE ist, hängt fast vollständig davon ab, wie sie gebaut wurde: ob sie nur dokumentierte Events nutzt, ob als veraltet markierte Objekte rechtzeitig ersetzt werden und ob vor jeder Hauptversion in einer Vorschau-Sandbox getestet wird. Was zu tun ist, wenn es doch knallt, steht im Artikel Extension nach Update nicht kompatibel. Bestehenden Code prüfe ich vorher in einem AL-Code-Review.

Kosten und Wartung

Eine PTE gehört euch, das ist Stärke und Pflicht zugleich. Achtet darauf, dass ihr den Quellcode bekommt, dass er in einer Versionsverwaltung liegt und dass ein anderer Entwickler ihn verstehen kann. Sonst hängt ihr an einer einzelnen Person oder einem einzelnen Partner.

So gehe ich bei der Entscheidung vor

Bevor ich eine Zeile AL schreibe, prüfe ich, ob es überhaupt Code braucht. Der Ablauf:

1. Anforderung als Prozess beschreiben, nicht als Lösung: Was soll am Ende passieren, wer macht es, wie oft?
2. Prüfen, ob der Standard das über Einrichtung, Profil, Layout oder Workflow abbildet.
3. Prüfen, ob es eine gepflegte AppSource-App gibt, die den Prozess ohne Umwege abdeckt.
4. Erst dann eine PTE planen, so klein wie möglich und nur über dokumentierte Erweiterungspunkte.
5. Aufwand und laufende Pflege offen gegenüberstellen, damit ihr eine echte Wahl habt.

Mehr zu Anpassungen, die ohne eigene Extension auskommen, findet ihr auf der Seite Business Central Customizing.

Häufige Fragen

Was ist der Unterschied zwischen einer Extension und einer Anpassung im Standard?

Eine Anpassung im Standard ändert nur, wie Business Central aussieht und wie vorhandene Funktionen eingerichtet sind, etwa per Personalisierung, Profil, Berichtslayout oder Workflow, und läuft bei Updates einfach mit. Eine Extension ist eine in AL entwickelte App, die neue Felder, Tabellen, Logik oder Schnittstellen ergänzt, ohne den Microsoft-Code zu verändern, und muss mit jeder Hauptversion kompatibel bleiben. Faustregel: Was sich per Einrichtung abbilden lässt, bleibt im Standard, neue Daten, neue Logik und Anbindungen brauchen eine Extension.

Kannst du prüfen, ob unsere bestehenden Anpassungen auch im Standard gingen?

Ja. Ich schaue mir eure Extensions an und prüfe pro Funktion, ob sie inzwischen durch Standardfunktionen oder Einrichtung ersetzbar ist. Jede Funktion, die ihr nicht selbst pflegen müsst, macht künftige Updates einfacher.

Ist eine Per-Tenant-Extension bei Updates riskanter als der Standard?

Ja, grundsätzlich schon, weil Microsoft nur den eigenen Code mit jeder Version testet. Eine sauber gebaute Extension, die ausschließlich dokumentierte Events und Erweiterungsobjekte nutzt und vor jeder Hauptversion in einer Vorschau-Sandbox getestet wird, ist bei Updates aber gut beherrschbar.

Können wir eine AppSource-App mit einer eigenen Extension erweitern?

Das geht, wenn der App-Anbieter die nötigen Erweiterungspunkte bereitstellt, also Events oder öffentliche Schnittstellen. Ob das der Fall ist, sollte man vor der Kaufentscheidung prüfen, nicht erst danach.

Was kostet eine kleine Extension bei dir?

Ich arbeite zum Festpreis oder nach Aufwand ab 120 € pro Stunde, ohne Jahresvertrag und ohne Mindestabnahme. Wie viel Aufwand eine Anforderung bedeutet, kläre ich im kostenlosen Erstgespräch, damit ihr vor dem Start wisst, woran ihr seid.

Gehört der Code einer Per-Tenant-Extension uns?

Das hängt vom Vertrag ab. Haltet bei jedem Entwickler und jedem Partner schriftlich fest, dass ihr den vollständigen Quellcode und die Nutzungsrechte bekommt, weil ihr sonst bei einem Wechsel nicht weiterentwickeln könnt.

Wann ich euch helfen kann

Wenn ihr vor einer konkreten Anforderung steht und nicht sicher seid, ob Standard, eigene Extension oder fertige App der richtige Weg ist, kläre ich das mit euch in einem kostenlosen 30-minütigen Erstgespräch. Das gilt auch, wenn ihr bestehende Anpassungen aufräumen oder upgrade-sicher machen wollt.

Erstgespräch buchen