Namenskonventionen in Power Automate

Ein Flow, der „Untitled“ oder „Instant cloud flow-3“ heißt, wirkt erstmal wie ein kleines Detail. Sobald in einem Tenant aber mehr als eine Handvoll Flows existieren und mehrere Personen daran bauen und pflegen, entscheidet genau dieser Name darüber, ob jemand in fünf Minuten versteht, was der Flow tut, oder eine halbe Stunde lang Trigger für Trigger durchklickt. Bei NordFlux setzen wir bei jedem digitalen Mitarbeiter, den wir für dich bauen, auf feste Namenskonventionen, weil sie die günstigste Governance-Maßnahme überhaupt sind: kein zusätzliches Tool, keine Lizenz, nur Disziplin beim Anlegen.

Microsoft behandelt Namenskonventionen deshalb nicht als Kür, sondern als festen Bestandteil der offiziellen Power-Automate-Coding-Guidelines und der Power-Platform-Governance-Empfehlungen. Dieser Artikel fasst die wichtigsten Regeln für Flows, Aktionen, Verbindungen und Umgebungen zusammen, direkt aus der Microsoft-Dokumentation abgeleitet, damit du sie als Styleguide in deinem Team festschreiben kannst. Du behältst dabei jederzeit die Kontrolle darüber, wie deine Automatisierungen wachsen, statt später mühsam aufräumen zu müssen.

Warum ist eine Namenskonvention die Grundlage für Governance?

Ein Center of Excellence für Power Platform steht laut Microsoft auf mehreren Säulen, darunter Datensicherheit, Zugriffsrechte und Monitoring. Eine davon ist die Lösungsentwicklung, und dort nennt Microsoft explizit „Codierungsstandards und Namenskonventionen zur Sicherstellung von Lesbarkeit und Wartbarkeit“ als Aufgabe der Governance. Der Grund liegt auf der Hand: Ohne einheitliche Namen lässt sich weder automatisiert reporten noch im Ernstfall schnell nachvollziehen, welcher Flow welche Verbindung nutzt oder welche Umgebung produktiv ist. Namenskonventionen sind damit keine kosmetische Frage, sondern die Basis, auf der Zugriffskontrolle, Monitoring und Reporting überhaupt erst funktionieren.

Wie solltest du Flows, Trigger und Aktionen benennen?

Für die Komponenten innerhalb eines Flows nennt die Microsoft-Doku Konsistente Benennung für Flowkomponenten verwenden fünf konkrete Empfehlungen:

• Beschreibende Namen statt generischer Bezeichnungen. Ein Trigger sollte nicht „Trigger1“ heißen, sondern zum Beispiel „Neue E-Mail empfangen“, damit der Zweck sofort klar ist.
• CamelCase oder Unterstriche zur Worttrennung. Aktionen wie „sendEmailNotification“ oder „send_email_notification“ sind auf einen Blick lesbar, „sendemailnotification“ dagegen nicht.
• Präfixe zur Kategorisierung. Microsoft schlägt vor, Trigger mit „Trg_“, Aktionen mit „Act_“ und Variablen mit „Var_“ zu markieren, damit die Rolle einer Komponente sofort erkennbar ist.
• Konsistenz über alle Flows hinweg. Ein Team, das dieselbe Konvention in jedem Flow anwendet, muss nicht bei jedem neuen Kollegen-Flow einen fremden Stil entschlüsseln.
• Dokumentation der Konvention. Ein Styleguide, zum Beispiel auf einer gemeinsamen SharePoint-Seite, sorgt dafür, dass neue Teammitglieder die Regeln kennen, statt sie aus bestehenden Flows abzuleiten.

Ergänzend empfiehlt Microsoft, Kommentare an Aktionen zu hängen, gerade bei komplexen Flows oder wenn mehrere Personen daran arbeiten. Ein Name sagt, was eine Aktion tut, ein Kommentar sagt, warum sie so gebaut wurde.

Was unterscheidet Verbindungen von Verbindungsreferenzen bei der Benennung?

Bei Connections wird die Namensfrage schnell unübersichtlich, weil Power Automate zwei unterschiedliche Konzepte kennt. Laut Vorteile der Verwendung lösungsfähiger Cloud-Flows sind Verbindungen benutzerspezifische Konfigurationen mit Authentifizierungsdetails, die außerhalb von Lösungen direkt in Aktionen eingebettet werden. Änderst du eine Verbindung, muss jede Aktion, die sie nutzt, einzeln aktualisiert werden. Verbindungsreferenzen dagegen sind ein Zeiger auf eine Verbindung und werden in lösungsfähigen Cloud-Flows verwendet. Sie trennen das Flow-Design von der konkreten Anmeldung und lassen sich zwischen Entwicklungs-, Test- und Produktionsumgebung austauschen, ohne dass du jede Aktion anfassen musst.

