Salesforce Flow Modernisierung
Modelle verwenden standardmäßig die Flow-Muster ihrer Trainingsdaten: Schleife + Entscheidung + Zuweisung, DML innerhalb von Schleifen, After-Save-Updates des auslösenden Datensatzes, zusätzliche Bildschirme zur Neuberechnung. Diese Skill ersetzt sie durch die aktuellen Elemente und stellt für jedes Element deploy-verifizierte Metadaten in examples/ bereit.
Diese Regeln bestimmen die meisten Ergebnisse:
- Das moderne Element ist die Standardauswahl. Eine Schleife benötigt eine deklarierte Ausnahmebedingung (siehe unten). Wenn das XML eines Elements unbekannt ist, kopieren Sie die Form aus der dazugehörigen Beispieldatei, anstatt das Element zu vermeiden.
- Nicht verifizierbar ist nicht nicht verfügbar. Die Verfügbarkeit richtet sich nach der API-Version der Organisation und der folgenden Tabelle. Sie benötigen keinen Webzugriff, um ein Element zu verwenden, dessen Mindestversion bei oder unter der Organisationsversion liegt. Die Bereitstellungsvalidierung ist der Prüfpunkt.
- Jede Schleife und jede Umgehung wird erklärt. Benennen Sie die Ausnahme in der Beschreibung der Schleife und im Auslieferungsobjekt. Ohne eine benannte Ausnahme schreiben Sie keine Schleife.
Arbeitsablauf
Kopieren Sie diese Checkliste in Ihre Arbeitsnotizen und haken Sie die Punkte ab:
- [ ] 1. Lesen Sie references/org-conventions.md; listen Sie die nicht gesetzten Slots auf, von denen diese Aufgabe abhängt
- [ ] 2. Ermitteln Sie die API-Version der Organisation
- [ ] 3. Klassifizieren Sie die Aufgabe: Erstellen, Prüfen oder Migrieren; Flow-Typ, Trigger-Ereignis, Ausführungskontext (wer führt aus)
- [ ] 4. Ordnen Sie jede Anforderung anhand der Entscheidungstabelle zu; öffnen Sie jedes verwendete Beispiel
- [ ] 5. Schreiben Sie die Metadaten (oder die Bauspezifikation)
- [ ] 6. Führen Sie scripts/check-flow.mjs aus; beheben Sie jeden ERROR, entscheiden Sie über jede WARNING
- [ ] 7. Führen Sie eine Bereitstellungsvalidierung durch, wenn eine Organisation verfügbar ist; andernfalls kennzeichnen Sie das XML als unvalidiert
- [ ] 8. Führen Sie die Überprüfungscheckliste aus references/delivery.md durch und liefern Sie aus
Schritt 1. Konventionen. Ein ausgefüllter Slot in org-conventions.md hat Vorrang vor den Standardeinstellungen dieser Skill. Ein leerer Slot bedeutet, dass die Standardeinstellung gilt und das Auslieferungsobjekt dies unter offene Entscheidungen aufführt.
Schritt 2. API-Version. Mit einer Organisation zeigt sf org display --target-org <Alias> die "Api Version". Ohne eine Organisation verwenden Sie sourceApiVersion aus der sfdx-project.json des Projekts oder 67.0, wenn auch diese fehlt, und teilen Sie dies mit. Setzen Sie die apiVersion neuer Flows auf diese Version.
Schritt 3. Klassifizieren. Vorhandener Flow oder neuer Build. Flow-Typ (Screen, Record-Triggered Before-Save oder After-Save, Autolaunched, Schedule-Triggered, Platform-Event-Triggered). Auslösendes Objekt und Trigger-Ereignis, beantwortet aus der Anforderung, bevor Sie ein Beispiel öffnen. Die Frage ist, ob ein Datensatz, der bereits die Bedingung erfüllt, zählt, oder nur einer, der sich in diese Bedingung ändert. "Erstellen und Aktualisieren" mit "nur wenn aktualisiert, um die Bedingung zu erfüllen" feuert bei einem solchen Erstellen, während "nur aktualisieren" dies nicht tut. Wenn die Anforderung dies nicht sagt, fragen Sie oder geben Sie die Annahme an (record-triggered.md). Wer führt den Flow aus (Benutzer, System, Agent). Was muss synchron passieren. Bei Screen Flows: die Oberfläche, die ihn einbettet, und was er aufnimmt und zurückgibt.
Schritt 4. Zuordnen. Nehmen Sie für jede Sammlungsoperation, Auswahlliste, Bildschirminteraktion, Datensatzaktualisierung, Zeitlichkeitsanforderung und Integration die Zeile aus der Entscheidungstabelle. Lesen Sie die Beispieldatei für jedes Element, das Sie schreiben werden, und die Domänenreferenz für seine Grenzen. Lesen Sie nur die Referenzen für die Domänen, die die Aufgabe berührt.
Schritt 5. Schreiben. Metadaten gehen nach force-app/main/default/flows/<ApiName>.flow-meta.xml (passen Sie an das Paketverzeichnis des Projekts an). Standard-Namensgebung: Flow-API-Namen Objekt_Verb_Bedingung, Elementnamen Typ_Zweck (Get_Open_Cases, Filter_High_Priority, Transform_To_Tasks, Dec_Is_Renewal), sofern org-conventions.md nichts anderes sagt. Setzen Sie <status>Draft</status>, es sei denn, der Benutzer fordert explizit einen aktiven Flow an oder der Aktivierungsrichtlinien-Slot sagt dies. Die Beispiele sind nur aktiv, weil sie ausgeführt wurden. Halten Sie alle Elemente eines Typs in der Datei zusammen (geteilte Gruppen schlagen bei der Bereitstellung fehl). Ohne CLI-Zugriff liefern Sie eine Bauspezifikation im Format aus delivery.md.
Schritt 6. Prüfen. Führen Sie den Prüfer für jeden Flow aus, den Sie geschrieben haben oder zu überprüfen aufgefordert wurden. Er benötigt nur Node:
node <skill-verzeichnis>/scripts/check-flow.mjs --api <org-api-version> force-app/main/default/flows/<ApiName>.flow-meta.xml
ERRORs sind veraltete Muster oder Formen, die die Plattform ablehnt; beheben Sie sie. WARNINGs erfordern eine Entscheidung, die Sie im Auslieferungsobjekt angeben.
Schritt 7. Validieren. Benennen Sie bei einer authentifizierten Organisation die Organisation explizit, anstatt sich auf die Standardorganisation der CLI zu verlassen:
sf project deploy validate --source-dir force-app/main/default/flows/<ApiName>.flow-meta.xml --target-org <Alias>
Beheben Sie den Fehler anhand der genauen Fehlermeldung und führen Sie den Vorgang erneut aus. XML, das nicht validiert wurde, wird im Auslieferungsobjekt deutlich als unvalidiert gekennzeichnet.
Schritt 8. Überprüfen und ausliefern. Führen Sie die Überprüfungscheckliste in delivery.md durch. Beenden Sie das Auslieferungsobjekt mit diesem Block, wobei jede Zeile ausgefüllt ist:
Modus: Metadaten | Bauspezifikation
Prüfer: <Befehl> → <n> Fehler, <n> Warnungen (<Entscheidung pro Warnung>)
Bereitstellungsvalidierung: <Befehl und Ergebnis> | nicht ausgeführt, unvalidiert (<Grund>)
Status: Entwurf | Aktiv (<Grund>)
Ausführungskontext: <runInMode oder Standard und was dies für diesen Flow-Typ bedeutet>
Ausnahmen: <E-ID und Grund pro Schleife oder Umgehung> | keine
Offene Entscheidungen: <nicht gesetzte Konventions-Slots, von denen dieser Flow abhängt> | keine
Standard-Ausführungskontext (runInMode DefaultMode): Record-Triggered-, Schedule-Triggered- und Platform-Event-Triggered-Flows werden im Systemkontext ohne Freigabe ausgeführt. Screen- und Autolaunched-Flows werden im Benutzerkontext ausgeführt, wenn sie über die Benutzeroberfläche oder die REST-API gestartet werden, und im Kontext des Aufrufers, wenn sie von Apex oder einem anderen Flow aufgerufen werden. Autolaunched ist nicht "standardmäßig System".
Prüfungen und Migrationen
Führen Sie bei einem vorhandenen Flow zuerst den Prüfer aus, inventarisieren Sie dann die verbleibenden veralteten Muster anhand der letzten Spalte der Entscheidungstabelle. Liefern Sie den in delivery.md definierten Prüfbericht vor jeder Neuschreibung aus, sortiert nach Auswirkung: Governor-Limits, dann Sicherheitskontext, dann Benutzererfahrung. Ändern Sie den Flow nicht, es sei denn, Sie werden darum gebeten. Wenn Sie darum gebeten werden, folgen Sie dem Migrationsplan des Berichts in der Reihenfolge. Beschreiben Sie Muster, niemals die Personen, die sie erstellt haben, da die meisten veralteten Muster zum Zeitpunkt der Erstellung die empfohlene Vorgehensweise waren. Die Zuordnung von Process Builder und Workflow Rules finden Sie in legacy-migration.md.
Entscheidungstabelle
"Org API" ist die niedrigste API-Version einer Organisation, die das Element hat (Flow, Metadata API Developer Guide). Beispiele befinden sich in examples/flows/, bereitgestellt und ausgeführt auf API 67.0.
| Anforderung | Verwenden Sie | Metadaten | Org API | Beispiel | Ersetzt |
|---|---|---|---|---|---|
| Die Elemente einer Sammlung behalten, die Kriterien erfüllen | Collection Filter (Bedingungen oder Formel) | collectionProcessors, FilterCollectionProcessor | 53 | Opportunity_Create_Followup_Tasks | Schleife + Entscheidung + Zuweisung |
| Datensätze aus einer Sammlung erstellen, Felder umformen | Transform, Map | transforms | 59 | Opportunity_Create_Followup_Tasks | Schleife + Zuweisung zum Erstellen einer Sammlung |
| Eine Sammlung summieren oder zählen | Transform, Sum / Count. In Before-Save-Flows: Filter + Zuweisung AssignCount oder eine Schleife für eine Summe (E3) | transforms, inputParameters | 59 (primitives Ziel 62) | Opportunity_Create_Followup_Tasks, Account_Before_Save_Count_Contacts | Schleifenzähler |
| Zwei Sammlungen über einen Schlüssel kombinieren | Transform, InnerJoin, mit der Zuordnung im selben Transform | transforms, JoinDefinition | 63 | Opportunity_Create_Account_Tasks_Joined | Verschachtelte Schleifen, Get Records innerhalb einer Schleife |
| Eine Sammlung sortieren | Collection Sort (sortiert an Ort und Stelle) | SortCollectionProcessor | 50 | Opportunity_Allocate_Budget_Waterfall | Manuelles Sortieren in einer Schleife |
| Viele Datensätze erstellen, aktualisieren oder löschen | Ein DML auf der vorbereiteten Sammlung | recordCreates inputReference | beliebig | Opportunity_Create_Followup_Tasks | DML innerhalb einer Schleife |
| Optionen aus Datensätzen oder einer Auswahlliste | Record / Picklist Choice Set | dynamicChoiceSets | beliebig | Account_Order_Entry_Screen | Get Records + Schleife zum Erstellen von Optionen |
| Summen, Sichtbarkeit oder Text, die Eingaben folgen | Reaktive Formel, visibilityRule | formulas, Bildschirmfelder | 59 | Account_Order_Entry_Screen | Ein zweiter Bildschirm zur Neuberechnung |
| Eingaberegeln auf einem Bildschirm | Komponente validationRule | Bildschirm fields | beliebig | Account_Order_Entry_Screen | Entscheidung nach dem Bildschirm zurück zu einem Fehlerbildschirm |
| Serverlogik, ohne den Bildschirm zu verlassen | Screen Action + Action Button | screens.actions, triggers | 59 | Account_Check_Pipeline_Screen | Weiter, Get Records, wieder zurück |
| Felder auf dem auslösenden Datensatz setzen | Before-Save-Flow, Zuweisung zu $Record | triggerType RecordBeforeSave | beliebig | Opportunity_Before_Save_Set_Next_Step | After-Save Update Records auf $Record |
| Einen Speichervorgang mit einer Nachricht blockieren | Custom Error | customErrors | 59 | Opportunity_Before_Save_Set_Next_Step | After-Save-Kompensation |
| Nur ausführen, wenn sich relevante Felder ändern | Einstiegsbedingungen, filterFormula mit ISCHANGED, "nur wenn aktualisiert, um die Bedingung zu erfüllen" | start | 55 (Formel) | Opportunity_Before_Save_Set_Next_Step, Opportunity_Closed_Won_Handover | Entscheidung als erstes Element |
| Callouts, E-Mails, nicht zusammenhängende DML, auf die der Benutzer nicht warten muss | Asynchroner Pfad | scheduledPaths AsyncAfterCommit | 53 | Opportunity_Closed_Won_Handover | Alles synchron |
| Arbeiten vor oder nach einem Datum eines Datensatzes | Scheduled Path | scheduledPaths RecordField | 51 | Opportunity_Closed_Won_Handover | Schedule-Triggered-Flow, der nach fälligen Datensätzen abfragt |
| Auf ein Platform-Event reagieren | Platform-Event-Triggered-Flow | triggerType PlatformEvent | 49 | Order_Event_Create_Task | Apex-Trigger, geschrieben zum Starten von Flow-Logik |
| Pausieren, bis ein Ereignis eintrifft | Wait-Element mit einem Platform-Event | waits | beliebig | Order_Wait_For_Confirmation | Abfragen |
| Flow-Logik für einen Agentforce-Agenten | Autolaunched-Flow mit beschriebenen Ein- und Ausgaben | variables description | beliebig | Case_Get_Status_For_Agent | Invocable Apex-Wrapper |
| Reihenfolge zwischen Flows auf einem Objekt | Trigger Order | triggerOrder | 54 | Opportunity_Closed_Won_Handover | Verlassen auf die Erstellungsreihenfolge |
| Eine REST-API aufrufen | HTTP Callout-Aktion | actionCalls (Builder-generiert) | siehe Integrationsreferenz | keine | Apex, nur für den Callout geschrieben |
Transform ist in Before-Save-Flows nicht zulässig (Bereitstellungsfehler). Before-Save hat Vorrang vor Transform, daher bleibt ein Wert auf dem auslösenden Datensatz Before-Save, und eine Summe dort ist eine Schleife unter E3, niemals ein After-Save-Transform plus ein zweites Speichern. Alles andere oben funktioniert in jedem Flow-Typ, der das Konzept hat, und die Domänenreferenzen listen die Ausnahmen auf.
Ausnahmebedingungen
Ein veraltetes Muster ist nur dann korrekt, wenn eine dieser Bedingungen zutrifft. Deklarieren Sie es in der <description> einer Schleife als Escape: E<n> <Grund> und im Auslieferungsobjekt.
| ID | Erlaubt | Gilt nur, wenn |
|---|---|---|
| E1 | Eine Schleife | Jedes Element benötigt seinen eigenen Aufruf einer Aktion, eines Subflows oder eines Apex-Plugins, das nur einzelne Werte akzeptiert. Der Schleifenkörper enthält diesen Aufruf. |
| E2 | Eine Schleife | Das Ergebnis eines Elements hängt von früheren Elementen ab, die über eine Summe oder Zählung hinausgehen: ein laufender Saldo, eine Zuteilung, eine Sequenznummer, ein Round-Robin. |
| E3 | Eine Schleife | Ein Before-Save-Flow benötigt eine Summe (Transform ist dort nicht zulässig). Dies ist beabsichtigt, da die In-Memory-Schleife billiger ist als ein After-Save-Zweitspeichern. Zählungen verwenden stattdessen Filter + AssignCount. |
| E4 | Arbeit auf dem synchronen Pfad | Ein späteres Element in derselben Transaktion liest das Ergebnis, oder der Benutzer muss es sehen, bevor der Speichervorgang abgeschlossen ist. |
| E5 | Keine reaktiven oder neueren Bildschirmfunktionen | Die genannte Einbettungsoberfläche unterstützt sie nicht: Salesforce Classic-Laufzeit, Slack (eingeschränkter Komponentensatz) oder eine Komponente, die die reaktiven Dokumente als nicht reaktiv auflisten. |
| E6 | Ein veraltetes Muster an Ort und Stelle belassen | Nur Prüfumfang: Der Flow liegt außerhalb der Änderung, die Sie vornehmen sollten. Gilt niemals für neue oder neu geschriebene Flows. |
Diese zählen nicht als Ausnahmebedingungen:
- "Ich kann nicht überprüfen, ob das Element in dieser Organisation existiert" (Regel 2 gilt, also überprüfen Sie die API-Version, dann bereitstellen-validieren).
- "Ich bin mir des XML nicht sicher" (kopieren Sie das Beispiel).
- "Eine Schleife ist einfacher oder klarer."
- "Bedingte Werte pro Element" (verwenden Sie
IF()in einer Transform-Formel). - "Filtern und Zuordnen in einem Durchgang" (Filtern, dann Transformieren).
- "Die Oberfläche könnte es nicht unterstützen" (nennen Sie die Oberfläche oder listen Sie es als offene Entscheidung auf, da eine unbekannte Oberfläche nicht E5 ist).
- DML oder Get Records innerhalb einer Schleife. Keine Ausnahme erlaubt sie.
Verwenden Sie das einfachste ausreichende Element. Das bedeutet Filter allein, wenn nur gefiltert wird, statische Auswahlmöglichkeiten, wenn die Optionsliste fest ist, und kein Subflow für Logik mit einem Aufrufer.
Vor dem Behaupten verifizieren
- Verfügbarkeit: API-Version der Organisation gegen die Tabelle. Behandeln Sie lizenzabhängige Funktionen (Agentforce, Einstein, Data 360, einige Orchestrierungseditionen) als Annahmen, bis die Organisation sie bestätigt, und teilen Sie dies mit.
- Grenzen und GA-Status, die ein Design oder einen Prüfbefund ändern: Zitieren Sie die offizielle Quelle (help.salesforce.com, developer.salesforce.com). Zitieren Sie keine Zahlen aus dem Gedächtnis, da die Domänenreferenzen die verifizierten angeben.
Fehlerbehandlung
- CLI fehlt oder Organisation nicht erreichbar: Liefern Sie Metadaten als "unvalidiert" gekennzeichnet oder eine Bauspezifikation und geben Sie an, welches.
- Validierung schlägt fehl: Beheben Sie den Fehler anhand der genauen Meldung, führen Sie den Prüfer und die Validierung erneut aus. Die Domänenreferenzen listen die bisher gesehenen Bereitstellungsfehler auf.
- Funktion nicht in der Organisation (API-Version, Edition, Lizenz): Verwenden Sie die nächstgelegene unterstützte Zeile der Tabelle, nennen Sie die Lücke und die Ausnahme.
Referenzen
Lesen Sie die, die die Aufgabe benötigt:
- org-conventions.md: die Entscheidungen des Teams, die Vorrang vor Standardeinstellungen haben.
- collections.md: Filter, Sort, Transform (Map, Sum, Count, Join), Bulk DML, Schleifen.
- screens.md: Choice Sets, reaktive Bildschirme, Validierung, Screen Actions, Einbettung.
- record-triggered.md: Einstiegsbedingungen, Trigger-Reihenfolge, Before-Save vs. After-Save, $Record, benutzerdefinierte Fehler.
- async-paths.md: Asynchrone Pfade, geplante Pfade, Wait-Elemente, Platform-Event-Trigger.
- agent-actions.md: Autolaunched-Flows als Agent Actions, Eingabe- und Ausgabevariablen, Beschreibungen.
- integration.md: HTTP-Callouts, Grenzen, Authentifizierung.
- legacy-migration.md: Process Builder, Workflow Rules.
- delivery.md: Format für Auslieferungsobjekte, Prüfbericht, Bauspezifikation und Abnahmekriterien.