Namenskonventionen in Power Automate

Ein Flow, der „Untitled" oder „Instant cloud flow-3" heißt, wirkt zunächst wie ein Detail. Sobald mehrere Personen im selben Tenant bauen, entscheidet genau dieser Name über die Einarbeitungszeit.

Microsoft führt Namenskonventionen deshalb als festen Bestandteil der Power-Automate-Coding-Guidelines. Dieser Artikel fasst die Regeln für Flows, Aktionen, Verbindungen und Umgebungen zusammen. Er zeigt außerdem, woran die Namen technisch hängen.

Warum ist eine Namenskonvention die Grundlage für Governance?

Der Name ist die einzige Ebene, auf der sich Flows ohne Zusatzwerkzeug filtern, gruppieren und auswerten lassen. Ohne Muster im Namen bleibt jede Auswertung Handarbeit.

Microsoft nennt in den Coding-Guidelines für Cloud-Flows Standards für Benennung, Struktur und Fehlerbehandlung als Grundlage wartbarer Automatisierung. Für Umgebungen ergänzt die Umgebungsstrategie: Konsistente Namen erleichtern Automatisierung und Berichterstellung.

Namenskonventionen kosten keine Lizenz und kein zusätzliches Werkzeug. Sie sind damit die günstigste Governance-Maßnahme, die Ihnen zur Verfügung steht.

Wie sollten Sie Flows, Trigger und Aktionen benennen?

Microsoft nennt in Konsistente Benennung für Flowkomponenten verwenden sechs Regeln: beschreibende Namen, camelCase oder Unterstriche, Präfixe zur Kategorisierung, Konsistenz über alle Flows, Dokumentation im Styleguide und Notizen an den Aktionen.

Die Präfixe aus der Dokumentation lassen sich direkt als Tabelle festschreiben:

Komponente | Präfix laut Microsoft | Beispiel

Komponente: Trigger · Präfix laut Microsoft: Trg_ · Beispiel: Trg_Neues_Element_in_Freigabeliste

Komponente: Aktion · Präfix laut Microsoft: Act_ · Beispiel: Act_Elemente_abrufen

Komponente: Variable · Präfix laut Microsoft: Var_ · Beispiel: Var_OffeneVorgaenge

Komponente: Verbindungsreferenz · Präfix laut Microsoft: eigene Festlegung, etwa conref_ · Beispiel: conref_sharepoint_freigabeliste

Das Präfix für Verbindungsreferenzen gibt Microsoft nicht vor. Es hat sich in der Praxis bewährt, weil es die Referenz im Lösungs-Explorer sofort von der Tabelle trennt.

So sieht ein konsequent benannter Ausschnitt in der Codeansicht aus. Jeder Name sagt, welche Rolle die Komponente hat:

1{
2  "Var_OffeneVorgaenge": {
3    "type": "InitializeVariable",
4    "inputs": {
5      "variables": [
6        { "name": "Var_OffeneVorgaenge", "type": "integer", "value": 0 }
7      ]
8    },
9    "runAfter": {}
10  },
11  "Act_Offene_Vorgaenge_filtern": {
12    "type": "Query",
13    "inputs": {
14      "from": "@body('Act_Elemente_abrufen')?['value']",
15      "where": "@equals(item()?['Status'], 'Offen')"
16    },
17    "runAfter": { "Var_OffeneVorgaenge": ["Succeeded"] }
18  },
19  "Act_Zaehler_setzen": {
20    "type": "SetVariable",
21    "inputs": {
22      "name": "Var_OffeneVorgaenge",
23      "value": "@length(body('Act_Offene_Vorgaenge_filtern'))"
24    },
25    "runAfter": { "Act_Offene_Vorgaenge_filtern": ["Succeeded"] }
26  }
27}
Copy

Beachten Sie die Schreibweise in runAfter und in den Ausdrücken. Dort steht der interne Name mit Unterstrichen, nicht die Anzeige mit Leerzeichen.

Ergänzend empfiehlt Microsoft Notizen an den Aktionen. Der Name sagt, was eine Aktion tut. Die Notiz sagt, warum sie so gebaut wurde.

Warum brechen Ausdrücke beim Umbenennen einer Aktion?

