Power Platform
Power Platform liegt
nicht neben Dynamics.
Es liegt darunter.
Ihr Dynamics 365 speichert in Dataverse, seine Oberflächen sind model-driven Apps, seine Logik läuft über Flows, Plugins und PCF-Controls. Jede Anpassung an Dynamics ist Power-Platform-Arbeit. Seit 2013 arbeiten wir ausschließlich mit Dynamics 365 CE und kennen diese Plattform von der Konfiguration bis in die Dataverse-Pipeline. Die Frage ist nicht, ob Sie sie nutzen, sondern wie tief Sie hineingehen müssen.
- ausschließlich Dynamics 365 CE
- seit 2013ausschließlich Dynamics 365 CE
- Projekte
- > 50Projekte
- Unternehmen in Begleitung
- > 20Unternehmen in Begleitung
- Microsoft Solutions Partner
- 6+ JahreMicrosoft Solutions Partner
- KonfigurationStandard, keine eigene Technik
- Dataverse & model-drivenEigene Tabellen, geerbte Regeln
- Power AutomateFachliche Abläufe, überschaubar
- PCF-ControlEigene Oberfläche, eigene Pflege
- PluginCode in der Pipeline, Tests nötig
Pflegeaufwand steigt nach unten
Anlass
Drei Anlässe, aus denen Unternehmen bei uns anrufen.
Power Platform braucht es erst, wenn der Standard einen Prozess nachweislich nicht abdeckt. Jede eigene App ist Technik, die gepflegt werden muss. Deshalb beginnt jeder dieser drei Wege mit einer Prüfung, nicht mit einem Bau.
Der Standard endet
Ein Prozess bricht, und Konfiguration trägt ihn nicht
Eine Außendienst-App ohne Netz, eine Freigabestrecke über mehrere Abteilungen, ein Portal für Partner: Wenn eine echte Lücke bleibt, ist Power Platform der richtige Weg. Vorher prüfen wir, ob Konfiguration sie schließt.
Lücke belegen lassenDer Bestand wächst unkontrolliert
Apps und Flows sind da, die Übersicht fehlt
Sie haben Power Apps und Flows im Haus, wissen aber nicht mehr, welche noch laufen, welche Daten sie berühren und wer sie verantwortet. Wir ordnen den Bestand, bevor die nächste App dazukommt.
Bestand ordnenDie Anpassungen sind unklar
Niemand weiß, was die nächste Release-Welle trifft
Anpassungen sind über Jahre gewachsen. Wie nah sind sie am Standard, tragen sie kommende Releases, ist die Basis bereit für Copilot und KI? Genau das beantwortet unser Audit.
Standort klärenGebaute Fälle
Zwei Verbände, die auf dieser Plattform arbeiten.
Beide Fälle sind auf unserer Referenzen-Seite dokumentiert. Ansprechpartner auf Kundenseite nennen wir im Gespräch, Referenzkontakt auf Anfrage.
Power Automate
Medizinische Fachgesellschaft
Bei der DGVS laufen Power-Automate-Flows für Mitgliederlebenszyklus und Veranstaltungs-Logistik, angebunden an Dynamics 365 und die SharePoint-Dokumentenablage. Die Geschäftsstelle begleiten wir laufend mit Third-Level-Support und Weiterentwicklung.
Power Apps
Wissenschaftliche Dachorganisation
Eine Power App für 180+ Fachgesellschaften, dazu die passende Anpassung in Dynamics 365: Die jährliche Datenabfrage ist digitalisiert, statt in der Geschäftsstelle manuell zusammengetragen zu werden.
Die Entscheidung davor
Reicht Konfiguration, oder braucht es eine eigene Anwendung?
Diese Frage stellen wir vor jedem Bau, und wir beantworten sie auch dann mit Nein, wenn ein Projekt schon eine App im Kopf hat. Dynamics 365 kann konfiguriert mehr, als die meisten Projekte ausschöpfen.
Konfiguration reicht, wenn …
Kein neuer Pflegeaufwand
- Der Prozess lässt sich mit Feldern, Ansichten, Rollen und einem Geschäftsprozessfluss abbilden.
- Alle Beteiligten arbeiten ohnehin in Dynamics 365 und brauchen keine eigene Oberfläche.
- Was fehlt, ist eine Regel oder eine Sicht auf bestehende Daten, keine neue Anwendung.
Eine eigene Anwendung ist nötig, wenn …
Dann mit Governance und Plan
- Es bleibt eine echte Lücke, etwa eine Außendienst-App oder eine Freigabestrecke über mehrere Abteilungen.
- Menschen ohne Dynamics-Arbeitsplatz müssen Daten liefern, etwa Kunden oder Partner über ein Portal.
- Logik muss serverseitig greifen, bevor ein Datensatz gespeichert wird, oder direkt im Formular sitzen.
Und eine dritte Antwort gibt es auch: Für hohe Datenmengen, harte Transaktionssicherheit oder komplexe Fehlerbehandlung ist eine echte Integration die bessere Wahl als ein Flow. Wir sagen Ihnen, welcher Fall vorliegt, statt alles in Flows zu bauen, weil es zuerst schneller aussieht.
Werkzeuge
Die Werkzeuge, mit denen Dynamics selbst gebaut ist.
Von der eigenen Tabelle bis zum Plugin in der Dataverse-Pipeline. Was Sie brauchen, entscheidet der Prozess, nicht der Wunsch nach einer App.
01
Dataverse ist Ihr Dynamics
Dynamics 365 speichert Konten, Kontakte und Verkaufschancen in Dataverse. Eine eigene Tabelle daneben erbt dieselben Berechtigungen, dieselbe Protokollierung, dieselbe Dublettenprüfung. Keine zweite Datenwelt.
02
Model-driven Apps sind Dynamics-Oberflächen
Formulare, Ansichten, Geschäftsprozessflüsse und rollenbasierte Apps sind dasselbe Werkzeug, mit dem Dynamics selbst gebaut ist. Der Innendienst bekommt eine eigene App auf denselben Datensätzen, nicht ein zweites System.
03
Power Automate für Prozesslogik
Freigaben über Abteilungsgrenzen, Fristen, Dokumente aus Vorlagen, Benachrichtigungen an Vertretungen. Was vorher aus Zurufen und Kalendereinträgen bestand, läuft nachvollziehbar durch.
04
Plugins und PCF-Controls, wo Konfiguration endet
Serverseitige Logik in der Dataverse-Pipeline und eigene Steuerelemente direkt im Dynamics-Formular. Das ist echte Entwicklung mit Tests und Versionierung, nicht zusammengeklickt.
05
Canvas-Apps und Power Pages am Rand
Außendienst ohne Netz, Prüfprotokolle auf dem Tablet, ein Portal für Kunden oder Partner. Angebunden an dieselben Datensätze, die Ihr Vertrieb im CRM sieht.
06
Umgebungen und Lösungen statt Klicken in Produktion
Getrennte Umgebungen für Entwicklung, Test und Betrieb, Änderungen als versionierte Lösungen. Damit ist jede Anpassung nachvollziehbar und zurückrollbar.
Auswertung und Berichte stehen auf einer eigenen Seite: Power BI.
Reihenfolge
Governance kommt vor der ersten App.
Ohne Regeln führt Low-Code tatsächlich zu Wildwuchs. Genau deshalb beginnen wir hier und nicht mit dem Bau. Vier Dinge stehen, bevor die erste Anwendung entsteht.
- 01
Getrennte Umgebungen
Entwicklung und Produktion sind nicht dieselbe Umgebung. Sonst ist jede Änderung sofort im Betrieb.
- 02
Data-Loss-Prevention-Regeln
Welche Konnektoren zusammen in einem Flow stehen dürfen, entscheidet eine Regel, nicht der Zufall.
- 03
Benannte Verantwortliche pro Anwendung
Jede Anwendung hat einen Verantwortlichen mit Namen, nicht bloß einen Eintrag, wer sie erstellt hat.
- 04
Eine Liste, was überhaupt existiert
Ohne Inventar weiß nach zwei Jahren niemand mehr, welche der vierzig Apps noch benutzt wird.
So arbeiten wir
Wir verantworten die Erweiterung. Und wir bleiben.
Wir nehmen Sie an die Hand: In jeder Etappe führt der Spezialist, den sie braucht, und ein Ansprechpartner bleibt durchgehend derselbe.
Wer die Anwendungen später pflegt, klären wir vor dem Bau, nicht danach. Entweder übernimmt Ihr Team die Pflege, dann bauen wir so, dass das realistisch möglich ist. Oder wir bleiben in der Verantwortung, dann ist es Teil der laufenden Begleitung.
Prüfen
Lücke im Standard belegen
Welcher Prozess bricht heute, und woran genau? Wir prüfen zuerst, ob Konfiguration in Dynamics reicht. Meist reicht sie weiter, als das Projekt annimmt.
Federführung · Beratung
Entscheiden
Stufe der Erweiterungsleiter wählen
Konfiguration, Dataverse-Tabelle, Flow, PCF oder Plugin. Diese Entscheidung bestimmt die Pflegekosten der nächsten Jahre und wird deshalb bewusst getroffen, nicht nebenbei.
Federführung · Architektur
Bauen
Umsetzen in Lösungen und Umgebungen
Umsetzung in getrennten Umgebungen, ausgeliefert als versionierte Lösung. Serverseitige Logik mit Tests, Steuerelemente mit dokumentierten Abhängigkeiten.
Federführung · Entwicklung
Übergeben
Übergeben, was übergebbar ist
Ihr Team lernt, was es selbst konfigurieren kann. Was Entwicklung braucht, bleibt bei uns, und das sagen wir vorher statt hinterher.
Federführung · Adoption
Nachziehen · laufend
Erweiterungen gegen Releases prüfen
Zu jeder Release-Welle sehen wir nach, was sich an Ihren Anpassungen ändert, und räumen ab, was der Standard inzwischen selbst kann.
Federführung · Support & Betrieb
Wer entwickelt
Zwei, die in der Dataverse-Pipeline zu Hause sind.
Plugins, Schnittstellen und Flows sind bei ihnen Tagesgeschäft, nicht Produktdemo. Im Projekt arbeiten Sie direkt mit ihnen, ohne Account-Management dazwischen.
Pascal Hollmann
Senior Lead Dynamics 365 CE Developer & Architect
Bindeglied zwischen Fachabteilung und Entwicklung, verantwortet die Qualität komplexer technischer Lösungen.
Björn Jastrzab
Dynamics 365 Developer
Setzt Anforderungen mit modernen Entwicklungstools um und kommuniziert die Lösungen direkt mit dem Kunden.
Porträt KI-bearbeitet, wo keines vorliegt stehen Initialen. Hinweise zur Kennzeichnung
Haltung
Warum „Dynamics oder Power Platform" die falsche Frage ist.
Es ist dieselbe Plattform. Die Entscheidung lautet: auf welcher Stufe der Erweiterungsleiter löst man einen Prozess, und was kostet diese Stufe in der Pflege.
Die Erweiterungsleiter
Konfigurieren, erweitern, entwickeln. In dieser Reihenfolge.
Erst prüfen, was der Standard konfiguriert leistet. Dann Dataverse und model-driven Erweiterung. Dann Flows. Erst danach Plugin oder PCF. Jede Stufe kostet mehr Pflege als die vorige, deshalb wird keine übersprungen.
Erweitern, nicht danebenbauen
Eine Anwendung, die eigene Kundendaten hält, ist ein neues Silo.
Alles, was wir bauen, sitzt auf Dataverse und übernimmt Berechtigungen und Datenmodell von Dynamics. So bleibt ein Kundendatensatz auch dann eine Wahrheit, wenn vier Anwendungen darauf zugreifen.
Release-Wellen überleben
Microsoft liefert zweimal im Jahr, ob es passt oder nicht.
Wer tief erweitert, muss wissen, was die nächste Welle an seinen Anpassungen ändert. Wir prüfen Releases gegen Ihre Erweiterungen, statt zu warten, bis im Betrieb etwas nicht mehr geht.
Werkzeug · 15 min, ohne Anmeldung
Was ändert die nächste Release-Welle an Ihren Anpassungen?
Selbstcheck, bevor Microsoft ausliefert.
Häufige Fragen
Häufige Fragen zu Power Platform.
Wann braucht man Power Platform, wenn Dynamics 365 schon läuft?
Ist Low-Code nicht genau das, was zu Tool-Wildwuchs führt?
Was ist Dataverse und brauchen wir es separat?
Was unterscheidet Power Automate von klassischen Schnittstellen?
Lohnt sich Copilot Studio für eigene Agenten?
Wer pflegt die Anwendungen später?
Nächster Schritt
Bringen Sie uns den Prozess, wir sagen Ihnen die Stufe.
Ein Gespräch darüber, was in Ihrem Prozess wirklich fehlt. Wir sagen Ihnen, ob Konfiguration reicht oder ob es Dataverse, einen Flow oder echten Code braucht.