Für die Namenskonvention bedeutet das: Eine Verbindungsreferenz sollte den Dienst und den Verwendungszweck im Namen tragen, etwa „conref_sharepoint_freigabeliste“, statt sich auf den generischen Vorschlag zu verlassen, den der Flow-Designer automatisch vergibt. So erkennst du beim Verschieben einer Lösung zwischen Umgebungen sofort, welche Referenz welchen externen Dienst anspricht, ohne jede Aktion einzeln zu öffnen.

Wie baust du eine Namenskonvention für Umgebungen auf?

Auch oberhalb der einzelnen Flows braucht es feste Regeln. Die Umgebungsstrategie-Empfehlungen von Microsoft schlagen ein Muster aus vier Bausteinen vor: Lebenszyklusphase, Region, Unternehmenseinheit und Zweck, zum Beispiel „Prod-US-Finance-Payroll“. Alternativ reicht in kleineren Organisationen oft schon ein einfacheres Schema wie „Contoso Dev“, „Contoso Test“ und „Contoso Prod“, solange es konsequent trennt, welche Umgebung welchem Zweck dient. Wichtig ist laut Microsoft außerdem, keine vertraulichen Informationen in Umgebungsnamen aufzunehmen, weil diese für jeden mit Zugriff auf das Admin Center sichtbar sind, und die Namen kurz genug zu halten, damit sie auch nach Jahren des Wachstums noch handhabbar bleiben.

Wie setzt du eine Namenskonvention im Team konsequent durch?

Eine Konvention, die nur auf dem Papier steht, verpufft in der Praxis. Microsoft empfiehlt deshalb, die Regeln in einem Styleguide zu dokumentieren und über eine gemeinsame Anlaufstelle wie eine SharePoint-Seite mit der Maker-Community zu teilen, statt sie in einzelnen Köpfen zu belassen. Für größere Organisationen gibt es zusätzlich das Power CAT Toolkit, das Code-Reviews unterstützt und automatisch erkennt, wenn Flows von den dokumentierten Best Practices abweichen, einschließlich Namenskonventionen. So bleibt die Kontrolle über wachsende Flow-Landschaften auch dann erhalten, wenn immer mehr Fachbereiche eigene Automatisierungen bauen.

Wenn du eine Namenskonvention für dein Unternehmen aufsetzen willst, aber nicht bei null anfangen möchtest, unterstützt dich NordFlux bei Power Automate dabei, Governance-Regeln zu definieren und in bestehende Flows zu übernehmen, ohne dass laufende Prozesse unterbrochen werden.

Häufige Fragen

Muss ich Präfixe wie „Trg_“ oder „Act_“ wirklich für jede Komponente verwenden?

Nein, Microsoft nennt Präfixe als eine mögliche Option zur Kategorisierung, nicht als Pflicht. Entscheidend ist, dass du dich innerhalb deines Teams auf ein Schema einigst und es konsequent anwendest, egal ob mit Präfixen, CamelCase oder Unterstrichen.

Wo dokumentiere ich unsere Namenskonvention am besten?

Microsoft empfiehlt einen zentralen, für alle Ersteller zugänglichen Ort, zum Beispiel eine SharePoint-Seite als Power-Platform-Hub für deine Maker-Community. Wichtig ist weniger das konkrete Tool als die Tatsache, dass jede neue Person die Regeln findet, bevor sie den ersten eigenen Flow anlegt.

Gilt dieselbe Namenskonvention auch für Verbindungsreferenzen in Lösungen?

Ja, auch wenn Verbindungsreferenzen technisch anders funktionieren als einfache Verbindungen, sollten sie denselben sprechenden Namensregeln folgen. Ein Name, der den angebundenen Dienst und den Verwendungszweck nennt, hilft besonders beim Verschieben von Lösungen zwischen Entwicklungs-, Test- und Produktionsumgebung.

Wie hängen Namenskonventionen und Umgebungsstrategie zusammen?

Beide Themen greifen ineinander: Eine klare Namenskonvention für Umgebungen wie „Prod-US-Finance-Payroll“ zeigt sofort, welche Flows und Verbindungen in welcher Umgebung landen dürfen. Ohne diese Klarheit lässt sich auch die beste Flow-Benennung nicht sinnvoll in eine größere Governance-Struktur einordnen.

Lohnt sich eine Namenskonvention auch bei nur wenigen Flows?

Ja, gerade weil sich die Zahl der Flows in den meisten Organisationen schneller vermehrt als geplant, zahlt sich eine früh eingeführte Konvention aus. Nachträglich Hunderte bestehende Flows umzubenennen ist deutlich aufwendiger, als von Anfang an eine einfache Regel konsequent anzuwenden.