Bei Geschäftsprozessabläufen gibt es etwas, das in der Dokumentation erst erwähnt wird, nachdem Sie bereits einen Nachmittag verschwendet haben: Sie können keinen außerhalb einer Lösung erstellen. Die meisten Einsteiger stoßen auf dieses Hindernis, klicken sich durch Power Automate auf der Suche nach der richtigen Schaltfläche und vermuten, dass die Funktion defekt ist oder ihre Lizenz nicht stimmt. Beides trifft nicht zu. Der Workflow muss von Anfang an innerhalb einer Lösung liegen, Sicherheitsrollen müssen zugewiesen sein, bevor ihn jemand sehen kann, und er muss aktiviert werden, bevor er auf einem einzigen Datensatzformular erscheint. Lassen Sie auch nur einen dieser drei Schritte aus, wird die Prozessleiste einfach nicht angezeigt. Der Workflow existiert. Er ist nur unsichtbar und nutzlos.
Dieser Leitfaden erläutert die vollständige Abfolge – vom Öffnen einer Lösung bis zum Anzeigen der Prozessleiste in einem Testdatensatz – und behandelt die Einschränkungen und Bearbeitungsregeln, die nach dem Go-live wichtig sind.
Die drei Dinge, die einen neuen Workflow unbemerkt zunichtemachen
- Geschäftsprozessabläufe müssen im Lösungs-Explorer erstellt werden – außerhalb davon wird der Workflow nicht angezeigt.
- Entwurfs-Workflows sind für Benutzer unsichtbar; die Aktivierung ist erforderlich, nicht optional.
- Erforderliche Zwei-Optionen-Schritte akzeptieren nur Ja – ein falsch konfiguriertes Feld blockiert die zulässige Navigation zwischen Phasen.
- Feste Grenzen: 30 Phasen, 5 Tabellen, 10 Verzweigungsebenen – bei Überschreitung einer dieser Grenzen schlägt die Validierung bei der Aktivierung fehl.
Was Geschäftsprozessabläufe in Power Automate und Dynamics 365 tatsächlich leisten
Ein Geschäftsprozessablauf ist eine geführte Leiste mit Phasen und Schritten, die oben in einem Datensatzformular in Power Apps oder Dynamics 365 angezeigt wird. Seine Aufgabe ist einfach: Er stellt eine einheitliche Dateneingabe sicher, indem er Benutzer durch eine definierte Abfolge von Phasen führt, die jeweils Schritte enthalten, für die bestimmte Felder ausgefüllt werden müssen, bevor der Benutzer fortfahren kann.
Die Definition eines Geschäftsprozessablaufs ist hier wichtig, da diese Funktion leicht mit etwas verwechselt werden kann, das sie nicht ist. Ein Geschäftsprozessablauf steuert die Erfahrung in einem Datensatz: welche Phasen existieren, welche Felder in jeder Phase erforderlich sind und unter welchen Bedingungen der Workflow auf einen alternativen Pfad verzweigt. Er ersetzt weder Cloud-Workflows noch automatisierte Workflow-Logik. Ein Cloud-Workflow läuft im Hintergrund, wird ausgelöst und führt Aktionen aus. Ein Geschäftsprozessablauf ist das, was ein Benutzer in einem Formular sieht und durchläuft.
Geschäftsprozessabläufe sorgen für Konsistenz. Ohne einen solchen Ablauf tragen zwei Vertriebsmitarbeiter, die mit derselben Opportunity-Tabelle in Dynamics 365 arbeiten, unterschiedliche Felder in unterschiedlicher Reihenfolge aus, lassen Lücken und übermitteln Datensätze, auf die sich nachgelagerte Berichte nicht verlassen können. Mit einem aktivierten Ablauf sehen beide Mitarbeiter dieselbe Prozessleiste und dieselben erforderlichen Schritte. Der Workflow automatisiert die Arbeit nicht – er strukturiert sie.
Diese Abgrenzung zu Workflows ist in der Praxis wichtig. Sie können einen bedarfsgesteuerten Workflow an eine Phase eines Geschäftsprozessablaufs anhängen – dort treffen die beiden Funktionen aufeinander. Der Ablauf selbst löst jedoch keine Automatisierungen aus. Er leitet Menschen an. Der an eine Phase angehängte Workflow löst Automatisierungen aus. Behalten Sie diese beiden Dinge getrennt im Kopf, bevor Sie mit dem Erstellen beginnen.
Voraussetzungen vor dem Erstellen eines Geschäftsprozessablaufs
Bevor Sie den Designer öffnen, müssen drei Dinge vorhanden sein. Fehlt auch nur eines davon, entstehen verwirrende Ergebnisse, die wie Produktfehler aussehen, aber keine sind.
Die richtige Lizenz für den Zugriff auf Power Platform
Erforderlich ist ein Power Apps-Plan pro Benutzer, ein Power Automate-Plan pro Benutzer oder ein qualifizierender Dynamics 365-Plan. Geschäftsprozessabläufe sind nicht in allen Power Platform-Lizenzen enthalten. Wenn die Option in Ihrem Menü fehlt, prüfen Sie zunächst die Lizenz, bevor Sie von einem Berechtigungs- oder Konfigurationsproblem ausgehen.
Zugriff auf den Lösungs-Explorer – nicht auf Power Automate als eigenständige Anwendung
Hier verlieren die meisten Einsteiger Zeit. Die Möglichkeit, neue Geschäftsprozessabläufe zu erstellen, existiert außerhalb des Lösungs-Explorers nicht mehr in der Hauptoberfläche von Power Automate. Die Funktion wurde nicht entfernt – sie wurde verschoben. Sie müssen zu Power Apps navigieren, eine bestehende Lösung öffnen oder eine neue erstellen und den Workflow dort erstellen. Wenn Sie versuchen, die Option für Geschäftsprozessabläufe im linken Menü von Power Automate auszuwählen und sie sich nicht wie erwartet verhält, ist das der Grund.
Eine zugeordnete Tabelle, auf der der Workflow ausgeführt wird
Jeder Geschäftsprozessablauf muss mit einer Dataverse-Tabelle verknüpft sein, die früher in Dynamics 365 als Entität bezeichnet wurde. Die Tabelle bestimmt, für welche Datensätze die Prozessleiste angezeigt wird. Standardtabellen wie Lead, Opportunity oder Kontakt funktionieren sofort. Auch benutzerdefinierte Tabellen funktionieren, sie müssen jedoch bereits in Dataverse existieren, bevor Sie ihnen einen Workflow zuordnen können. Sie können nicht gleichzeitig den Workflow erstellen und die Tabelle anlegen.
So erstellen Sie einen Geschäftsprozessablauf Schritt für Schritt
Die vollständige Abfolge besteht aus fünf Phasen: Öffnen Sie eine Lösung und benennen Sie den Workflow, fügen Sie im Designer Phasen und Schritte hinzu, ergänzen Sie bei Bedarf Verzweigungen oder bedarfsgesteuerte Workflows, validieren und speichern Sie den Workflow und weisen Sie anschließend Sicherheitsrollen zu und aktivieren Sie ihn. Jede Phase ist erforderlich. Der häufigste Fehler besteht darin, die Aktivierung als optionalen Aufräumschritt zu behandeln, der erst nach Benutzertests erfolgen kann.
Öffnen Sie eine Lösung und benennen Sie den Workflow
Rufen Sie Power Apps (make.powerapps.com) auf, wählen Sie in der linken Navigation Lösungen und öffnen Sie die Lösung, in der der Workflow liegen soll. Wenn Sie eine neue Lösung erstellen, geben Sie ihr einen projektspezifischen Namen – Sie werden für Aktualisierungen darauf zurückkommen.
Wählen Sie innerhalb der Lösung Neu, dann Automatisierung und Prozess. Wählen Sie anschließend Geschäftsprozessablauf als Prozesstyp. Vergeben Sie einen eindeutigen Namen – dieser erscheint als Beschriftung in der Prozessleiste. Ein Name wie „Lead-Qualifizierungsprozess“ ist daher hilfreicher als „BPF-v2-Test“. Wählen Sie die Tabelle, auf der der Workflow ausgeführt wird, und bestätigen Sie die Auswahl.
Der Workflow wird im Entwurfsstatus innerhalb der Lösung erstellt. Der Designer öffnet sich automatisch. An diesem Punkt navigieren manche Personen weg, um etwas anderes anzusehen, und verlieren den Kontext dessen, was sie gerade erstellt haben. Tun Sie das nicht. Bleiben Sie im Designer und führen Sie die nächsten Schritte aus, bevor Sie zu anderen Tabs wechseln.
Die Erstellung außerhalb einer Lösung – beispielsweise indem Sie über die eigenständige Benutzeroberfläche von Power Automate ohne Lösungs-Explorer starten – ist der häufigste erste Fehler. Die Option erscheint möglicherweise nicht dort, wo Sie sie erwarten. Und falls der Workflow außerhalb einer Lösung erstellt wird, was in älteren Plattformversionen möglich war, wird seine spätere Verwaltung und Bereitstellung deutlich schwieriger. Beginnen Sie innerhalb der Lösung. Bleiben Sie innerhalb der Lösung.
Phasen und Schritte im Designer für Geschäftsprozessabläufe hinzufügen
Der Designer für Geschäftsprozessabläufe zeigt eine Arbeitsfläche mit einer standardmäßigen ersten Phase. Jede Phase steht für einen zentralen Abschnitt des Prozesses – etwa Qualifizieren, Entwickeln, Vorschlagen, Abschließen für einen klassischen Vertriebsablauf oder Eingang, Prüfung, Genehmigung, Abschluss für einen internen Anforderungsprozess.
Um eine Phase hinzuzufügen, ziehen Sie eine Phase-Komponente aus dem rechten Bereich auf die Arbeitsfläche. Geben Sie ihr im Eigenschaftenbereich einen aussagekräftigen Namen. Jede Phase im Prozess benötigt eine Kategorie, die typischerweise dem Namen der Phase entspricht, sowie eine Tabelle. Standardmäßig wird die Tabelle übernommen, die Sie beim Erstellen des Workflows ausgewählt haben. Bei Workflows mit mehreren Tabellen können verschiedene Phasen jedoch auf unterschiedliche zugehörige Tabellen verweisen.
Fügen Sie innerhalb jeder Phase Schritte hinzu. Ein Schritt wird einem bestimmten Feld im Datensatz zugeordnet. Wenn der Benutzer das Feld „Abschlussdatum“ ausfüllen soll, bevor er die Phase „Vorschlag“ verlassen kann, fügen Sie innerhalb dieser Phase einen Schritt hinzu, ordnen Sie ihm das Feld „Abschlussdatum“ zu und markieren Sie ihn als erforderlich. Der Benutzer kann erst zur nächsten Phase wechseln, wenn er das Feld ausgefüllt hat.
Ein Verhalten überrascht viele Teams: Erforderliche Schritte, die Zwei-Optionen-Feldern zugeordnet sind, also booleschen Ja/Nein-Feldern in Dynamics 365, akzeptieren nur Ja als erfüllenden Wert. Wenn das Feld auf Nein gesetzt ist, kann die Phase nicht weitergeführt werden. Das ist kein Fehler, sondern beabsichtigt. Es verursacht jedoch reale Probleme, wenn ein Zwei-Optionen-Feld berechtigterweise nur dann bedeutet, dass dieser Schritt abgeschlossen ist, wenn es auf Ja gesetzt wurde. Wenn Ihr Prozess einen Bestätigungsschritt wie „Vertrag eingegangen“ enthält, muss der Benutzer ihn auf Ja setzen, um fortzufahren. Die Einstellung auf Nein – selbst absichtlich – blockiert die Navigation und erzeugt eine verwirrende Fehlermeldung ohne klare Erklärung in der Benutzeroberfläche. Testen Sie jeden erforderlichen Zwei-Optionen-Schritt vor dem Go-live manuell.
Für die Designer-Arbeitsfläche gelten feste Grenzen: maximal 30 Phasen pro Prozess. Planen Sie Ihre Phasenstruktur vor dem Erstellen, nicht währenddessen. Einen Workflow mit mehr als 20 Phasen nachträglich umzustrukturieren, ist genau die Art Erfahrung, die deutlich formulierte interne Slack-Nachrichten hervorruft.
Verzweigungsbedingungen oder bedarfsgesteuerte Workflows hinzufügen
Mit Verzweigungen kann der Workflow abhängig von den Datensatzdaten einen anderen Prozesspfad nehmen. Wenn ein Geschäftswert einen Schwellenwert überschreitet, leiten Sie ihn an eine Freigabephase für Enterprise-Geschäfte weiter. Wenn der Kontotyp SMB lautet, überspringen Sie die Phase für die Rechtsprüfung. Um eine Verzweigung hinzuzufügen, wählen Sie eine Phase aus und definieren Sie die Wenn-dann-Logik über den Bedingungseditor im Eigenschaftenbereich.
Die Grenze für die Verzweigungstiefe liegt bei 10 Ebenen. In der Praxis profitieren Workflows, die mehr als 4 oder 5 Verzweigungsebenen benötigen, meist davon, in separate Workflows umgestaltet zu werden. Sicherheitsrollen steuern dann, welchen Workflow ein Benutzer sieht – mehr dazu in einem späteren Abschnitt.
Bedarfsgesteuerte Workflows können an bestimmte Phasen angehängt werden. Sie werden ausgelöst, wenn der Benutzer sie manuell innerhalb der Phase startet. Sie können außerdem Workflows für das Betreten oder Verlassen einer Phase anhängen, die automatisch ausgelöst werden, wenn der Benutzer eine Phase betritt oder verlässt. Hier verbirgt sich die häufigste Überraschung im Produktivbetrieb: Workflows beim Verlassen einer Phase werden in der letzten Phase nicht ausgelöst. Der Grund ist mechanisch: Ein Workflow beim Verlassen einer Phase wird ausgelöst, wenn ein Phasenwechsel stattfindet, und aus der letzten Phase gibt es keinen Übergang heraus. Der Workflow ist konfiguriert, er sieht korrekt aus, aber es passiert nichts, wenn der Benutzer die letzte Phase abschließt. Wenn bei Abschluss des Prozesses etwas ausgelöst werden soll, verwenden Sie einen Workflow beim Betreten einer Abschlussphase oder lösen Sie einen separaten Cloud-Workflow anhand einer Feldänderung aus, die während der letzten Phase gesetzt wird. Berücksichtigen Sie diese Einschränkung im Design, statt zu erwarten, dass die Plattform sie transparent behandelt.
Geschäftslogik, die über erforderliche Felder durchgesetzt wird, befindet sich in den Schritten. Geschäftsregeln, die das Verhalten von Datensätzen verändern, befinden sich in separaten Geschäftsregeln von Power Apps. Das sind unterschiedliche Funktionen. Sie zu verwechseln, erzeugt unnötige Komplexität.
Den Workflow validieren, Sicherheitsrollen zuweisen und aktivieren
Wenn Phasen, Schritte und Verzweigungen korrekt aussehen, wählen Sie im oberen Menü Validieren. Der Designer kennzeichnet alle strukturellen Probleme: nicht zugeordnete Schritte, ungültige Bedingungen und Verstöße gegen Plattformgrenzen. Beheben Sie jeden Fehler, bevor Sie speichern.
Speichern Sie den Workflow. Er befindet sich weiterhin im Entwurfsstatus. Entwurfs-Workflows sind für Benutzer unsichtbar. Das ist keine unverbindliche Empfehlung, sondern eine Plattformbeschränkung. Niemand sieht eine Instanz eines Geschäftsprozessablaufs im Entwurf bei irgendeinem Datensatz. Erst die Aktivierung sorgt dafür, dass die Prozessleiste erscheint.
Weisen Sie vor der Aktivierung Sicherheitsrollen zu. Dieser Schritt bestimmt, welche Benutzer die Prozessleiste sehen. Rufen Sie die Eigenschaften des Workflows auf und fügen Sie die relevanten Rollen hinzu: die Standardrolle für Geschäftsprozessabläufe oder benutzerdefinierte Rollen basierend auf der Reihenfolge der Geschäftsprozesse und den Benutzergruppen. Ein Workflow, der ohne Sicherheitsrollenzuweisungen aktiviert wird, wird entweder allen angezeigt, abhängig von den Mandanteneinstellungen, oder bleibt für die meisten Benutzer unsichtbar. Beide Ergebnisse sind für den Produktivbetrieb falsch.
Aktivieren Sie den Workflow anschließend. Sein Status ändert sich von Entwurf zu Aktiv. Öffnen Sie nun als Benutzer mit der zugewiesenen Sicherheitsrolle einen Datensatz in der zugehörigen Tabelle. Die Prozessleiste sollte oben im Formular erscheinen, wobei die erste Phase hervorgehoben und ihre Schritte sichtbar sind. Das ist das Signal „Es hat funktioniert“. Wenn die Leiste nicht erscheint, prüfen Sie zuerst den Aktivierungsstatus, dann die Sicherheitsrollenzuweisung und anschließend, ob die Tabelle des Datensatzes mit der dem Workflow zugeordneten Tabelle übereinstimmt.
📊 In der Praxis:
Öffnen Sie nach der Aktivierung einen Testdatensatz mit einem Konto, dem die zugewiesene Sicherheitsrolle gehört – nicht mit dem Administratorkonto, das den Workflow erstellt hat. Administratoren sehen gelegentlich Workflows, die reguläre Benutzer nicht sehen, weil Zugriffe auf Administratorebene die rollenbasierte Sichtbarkeit umgehen. Bestätigen Sie dies mit einem Benutzerkonto, bevor Sie dem Team mitteilen, dass alles bereit ist.
Plattformgrenzen, die Geschäftsprozessabläufe im Produktivbetrieb beeinträchtigen
Die meisten Geschäftsprozessabläufe, die nach dem Go-live scheitern, scheitern, weil jemand sie in einer Demoumgebung entworfen hat, ohne die Plattformgrenzen zu berücksichtigen. Diese Grenzen sind nicht versteckt – sie stehen in der Dokumentation –, aber Teams planen bei der ersten Konzeption selten gegen sie. Bis ein Workflow 32 Phasen oder eine sechste Tabelle benötigt, ist die Struktur bereits aufgebaut und das Gespräch über eine Neuarchitektur unerquicklich.
Die festen Grenzen für einen einzelnen Geschäftsprozess:
| Einschränkung | Grenze | Was passiert, wenn Sie sie erreichen |
|---|---|---|
| Phasen pro Prozess | 30 | Die Validierung schlägt fehl; der Workflow kann nicht aktiviert werden |
| Tabellen pro Workflow mit mehreren Tabellen | 5 | Es können keine weiteren zugehörigen Tabellen zum Workflow hinzugefügt werden |
| Verzweigungsebenen | 10 | Verzweigungsbedingungen können nicht tiefer verschachtelt werden |
| Geschäftsprozessabläufe pro Tabelle | Mehrere zulässig | Keine Grenze – dies ist eine Designoption |
Die Möglichkeit, mehrere Geschäftsprozessabläufe pro Tabelle zu verwenden, sollte separat verstanden werden. Einer einzelnen Dynamics 365-Tabelle können mehrere Geschäftsprozessabläufe zugeordnet sein. Das ist kein Workaround für das Erreichen der Phasengrenze, sondern eine bewusste Designfunktion. Ein Vertriebsteam kann beispielsweise einen Workflow für Enterprise-Opportunities und einen anderen für SMB-Opportunities haben, die beide auf der Opportunity-Tabelle laufen. Sicherheitsrollen steuern, welchen Workflow ein bestimmter Benutzer sieht. Das ist sowohl für das Design als auch für die Diskussion der Grenzen wichtig: Wenn ein einzelner Workflow sich 30 Phasen nähert, lautet die richtige Frage meist, ob daraus zwei Workflows für unterschiedliche Benutzergruppen werden sollten – nicht, ob sich die Phasengrenze erweitern lässt.
Das im vorherigen Abschnitt beschriebene Verhalten von Workflows in der letzten Phase gehört in dieselbe Kategorie von Produktionsrisiken. Workflows beim Verlassen der letzten Phase werden nicht ausgelöst. Das ist ein Plattformverhalten, kein Konfigurationsfehler, und es erscheint nicht in der grundlegenden Validierung. Teams entdecken es nach dem Go-live, wenn die nachgelagerte Aktion, die sie beim Abschluss des Prozesses erwartet haben, einfach nie stattfindet. Die Dokumentation von Dynamics 365 zu Geschäftsprozessabläufen weist auf dieses Verhalten hin, aber beim ersten Aufbau und Testen wird es regelmäßig übersehen.
Geschäftsprozessmodellierung, die diese Grenzen ignoriert, erzeugt Workflows, die isoliert funktionieren, aber bei der Aktivierung oder in Sonderfällen der realen Nutzung scheitern. Berücksichtigen Sie die Grenzen vom ersten Tag an und nicht erst als abschließende Prüfung.
So bearbeiten Sie einen Geschäftsprozessablauf, ohne aktive Datensätze zu beeinträchtigen
Die Bearbeitung eines Geschäftsprozessablaufs nach der Aktivierung ist eine häufige Verwaltungsaufgabe, die reale Risiken birgt, wenn falsche Änderungen an Datensätzen vorgenommen werden, die sich bereits im Prozess befinden. Dieser Abschnitt richtet sich an Personen, die einen von jemand anderem erstellten Workflow übernommen haben und ihn verbessern müssen, ohne ihn zu verschlechtern.
Sichere Änderungen gegenüber Änderungen, die aktive Instanzen betreffen
Einige Änderungen können sicher vorgenommen werden, ohne Datensätze zu beeinträchtigen, die sich gerade im Prozess befinden. Das Hinzufügen einer neuen Phase am Ende des Workflows stört beispielsweise keine Datensätze, die sich bereits in Phase 3 befinden. Das Hinzufügen eines optionalen Schritts zu einer bestehenden Phase beeinträchtigt aktive Instanzen in der Regel nicht. Die Aktualisierung von Phasennamen oder Beschreibungen ist kosmetisch und beeinflusst weder Daten noch Navigation.
Prozessänderungen, die Datensätze im laufenden Prozess betreffen, sind riskanter:
Entfernen einer Phase, in der sich aktive Datensätze gerade befinden
Datensätze in der Mitte eines Workflows, die auf eine gelöschte Phase verweisen, können in einen inkonsistenten Zustand geraten. Benutzer sehen möglicherweise unerwartetes Verhalten in der Prozessleiste.
Bisher optionale Schritte als erforderlich festlegen
Datensätze, die diese Phase bereits passiert haben, sind unproblematisch. Datensätze, die sich aktuell in dieser Phase befinden, können blockiert werden, wenn das Feld leer ist und der Benutzer fortfahren möchte.
Ändern der Tabellenzuordnung
Dies beeinträchtigt fast immer aktive Instanzen von Geschäftsprozessabläufen in bestehenden Datensätzen. Vermeiden Sie diese Änderung im Produktivbetrieb ohne Migrationsplan.
Bei wesentlichen strukturellen Änderungen – etwa beim Umordnen von Phasen, beim Entfernen von Phasen mit aktiven Datensätzen oder beim Ändern von Feldzuordnungen – ist es sicherer, eine neue Workflow-Version zu erstellen, sie mit neuen Datensätzen zu testen und Tools für das Geschäftsprozessmanagement zu verwenden, um aktive Instanzen dem neuen Workflow zuzuordnen, bevor Sie den alten deaktivieren. Das dauert länger als die direkte Bearbeitung des Live-Workflows, verhindert aber die Art halb defekter Datensatzstatus, die eine Woche lang Support-Tickets erzeugen.
In der Praxis sieht die Verbesserung von Geschäftsprozessen fast immer so aus: Jemand übernimmt einen Workflow, nimmt eine kleine Änderung vor und verbringt anschließend zwei Stunden damit, einer Teamleitung zu erklären, warum nun 40 Datensätze in einer Phase festhängen, die nicht mehr existiert. Die zusätzlichen 30 Minuten für eine ordnungsgemäße Versionsmigration lohnen sich jedes einzelne Mal.
Effiziente Verwaltung mehrerer Geschäftsprozessabläufe in einer Tabelle
Wenn für dieselbe Tabelle mehrere Geschäftsprozessabläufe verfügbar sind, bestimmen Sicherheitsrollen, welchen Workflow ein bestimmter Benutzer sieht. Ein Benutzer mit der Rolle Enterprise Sales sieht möglicherweise den Enterprise-Opportunity-Prozess. Ein Benutzer mit der Rolle SMB Sales sieht den SMB-Opportunity-Prozess. Beide Workflows sind derselben Opportunity-Tabelle zugeordnet. Keiner der Benutzer sieht den Workflow des anderen.
Um den Standard-Geschäftsprozessablauf für eine Tabelle festzulegen, rufen Sie den Workflow auf und verwenden Sie die Einstellung „Reihenfolge“ in den Prozesseigenschaften. Damit steuern Sie, welcher Workflow Vorrang hat, wenn ein Benutzer auf mehr als einen zugreifen kann. Der Workflow mit der höchsten Priorität in der Reihenfolge wird standardmäßig angezeigt; Benutzer können manuell aus dem Datensatz zu einem anderen verfügbaren Workflow wechseln, wenn ihre Rolle dies zulässt.
Das ist eine nützliche Verwaltungsentscheidung und nicht nur eine Designoption. Ein benutzerdefinierter Geschäftsprozessablauf für ein bestimmtes Teamsegment hält die Prozessleiste für dieses Team übersichtlich und relevant, ohne bedingte Logik in einen einzigen riesigen Workflow einzubauen. Der Kompromiss ist der Wartungsaufwand: Jeder Workflow benötigt eigene Sicherheitsrollenzuweisungen und eine eigene Aktivierungsverwaltung. Zwei Workflows sind überschaubar. Sechs Workflows in einer Tabelle sind ein Governance-Thema, das Sie besprechen sollten, bevor Sie sie erstellen.
Häufige Fehler bei der Verwendung von Geschäftsprozessabläufen in Power Automate
In Support-Threads zu Geschäftsprozessabläufen sehe ich immer wieder dieselben vier Muster. Keines davon sind Plattformfehler. Alle sind behebbare Konfigurationsfehler, die wie Plattformfehler aussehen, bis Sie wissen, worauf Sie achten müssen.
Fehler 1: Erstellung außerhalb des Lösungs-Explorers. Die Einrichtung sieht zunächst funktionierend aus – ein Workflow wird erstellt, der Designer öffnet sich, Phasen werden hinzugefügt. Dann verschwindet der Workflow aus den erwarteten Menüs, kann nicht in andere Umgebungen bereitgestellt und nicht korrekt verwaltet werden. Der Menüpfad zum Automatisieren eines Geschäftsprozessablaufs außerhalb des Lösungs-Explorers unterstützt die vollständige Erstellung und Verwaltung von Workflows nicht mehr. Wenn Sie sich dabei ertappen, den Workflow hier erstellen zu wollen, halten Sie an, öffnen Sie den Lösungs-Explorer und beginnen Sie erneut. Zehn Minuten jetzt sparen Ihnen später einen Nachmittag.
Fehler 2: Die Aktivierung vergessen. Entwurfs-Workflows sehen vollständig aus. Der Designer zeigt alle Phasen korrekt an. Die Validierung ist erfolgreich. Wenn jedoch ein Teammitglied einen Datensatz öffnet und meldet, dass die Prozessleiste nicht angezeigt wird, lautet die erste Frage immer: Haben Sie ihn aktiviert? In einem beträchtlichen Teil der Fälle lautet die Antwort nein. Die Aktivierung ist kein abschließender kosmetischer Schritt. Sie sorgt erst dafür, dass der Workflow für Benutzer existiert. Prüfen Sie dies, bevor Sie jemandem mitteilen, dass der Workflow bereit ist.
Fehler 3: Das Verhalten erforderlicher Zwei-Optionen-Felder falsch verstehen. Dieser Fehler zeigt sich nach dem Go-live, nicht während der Tests, da Tester oft den Idealpfad testen, bei dem jedes Feld auf den „erwarteten“ Wert gesetzt wird. Im Produktivbetrieb setzen Benutzer Dinge jedoch gelegentlich auf Nein – und können dann nicht zur nächsten Phase wechseln. Das Feld ist nicht defekt. Der Prozess blockiert sie absichtlich. Wenn ein erforderlicher Zwei-Optionen-Schritt, der eine zulässige Navigation blockiert, für Ihren Prozess ein Problem darstellt, ändern Sie den Feldtyp oder machen Sie den Schritt optional und setzen Sie die Anforderung stattdessen über eine Geschäftsregel durch.
Fehler 4: Über die Plattformgrenzen hinaus planen. Die Grenzen von 30 Phasen, 5 Tabellen und 10 Verzweigungsebenen sind real und nicht verhandelbar. Ein Workflow, der eine davon überschreitet, scheitert bei der Validierung und kann nicht aktiviert werden. Geschäftsprozessoptimierung bedeutet, innerhalb der Einschränkungen zu arbeiten – nicht gegen sie zu drücken und zu hoffen, dass die Plattform nachgibt. Wenn das Design Ihres Workflows tatsächlich mehr als 30 Phasen benötigt, muss es in mehrere Workflows aufgeteilt werden, wobei Sicherheitsrollen unterschiedliche Benutzergruppen zum richtigen Workflow leiten.
An diesem letzten Punkt wird die Designfrage interessant. Wenn ein Prozess komplex genug ist, um bedingte Weiterleitungen über Dutzende Schritte zu erfordern, ist ein nativer Geschäftsprozessablauf nicht immer das richtige Werkzeug für das Gesamtbild. Teams, die Daten zum Abschluss einer Phase an externe Systeme weiterleiten müssen – etwa eine CRM-Benachrichtigung, wenn eine Dynamics 365-Opportunity zu „Vorschlag“ wechselt, oder einen an Slack gesendeten Freigabeauslöser bei einem Phasenwechsel –, ergänzen den nativen Ablauf oft um eine separate Automatisierung. Für Teams, die Phasendaten mit externen Tools verbinden, schließen Latenodes mehr als 5.500 Integrationen die Lücke zwischen dem, was der native Designer abdeckt, und dem, was nachgelagert in anderen Systemen passieren muss. Der native Ablauf steuert die geführte Erfahrung im Datensatz. Die externe Automatisierung übernimmt alles, was bei einem Phasenwechsel überall sonst passieren muss.
Dort beginnt üblicherweise das Ticket.