Weil Ausdrücke den Aktionsnamen als Text enthalten und Power Automate diesen Text nicht überall mitzieht. Die Fehlercode-Referenz für Cloud-Flows hält zwei Regeln fest.

Erstens ersetzen Unterstriche die Leerzeichen. Zweitens wird zwischen Groß- und Kleinschreibung unterschieden. Aus der Aktion „Get item" wird also:

1outputs('Get_item')
2
3body('Act_Elemente_abrufen')?['value']
4
5length(body('Act_Offene_Vorgaenge_filtern'))
Copy

outputs('Get Item') mit Leerzeichen und großem I schlägt dagegen mit InvalidTemplate fehl. Deshalb gilt: Benennen Sie eine Aktion sofort nach dem Einfügen, nicht erst am Ende.

Was unterscheidet Verbindungen von Verbindungsreferenzen?

Verbindungen speichern die Anmeldung selbst, Verbindungsreferenzen zeigen nur darauf. Der Unterschied stammt aus Vorteile der Verwendung lösungsfähiger Cloud-Flows.

Merkmal | Verbindung | Verbindungsreferenz

Merkmal: Vorkommen · Verbindung: Flows außerhalb von Lösungen · Verbindungsreferenz: lösungsfähige Cloud-Flows

Merkmal: Inhalt · Verbindung: Authentifizierungsdetails, benutzerspezifisch · Verbindungsreferenz: Zeiger auf eine Verbindung

Merkmal: Änderung der Anmeldung · Verbindung: jede verknüpfte Aktion einzeln aktualisieren · Verbindungsreferenz: nur die Referenz aktualisieren

Merkmal: Transport zwischen Umgebungen · Verbindung: einzeln nachziehen · Verbindungsreferenz: über die Lösung, mit Umgebungsvariablen

Merkmal: Versionsverwaltung des Flows · Verbindung: nicht verfügbar · Verbindungsreferenz: verfügbar

Ein Grenzwert kommt hinzu. Außerhalb von Lösungen besitzt eine Person höchstens 600 Flows. Für Flows in Lösungen gilt diese Grenze nicht.

Für die Benennung folgt daraus: Nennen Sie Dienst und Verwendungszweck in der Referenz, etwa conref_sharepoint_freigabeliste. Beim Verschieben einer Lösung sehen Sie dann sofort, welche Referenz welchen Dienst anspricht. Wie sich das in gewachsenen Listenlandschaften auswirkt, zeigen wir in der SharePoint-Workflow-Migration.

Wie bauen Sie eine Namenskonvention für Umgebungen auf?

Microsoft schlägt ein Muster aus vier Bausteinen vor, zum Beispiel Prod-US-Finance-Payroll. Kleinere Organisationen kommen mit „Contoso Entwicklung", „Contoso Test" und „Contoso Produktion" aus.

Baustein | Zweck | Beispielwerte

Baustein: Lebenszyklusphase · Zweck: trennt gleiche Inhalte nach Verwendungszweck · Beispielwerte: Dev, Test, Prod

Baustein: Region · Zweck: zeigt den Datenstandort · Beispielwerte: EU, US, DE

Baustein: Unternehmenseinheit · Zweck: ordnet die Umgebung einer Nutzergruppe zu · Beispielwerte: Finance, HR, Vertrieb

Baustein: Zweck · Zweck: benennt das Vorhaben · Beispielwerte: Payroll, Rechnungsfreigabe

Zwei Nebenbedingungen nennt Microsoft ausdrücklich. Namen dürfen keine vertraulichen Informationen enthalten, weil sie für jeden mit Zugriff auf das Admin Center sichtbar sind. Und das Schema muss dem Wachstum standhalten.

Wie prüfen Sie bestehende Flow-Namen automatisch?

Über das PowerShell-Modul für Power-Platform-Administration lassen sich alle Flow-Namen einer Umgebung auslesen und gegen ein Muster prüfen. Das folgende Skript listet jeden Flow auf, dessen Name nicht dem Schema Bereich-Ausloeser-Ergebnis folgt:

1Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser
2Add-PowerAppsAccount
3
4$muster = '^[A-Za-z]+-[A-Za-z]+-[A-Za-z]+$'
5
6foreach ($umgebung in Get-AdminPowerAppEnvironment) {
7    Get-AdminFlow -EnvironmentName $umgebung.EnvironmentName |
8        Where-Object { $_.DisplayName -notmatch $muster } |
9        Select-Object @{ n = 'Umgebung'; e = { $umgebung.DisplayName } },
10                      DisplayName, FlowName
11}
Copy

