Microsoft Dynamics 365 · Programmierung
Microsoft Dynamics 365 ist eine Plattform, kein Produkt. Wer „Microsoft Dynamics 365 Programmierung" sucht, meint meistens eines von fünf sehr unterschiedlichen Programmiermodellen — Dataverse-Plug-ins in C#, JavaScript-Client-API im Browser, Power Fx im Low-Code-Maker, AL für Business Central oder PCF Controls in TypeScript. Wir ordnen diese fünf Welten ein, zeigen, wann Programmierung statt Konfiguration die richtige Antwort ist, und legen unsere Pakete, Tagessätze und sechs typische Programmierungs-Fehler offen. Mit 20+ Jahren Microsoft-Praxis seit CRM 3.0.
Begriffs-Klarheit
Drei Begriffe werden im Markt durcheinandergeworfen — Customization, Configuration und Custom Development. Wer für ein Angebot vergleicht, sollte sie sauber trennen.
Configuration meint das, was Sie ohne Code-Editor erreichen — Tabellen anpassen, Forms gestalten, Business Rules definieren, Workflows bauen, Security Roles vergeben, Views konfigurieren. Wer in der modernen Power-Apps-Maker-Welt arbeitet, sieht Configuration auf den ersten Blick als „klickbar". Sie erzeugt Solution-Artefakte, die mit Dev-Test-Prod-ALM transportiert werden — aber kein Build, kein Compile.
Customization ist der Microsoft-Sammelbegriff für alle nicht-Standard-Anteile in einer Dynamics-365-Lösung. Im engeren Sinne meint er den Code-Anteil — Plug-ins, JavaScript, PCF Controls, Custom APIs, AL-Extensions. Im weiteren Sinne deckt er auch die strukturellen Anpassungen ab (Custom Entities, Custom Fields, Custom Workflows). Wir nutzen „Customization" im weiteren Microsoft-Sinn und sagen „Pro-Code-Komponenten", wenn wir konkret den Code-Anteil meinen.
Custom Development meint größere, oft eigenständige Software-Komponenten — etwa ein Power-Apps-Portal mit Custom Branding, eine Azure-Functions-Backend-Schicht für Drittsystem-Integration, eine native Mobile App oder ein eigenes Web-Front-end gegen Dataverse-Web-API. Custom Development ist die Brücke zwischen Plattform-Programmierung und freier Software-Entwicklung — und der Bereich, in dem unser Independent-Engineering-Team mit .NET, React und Node arbeitet.
Eine zweite Trennlinie verläuft zwischen den Modul-Welten: Customer Engagement (Sales, Customer Service, Field Service, Project Operations, Customer Insights) wird über Plug-ins in C#, JavaScript-Client-API, PCF Controls, Power Fx und Custom APIs erweitert — diese Welt läuft auf Dataverse. Business Central als SMB-ERP-App wird über AL-Extensions erweitert, eine eigene Sprache mit eigener Laufzeit und eigenem Compiler. Finance & Operations nutzt X++ und Extensions im Application Object Tree und ist eine dritte Welt, für die wir mit spezialisierten F&O-Partnern zusammenarbeiten.
Programmiermodelle
Wenn Sie nach „Dynamics 365 Programmierung" oder „Dynamics CRM Programmierung" suchen, meinen Sie eines dieser fünf Modelle. Sie unterscheiden sich in Sprache, Laufzeit, Einsatzort und Skill-Profil — und werden in der Regel kombiniert eingesetzt.
.NET · C# · Server-side
Server-seitige .NET-Komponenten in C#, die auf Pre-/Post-Operation-Events in der Dataverse-Pipeline reagieren — etwa „nach dem Speichern eines Accounts den Kreditrahmen neu berechnen". Eingesetzt in allen CE-Modulen (Sales, Customer Service, Field Service, Project Operations).
Skill-Profil: .NET-Tiefe, Dataverse-SDK, IPluginExecutionContext, sandboxed Plug-in-Limits (2 Minuten Laufzeit, 5 MB Outgoing).
JavaScript · TypeScript · Browser-side
Browser-seitige Logik in der Unified-Interface-Web-Form — Felder ein- oder ausblenden, Validierungen mit Dialog, Sub-Grid-Refreshes nach API-Calls. Web Resources werden über ALM in Solutions deployed und versioniert.
Skill-Profil: JavaScript ES6+, idealerweise TypeScript, Xrm.WebApi, Form Context Lifecycle, Async/Await-Patterns.
Low-Code · Deklarativ
Deklarative Formel-Sprache (Excel-ähnliche Syntax) für Canvas-Apps in Power Apps und Cloud-Flows in Power Automate. Power Fx ist Low-Code im Maker-Portal und Pro-Code in YAML-basierter Source-Control gleichzeitig.
Skill-Profil: Power Apps Canvas, Dataverse-Konnektor, Performance-Patterns für große Listen, ALM mit Managed Solutions.
AL · Pascal-ähnlich · ERP
Sprache für Business-Central-Extensions, Erbe der C/AL-Welt aus Navision. AL-Code läuft als versionierte Extension im Business-Central-Server (Cloud oder On-Premises), mit Symbol-Files, Translations und App-Manifest.
Skill-Profil: AL-Patterns, Business-Central-Server-Architektur, AL Code Analyzers, Translation Workflows, AppSource-Submission-Prozess für ISVs.
TypeScript · React · UI
PowerApps Component Framework — TypeScript-basierte Custom-Controls, die als ersetzte Felder oder Datasets in Model-Driven Apps und Canvas Apps eingesetzt werden. Etwa ein interaktives Gantt-Chart statt einer Sub-Grid-Liste oder ein eigener Color-Picker.
Skill-Profil: TypeScript, React (optional aber häufig), pac-cli, npm-Build-Toolchain, ManifestSchema, ControlContext-Lifecycle.
Azure · .NET · Custom APIs
Strenggenommen kein „Dynamics 365"-Programmiermodell — aber in der Praxis kaum trennbar. Komplexe Logik wandert in Azure Functions oder Dataverse Custom APIs, weil Plug-in-Limits (2 Min, 5 MB) sonst sprengen. Aufruf über Web-API, REST oder Service Bus.
Skill-Profil: .NET, Azure-Functions-Hosting, Service Bus, Application Insights, Managed Identity, OAuth gegen Dataverse.
Entscheidungs-Heuristik
Vor jeder Customization steht die Frage: Geht das auch ohne? Eine grobe Heuristik, die wir im Discovery-Spike nutzen, um die Anteile zu trennen.
| Anforderung | Konfiguration (No-Code) | Programmierung (Low- oder Pro-Code) |
|---|---|---|
| Formularlogik (Feld ein- oder ausblenden) | Business Rules | JavaScript-Client-API (wenn mehrere Bedingungen oder asynchrone Lookups) |
| Workflow-Automation | Power Automate Cloud-Flows | Dataverse-Plug-ins (wenn synchron oder transaktional) |
| Externe API anbinden | Power Automate-Konnektor (Standard-Konnektoren) | Azure Functions oder Custom Connector (wenn Auth-spezifisch oder hoch-frequent) |
| Komplexe Validierung | Business Rules für einfache Regeln | Plug-in oder JavaScript-Client-API (wenn Cross-Entity oder Aggregat-Prüfung) |
| Eigene UI-Komponente | Form-Designer mit Standard-Controls | PCF Control (wenn interaktives Element wie Gantt, Calendar, Map) |
| Berechnungslogik | Calculated & Rollup Columns | Plug-in (wenn Rollup-Limits oder Geschwindigkeit kritisch) |
Faustregel: Wenn Sie die Anforderung zu 80 Prozent im Standard abbilden, bleibt es bei Konfiguration. Sobald mehr als 20 Prozent als „aber bei uns ist das anders" durchscheinen, kommen Pro-Code-Komponenten ins Spiel. Im Discovery-Spike trennen wir die Anteile sauber — und vermeiden, dass Customization aus Gewohnheit entsteht statt aus Notwendigkeit.
Auswahl-Kriterien · anbieter-neutral
Diese Kriterien gelten unabhängig davon, ob Sie mit arades arbeiten oder mit einem anderen Microsoft Partner. Wer als „Dynamics-365-Entwickler" auftritt, sollte gegen alle sechs Kriterien antworten können — sonst entsteht ein einseitiges Skill-Profil mit Folgekosten.
01
Wie viele Plug-ins in Produktion? Wie viele Custom APIs? Wie tief sitzt das Verständnis für Dataverse-Sicherheit, Business Units, Hierarchical Security, Field-Level-Security? Wer auf diese Fragen ausweicht, hat selten unter Last gebaut.
02
Source-Control mit Azure DevOps oder GitHub, Managed Solutions in Test und Prod, Dev-Test-Prod-Umgebungen, Power Platform Build Tools für CI/CD. Wer ohne ALM-Pipeline arbeitet, baut Lösungen, die niemand außer dem Original-Entwickler weiterentwickeln kann.
03
Falls Business Central im Spiel ist oder ankommt: echte AL-Extension-Erfahrung, nicht nur C/AL-Erbe aus Navision. Symbol-Files, Translation Workflows, AppSource-Submission-Prozess für ISVs, Business-Central-Server-Architektur Cloud und On-Premises.
04
Wer Form-Logik in 2019er Patterns baut (var statt let, kein Promise.all, alte Xrm-Page-Notation), hinterlässt technische Schulden. ES6+, idealerweise TypeScript, Async/Await sauber im Form Context Lifecycle — das ist heute Mindeststandard.
05
Azure Functions, Service Bus, Application Insights, Managed Identity, OAuth gegen Dataverse — diese Skills sind notwendig, sobald Plug-in-Limits sprengen oder externe Systeme im Spiel sind. Custom Code in Dataverse allein reicht selten für ein produktives Mittelstands-Setup.
06
Tagessatz oder Festpreis-Sprint — beide Modelle sind legitim, aber sie sollten offen genannt werden. Wer auf die Frage „Was kostet das?" mit „kommt drauf an" antwortet und sich nicht auf eine Range einlässt, hat entweder kein Pricing-Modell oder fürchtet die Antwort.
Wo arades stark ist
Wir machen nicht alles gleich gut. Diese sechs Bereiche sind die, in denen wir aus tiefer Praxis arbeiten — mit eigenen Codebasen, dokumentierten Patterns und produktiven Mittelstands-Implementierungen im Rücken.
Server-seitige .NET-Komponenten für CE-Module. Tief in Pre- und Post-Operation-Pipelines, Plug-in-Steps mit Filtering Attributes, sauberer Trennung zwischen synchron und asynchron. Mit On-Premises-CRM-Historie zurück bis CRM 3.0, Migrations-Erfahrung in die Cloud.
TypeScript-basierte Custom-Visuals — Gantt-Components, Map-Components, eigene Sub-Grid-Renderer. Plus klassische Web Resources für Form-Logik. Wir trennen sauber, wo eine Web Resource reicht und wo ein PCF Control den Mehrwert rechtfertigt.
Power Fx in Canvas-Apps mit klaren Performance-Patterns, Custom Connectors für eigene REST-APIs, Solution-basiertes ALM mit Dev-Test-Prod-Pipeline. Wir setzen Low-Code dort ein, wo es trägt — und bauen Pro-Code-Backbone, wo es nicht trägt.
Extensions für Business Central Cloud und On-Premises. Eigene App-Manifest-Strukturen, Translation Workflows, AL Code Analyzer im CI. Für ISV-Vorhaben kennen wir den AppSource-Submission-Prozess aus eigener Praxis.
Wenn die Plattform-Programmierung an ihre Grenzen stößt, haben wir einen eigenen Stack im Rücken: .NET, Azure (App Service, Functions, Service Bus), React-Frontends, Node-Backends. So bauen wir Custom-APIs, Backend-Services und Spezial-UIs als saubere Erweiterung der Dynamics-365-Welt.
Quality-Gates, dokumentierte Test-Strategie, Code-Reviews mit Two-Eyes-Prinzip, definierte Definition-of-Done pro Sprint. Custom-Code-Lieferung als Process — nicht als „der Entwickler weiß schon, was er tut".
Pakete & Tagessätze
Vom 1-wöchigen Discovery-Spike bis zum mehrmonatigen Embedded-Developer-Retainer. Welche Form passt, hängt von der Klarheit der Anforderung und der gewünschten Geschwindigkeit ab — nicht vom Volumen allein.
1 Woche Festpreis. Anforderungs-Analyse, Architektur-Skizze, klickbarer Prototyp in der Zielumgebung, dokumentierter Aufwandsrahmen für den Folge-Sprint. Ideal, wenn die Anforderung noch unscharf ist — der Spike schärft sie.
4 Wochen Festpreis. Konkrete Customization-Lieferung — etwa drei Plug-ins, ein PCF Control, eine JavaScript-Schicht für ein Formular, eine Power-Automate-Integration. Mit Code-Review, Test-Strategie und ALM-Pipeline.
Monats-Retainer. Eine bis vier Entwickler:innen für drei bis zwölf Monate, eingebettet in Ihr Team oder als externes Squad. Geeignet für Roadmaps mit fortlaufendem Lieferbedarf — etwa beim Aufbau einer eigenen Branchen-Lösung auf Dataverse.
Konkrete Tagessätze nach dem 30-Minuten-Discovery — abhängig von Seniorität (Junior, Senior, Architekt) und Skill-Profil (Plug-in, PCF, AL).
Sechs typische Programmierungs-Fehler
Diese sechs Fehler treten in fast jedem Custom-Code-Bestand auf, den wir in einem Architektur-Review oder einer Knowledge-Recovery-Phase aufnehmen — bei Code von Drittpartnern und manchmal auch bei uns selbst aus früheren Jahren. Bewusst nennen statt verschweigen.
Direkter SQL-Zugriff auf die Dataverse-Datenbank, ungenehmigte DLL-Patches in der Plug-in-Sandbox, „undokumentierte, aber funktionierende" API-Aufrufe gegen Microsoft-interne Endpoints. Funktioniert — bis zur nächsten Release Wave. Microsoft toleriert diesen Bereich nicht, und Lift-and-Shift in die Cloud scheitert daran zuverlässig.
Plug-in im Pre-Operation-Step ruft eine externe API auf, die in 30 Sekunden antwortet (oder eben nicht). Das blockiert die Speichern-Transaktion des Users, sprengt die 2-Minuten-Grenze und führt zu Timeout-Fehlern bei jeder dritten Operation. Korrekt wäre: asynchron oder über Service-Bus-Queue mit Azure Function.
Im Plug-in steht „lookupOptionSetValue = 100000001" — die GUID oder der OptionSet-Wert eines Lookups direkt im Code. Das funktioniert in Dev, bricht in Test (andere GUID), bricht in Prod (wieder andere GUID). Korrekt wäre: Konfigurations-Entity mit Schema-Namen-Lookup oder FetchXML gegen eine Eindeutigkeits-Spalte.
JavaScript-Datei wird mehrfach gepatcht ohne Solution-Update, Browser-Cache liefert die alte Version, der User sieht ein zufälliges Mischbild. Korrekt wäre: Versionierter Solution-Import, Cache-Busting-Suffix bei jeder Änderung, idealerweise mit Build-Pipeline.
Eine Canvas-App, die in der Demo mit 50 Datensätzen flott läuft, dauert in Produktion mit 12.000 Datensätzen 18 Sekunden für den ersten Render. Power Fx hat klare Delegation-Limits — wer sie ignoriert, baut Apps, die im Demo funktionieren und in Produktion frieren. Korrekt: Delegation-Warnings ernst nehmen, Aggregat-Logik in Dataverse statt im Client.
Customization wird direkt in der Produktiv-Umgebung gemacht, „weil es schneller geht". Solutions sind unmanaged, niemand weiß, was wirklich produktiv ist. Bei einem Rollback ist die Lösung weg. Korrekt: Dev-Test-Prod-Umgebungen, Managed Solutions ab Test, Source-Control für alle Custom-Code-Bestandteile.
Qualifikation
Wir programmieren Dynamics 365 seit Microsoft CRM 3.0 (2005). Durch alle Plattform-Wechsel, alle Release-Wave-Umbenennungen, alle Lizenz-Modell-Anpassungen — und mit eigener Codebasis im Rücken. Unsere praxiserprobten Entwickler:innen arbeiten in Teams von zwei bis vier Personen mit gemischtem Skill-Profil, nicht als Vollstack-Einzelkämpfer:innen.
Häufige Fragen
Wir starten mit einem Discovery-Spike als Festpreis (1 Woche, ab 6.500 € netto). Daraus entsteht ein klickbarer Prototyp und ein realistischer Aufwandsrahmen. Ein Customization-Sprint über vier Wochen liegt als Festpreis ab 25.000 € netto. Längere Vorhaben fahren wir als Embedded-Developer-Retainer mit transparentem Monats- oder Tagessatz. Der konkrete Tagessatz hängt von Seniorität und Skill-Profil ab und wird nach dem Discovery-Gespräch genannt.
AL (Application Language) ist die Sprache für Business Central — die SMB-ERP-App in Dynamics 365. AL-Code läuft in Extensions im Business-Central-Server und ist Erbe der C/AL-Welt aus Navision. Plug-ins meinen meistens Dataverse-Plug-ins: server-seitige .NET-Komponenten in C#, die auf Pre-/Post-Events in den CE-Apps (Sales, Customer Service, Field Service, Project Operations) reagieren. Beide sind Pro-Code, beide werden mit Source-Control und ALM-Pipeline ausgeliefert — aber sie laufen auf zwei unterschiedlichen Laufzeit-Umgebungen.
Customer Engagement (Sales, Customer Service, Field Service, Project Operations) läuft auf Dataverse und wird über Plug-ins (.NET), JavaScript-Client-API, Power Fx, PCF Controls und Custom APIs erweitert. Finance & Operations nutzt X++, Extensions und das Visual Studio Application Object Tree — eine Welt, in der Sie eher die SCM- und Finance-Module anpassen. arades bedient den CE-Stack und Business Central selbst; für F&O-Custom-Code arbeiten wir mit spezialisierten F&O-Partnern aus unserem Netzwerk zusammen. Hintergrund im D365-ERP-Themen-Bereich.
Manches ja, manches nicht. Plug-ins, die supportet geschrieben wurden (kein direkter SQL-Zugriff, keine Impersonation außerhalb der Plug-in-Pipeline), lassen sich oft mit überschaubarem Aufwand auf Dataverse migrieren. JavaScript für Web-Forms und Web Resources ist auf der Unified Interface umzubauen. Klassische SSRS-Reports werden meist durch Power BI ersetzt. Wir prüfen den Custom-Code-Bestand in einem Discovery-Spike und liefern einen Migrations-Plan mit Re-Build-Quote, Lift-and-Shift-Quote und bewusst-nicht-migrieren-Quote.
Für Canvas-Apps und Power-Automate-Flows: ja, mit klaren Leitplanken. Wir setzen Power Fx in produktiven Mittelstands-Apps ein, achten aber auf vier Punkte — saubere Datenquellen-Architektur (vorzugsweise Dataverse), explizite Performance-Tests bei Listen über 2.000 Datensätzen, ALM-Pipeline mit Dev-Test-Prod-Solutions, und klare Trennung zwischen Citizen-Development und Pro-Code-Komponenten. Wo Power Fx an Performance- oder Komplexitäts-Grenzen stößt, bauen wir Custom APIs in Azure Functions als Backend.
Konfiguration meint das, was Sie im Maker-Portal ohne Code erreichen: Forms anpassen, Views definieren, Business Rules anlegen, einfache Workflows bauen, Security Roles vergeben. Customization meint Code: Plug-ins, JavaScript-Client-API, PCF Controls, Custom APIs, AL-Extensions. Faustregel — wenn Ihre Anforderung zu 80 Prozent oder mehr im Standard abbildbar ist, bleibt es bei Konfiguration. Sobald mehr als 20 Prozent als „aber bei uns ist das anders" durchscheint, kommen Pro-Code-Komponenten ins Spiel.
Wenn Ihr Prozess Standard ist, reicht Standard. Microsoft Dynamics 365 deckt sehr viel ab, und vieles, was vor zehn Jahren noch Custom-Code war, ist heute Konfiguration oder Power Fx. Externe Entwicklung lohnt, wenn Ihr Prozess Wettbewerbsvorteil ist (Branchen-Logik, eigene Berechnungsmodelle, integrierte Drittsysteme) oder wenn Sie mit alten Custom-Anteilen in der Cloud landen müssen. Im Discovery-Spike trennen wir, was Konfiguration wird und was wir tatsächlich coden.
Azure DevOps Repos oder GitHub für Source-Control, Power Platform Build Tools für Solution-Deployment, Azure Pipelines für CI/CD. Dev-Test-Prod-Umgebungen mit Managed Solutions in Test und Prod, Unmanaged in Dev. Für Business Central nutzen wir die offiziellen AL-Templates und das Microsoft-AL-Language-Extension-Toolchain. PCF Controls werden über npm-Build mit pac-cli verpackt. ALM ist bei uns kein Add-on, sondern Liefer-Grundlage.
Selten. Plug-in-Entwicklung in C# erfordert .NET-Tiefe und Dataverse-API-Verständnis. JavaScript-Client-API erfordert Front-end-Erfahrung im Unified-Interface-Lifecycle. AL für Business Central ist eine eigene Welt mit eigenen Patterns. PCF Controls sind TypeScript mit React-Anteilen. Power Fx ist deklarativ. Wir arbeiten in kleinen, gemischten Teams (typisch 2-4 Personen), die sich die Modelle teilen — die Vorstellung des „Vollstack-Dynamics-Entwicklers, der alles kann", ist Marketing-Märchen.
Wenn das, was Sie coden, ein Microsoft-Standard wäre, der Ihnen nur unbekannt ist. Wenn der Code synchrone Datenbank-Operationen in einem Plug-in macht, das auf eine externe API wartet. Wenn JavaScript Formular-Logik trägt, die auch eine Business Rule abbilden könnte. Wenn GUIDs hart codiert werden, statt sie über FetchXML zu beziehen. Wenn niemand außer dem Original-Entwickler den Code versteht. Vor jeder Customization steht bei uns die Frage: Geht das auch ohne?
Weiterführend
Die zugehörige Service-Page für die Lieferform: Discovery-Spike, Customization-Sprint und Application-Care. Mit Liefermodellen, Discovery-Logik und Übergang zu Application Care.
Bevor Sie programmieren lassen: Modul-Auswahl, Lizenz-Architektur und Roadmap. Discovery-Gespräch, Strategie-Workshop und Architektur-Review.
Vier Kategorien von Erweiterungen: AppSource-Marketplace, Custom Solutions, eigene Lösungen, Plug-ins. Vor der Custom-Entwicklung lohnt der Blick auf das, was bereits existiert.
Drei Einführungs-Pakete und das 4-Phasen-Modell (Discovery, Build, Migration und UAT, Hypercare). Programmierung ist meistens Teil der Build-Phase.
Nach Go-Live: planbarer Application-Care-Vertrag mit Monatspauschale für Custom-Code-Wartung, Releases und Erweiterungen.
Wenn die Plattform-Programmierung an ihre Grenzen stößt: eigener Stack mit .NET, Azure, React und Node — als saubere Erweiterung der Dynamics-365-Welt.
30 Min · kostenlos · ohne Verpflichtung
Erzählen Sie uns, was programmiert werden soll — eine Plug-in-Erweiterung, ein PCF Control, eine AL-Extension oder eine Power-Fx-App. Wir ordnen ein, schlagen das passende Programmiermodell vor und geben Ihnen eine erste Aufwands-Range. Bei Eignung Übergang in einen Discovery-Spike.