Das Ergebnis ist Ihre Aufräumliste. Sie brauchen dafür Administratorrechte im Tenant oder in der jeweiligen Umgebung.

Für Lösungen empfiehlt Microsoft zusätzlich das Power CAT Toolkit für Code-Reviews. Es kennzeichnet Muster, die von den dokumentierten Best Practices abweichen.

Dokumentieren Sie die Regeln an einer Stelle, die jede neue Person findet. Microsoft schlägt dafür eine SharePoint-Seite als Power-Platform-Hub vor. Wenn Sie eine Konvention aufsetzen und in bestehende Flows übernehmen möchten, unterstützt Sie NordFlux bei Power Automate dabei.

Typische Fehler und Ursachen

Fünf Fehlerbilder treten rund um Namen regelmäßig auf. Alle fünf haben eine dokumentierte Ursache.

Der Flow lässt sich nicht speichern, Fehler `DuplicateActionName`. Ursache: Zwei Aktionen tragen denselben internen Namen, meist nach dem Kopieren ohne Umbenennen. Lösung: Eine der beiden umbenennen und alle Ausdrücke von outputs('Alter_Name') auf outputs('Neuer_Name') umstellen. Quelle: Cloud flow error code reference.

Nach dem Umbenennen meldet der Flow `InvalidTemplate`. Ursache: Ein Ausdruck verweist noch auf den alten Aktionsnamen oder verwendet Leerzeichen statt Unterstrichen. Lösung: Alle Ausdrücke prüfen und exakt schreiben, outputs('Get_item') statt outputs('Get Item'). Quelle: Cloud flow error code reference.

Aktionen lassen sich nicht umbenennen. Ursache: Ein bekanntes Problem bei Flows mit Power-Apps-Trigger. Lösung: Trigger entfernen, Aktionen umbenennen, Trigger neu hinzufügen und Variablen neu belegen. Quelle: Troubleshoot common issues with triggers.

Notizen lassen sich nicht ergänzen. Ursache: Kommentare sind für Flows aus verwalteten Lösungen nicht zulässig. Lösung: Notizen in der Entwicklungsumgebung setzen und mit der Lösung transportieren. Quelle: Move, delete, and add options to actions.

Ein Umgebungsname verrät Interna. Ursache: Umgebungsnamen sind für jeden sichtbar, der Zugriff auf das Admin Center hat. Lösung: Projektcodenamen, Kundennamen und Vertragsnummern aus dem Namen entfernen. Quelle: Umgebungsstrategie.

Häufige Fragen

Muss ich Präfixe wie „Trg_" oder „Act_" wirklich verwenden?

Nein. Microsoft nennt Präfixe als Option zur Kategorisierung, nicht als Pflicht. Entscheidend ist, dass sich Ihr Team auf ein Schema einigt und es überall anwendet.

Wo dokumentiere ich unsere Namenskonvention am besten?

An einem zentralen Ort, den jede erstellende Person erreicht. Microsoft schlägt eine SharePoint-Seite als Power-Platform-Hub vor. Wichtig ist, dass neue Personen die Regeln vor dem ersten eigenen Flow finden.

Gilt dieselbe Konvention auch für Verbindungsreferenzen?

Ja. Verbindungsreferenzen funktionieren technisch anders als Verbindungen, folgen aber denselben sprechenden Regeln. Ein Name mit Dienst und Verwendungszweck hilft besonders beim Transport zwischen Entwicklung, Test und Produktion.

Wie hängen Namenskonventionen und Umgebungsstrategie zusammen?

Ein Umgebungsname wie Prod-US-Finance-Payroll zeigt sofort, welche Flows dort landen dürfen. Ohne diese Klarheit lässt sich auch die beste Flow-Benennung nicht in eine Governance-Struktur einordnen.

Lohnt sich eine Namenskonvention auch bei wenigen Flows?

Ja. Die Zahl der Flows wächst in den meisten Organisationen schneller als geplant. Hunderte Flows nachträglich umzubenennen ist deutlich aufwendiger, als von Anfang an eine einfache Regel anzuwenden.