Automatisierungen retten Admins und Berater. Sie übernehmen repetitive Aufgaben, halten Daten konsistent und beschleunigen Prozesse, die sonst manuell laufen würden. In der Theorie. In der Praxis sehe ich in fast jedem Projekt dieselben Fehler. Manche davon kosten nur Zeit, manche kosten Daten.
Was folgt, sind keine akademischen Fehlerklassen. Es sind konkrete Situationen aus meiner Arbeit als Salesforce- und Airtable-Berater. Jeder dieser Fehler ist mir mindestens einmal begegnet. Die meisten mehrfach. Und alle lassen sich vermeiden, wenn Sie wissen, worauf Sie achten müssen.
Fehler 1: Zu früh automatisiert
Symptom: Ein Unternehmen führt Salesforce ein. Die Vertriebsleiterin will sofort Automatisierungen. Leads sollen automatisch qualifiziert, Tasks erstellt und E-Mails verschickt werden. Der Prozess dahinter ist noch nicht definiert, die Felder nicht stabil, die Nutzer noch im Onboarding.
Konsequenz: Drei Monate später bildet die Automatisierung einen Prozess ab, den niemand mehr so lebt. Jeder Edit am Prozess erfordert einen Edit am Flow. Die Automatisierung wird zur Bremse statt zum Beschleuniger. Im schlimmsten Fall ignorieren die Nutzer den Flow komplett und arbeiten am System vorbei.
Fix: Erst wenn ein Prozess mindestens vier Wochen stabil manuell läuft, lohnt sich die Automatisierung. Vorher riskieren Sie, Instabilität in Ihren Flow zu gießen. Ich empfehle meinen Kunden: Dokumentieren Sie den manuellen Prozess. Wenn er sich in vier Wochen nicht verändert hat, ist er reif für die Automatisierung.
Fehler 2: Kein Fehler-Handler
Symptom: Salesforce Flows laufen durch. Bis sie es nicht mehr tun. Ein fehlender Wert in einem Lookup, ein API-Timeout, ein Pflichtfeld das nicht befüllt ist. Der Flow bricht ab, der Datensatz bleibt in einem Zwischenzustand, und der Admin bekommt erst Tage später eine Fehlermeldung. Wenn überhaupt.
Konsequenz: Ich habe Projekte gesehen, in denen Flows seit Wochen mit Fault-Pfaden fehlschlugen, aber niemand die Flow Error E-Mails im Postfach hatte. Der Prozess lief scheinbar. Die Daten waren korrupt. Bei einem Kunden fehlten 200 Aktivitäten-Records, weil ein Flow seit drei Wochen bei bestimmten Feldkombinationen abbrach.
Fix: Jeder Flow braucht einen Fault Connector. Der leitet auf einen Fehler-Pfad, der mindestens eine Nachricht speichert: welcher Datensatz, welche Aktion, welcher Fehlertext. Idealerweise landet das in einem Custom Object für Monitoring. Mindestens aber geht eine E-Mail an den Admin.
Mehr zu sauberem Flow-Aufbau finden Sie im Artikel Salesforce Flow Best Practices.
Fehler 3: Zu komplexe Flows statt einfacher Lösungen
Symptom: Ein Flow mit 47 Elementen, 12 Entscheidungspfaden und drei Sub-Flows für eine Aufgabe, die ein erfahrener Admin mit einer Formula Field-Lösung und einem einzigen Record-Triggered Flow in 20 Minuten baut. Das ist kein Extremfall. Das ist ein typisches Ergebnis, wenn Flows nicht von Grund auf geplant, sondern iterativ erweitert werden.
Konsequenz: Komplexe Flows sind schwerer zu debuggen, schwerer zu warten und produzieren bei Änderungen häufiger unvorhergesehene Seiteneffekte. Wenn ich als externer Berater dazukomme und einen Flow nicht in fünf Minuten verstehen kann, ist das ein Warnsignal. Bei einem Kunden hat ein überladener Lead-Routing-Flow bei jeder kleinen Änderung an der Zuweisungslogik drei weitere Fehler produziert.
Fix: Die Gegenfrage, die ich immer stelle: Braucht das wirklich einen Flow? Manchmal reicht ein Formula Field. Manchmal ein Validation Rule. Manchmal ein Default-Wert. Das Einfachste, das die Anforderung erfüllt, ist fast immer die beste Lösung. Und wenn es ein Flow sein muss: Planen Sie die Logik auf Papier, bevor Sie den Flow Builder öffnen.
Ein Flow, den Sie in fünf Minuten erklären können, läuft zehn Jahre lang zuverlässig. Einen Flow, den Sie selbst nicht mehr durchschauen, werden Sie in zwölf Monaten löschen.
Fehler 4: Automatisierungen ohne User-Input
Symptom: Automatisierungen werden technisch gebaut, ohne die Nutzer zu fragen, die damit arbeiten werden. Flows triggern zu falschen Zeitpunkten, erzeugen Benachrichtigungen die niemand braucht, oder schreiben Felder über, die die Vertriebsmitarbeiter manuell pflegen wollen.
Konsequenz: Ein konkretes Beispiel: Ein Kundenunternehmen hatte einen Flow, der bei jedem Lead-Update automatisch eine interne Benachrichtigung auslöste. Das Team hatte den Flow nach zwei Wochen deaktiviert, weil die Benachrichtigungsflut den Arbeitsfluss störte. Der Flow lief nie wieder. In einem anderen Projekt hatte ein Automatisierungs-Flow das Feld "Nächster Schritt" auf der Opportunity überschrieben. Die Vertriebsmitarbeiter pflegten das Feld manuell und verloren jedes Mal ihre Notizen.
Fix: Bevor eine Automatisierung gebaut wird, lohnt sich ein kurzes Interview mit den Hauptnutzern: Was nervt Sie heute? Was soll die Automatisierung nicht tun? Welche Felder gehören Ihnen? Diese fünfzehn Minuten sparen Wochen an Korrekturen. Ich führe vor jedem Automatisierungsprojekt einen Workshop mit den Key Usern durch. Dauert maximal eine Stunde. Spart mindestens zwei Iterationsrunden.
Fehler 5: Fehlende Dokumentation
Symptom: Sechs Monate nach Go-Live fragt ein neuer Admin: Was macht dieser Flow eigentlich? Niemand weiß es mehr. Der Originalentwickler ist nicht mehr im Unternehmen. Die Beschreibung im Flow-Editor ist leer. Die einzige Möglichkeit, den Flow zu verstehen, ist ihn komplett durchzulesen.
Konsequenz: Jede Änderung an einem undokumentierten Flow dauert doppelt so lang, weil der Admin zuerst verstehen muss, was der Flow tut. In einer Org mit 30 undokumentierten Flows summiert sich das auf Wochen verlorener Produktivität pro Jahr. Und das Risiko steigt, dass ein Admin aus Unsicherheit einen Flow lieber nicht anfasst, obwohl er aktualisiert werden müsste.
Fix: Dokumentation ist keine Nice-to-have. Sie ist Teil der Lieferung. In jedem meiner Projekte gehört zu einem Flow mindestens: eine Beschreibung im Description-Feld (was tut der Flow, wann triggert er), eine Zeile im internen Admin-Wiki, und falls es Sub-Flows gibt, ein Übersichtsdiagramm. Das sind dreißig Minuten pro Flow. Diese dreißig Minuten zahlen sich beim nächsten Änderungsauftrag sofort aus.
Fehler 6: Kein Test in der Sandbox
Symptom: Flows direkt in der Produktionsumgebung bauen und aktivieren. Das klingt nach einer Entscheidung, die niemand bewusst trifft. In kleinen Unternehmen ohne dedizierte Sandbox ist es aber alltäglich. Und in größeren Unternehmen passiert es unter Zeitdruck trotzdem.
Konsequenz: Ein Record-Triggered Flow, der in der Produktion sofort auf alle existierenden Datensätze trifft. Ein Update-Field-Element das nicht das richtige Field anspricht. Das sind Fehler, die in fünf Minuten in der Sandbox sichtbar werden, aber in der Produktion Hunderte von Datensätzen beschädigen können. Bei einem Kunden hat ein falsch konfigurierter Flow in der Produktion 3.000 Account-Records mit falschen Owner-Werten überschrieben. Die Korrektur hat zwei Tage gedauert.
Fix: Wenn keine Full-Sandbox zur Verfügung steht, ist mindestens eine Developer Sandbox Pflicht. Testen Sie nicht nur den Happy Path, sondern auch: Was passiert bei leeren Feldern? Bei Bulk-Updates? Bei Records, die den Trigger-Bedingungen nicht entsprechen?
Wer Flows aus einer bestehenden Org migriert, sollte sich mit dem Thema Migrations-Workflow beschäftigen, bevor er losläuft.
Fehler 7: Over-Engineering mit Automatisierungen
Symptom: Automatisierungen können fast alles. Das verleitet dazu, immer mehr in sie hineinzupacken. Ein Lead-Routing-Flow, der gleichzeitig den Account anreichert, eine Task erstellt, den Owner ändert, eine Slack-Benachrichtigung auslöst und den Opportunity Stage aktualisiert. Technisch möglich. Praktisch eine Katastrophe.
Konsequenz: Wenn einer dieser Schritte fehlschlägt, was passiert dann mit den anderen? Wie debuggen Sie, welcher Schritt das Problem verursacht hat? Wie ändern Sie ein Detail, ohne den Rest zu beeinflussen? In meiner Erfahrung sind solche Mega-Flows der häufigste Grund für lange Debug-Sessions. Nicht weil die einzelnen Schritte komplex sind, sondern weil die Abhängigkeiten zwischen den Schritten unsichtbar werden.
Fix: Das Prinzip, das ich konsequent anwende: Ein Flow macht eine Sache. Wirklich eine. Wenn mehrere Dinge passieren sollen, sind das mehrere Flows. Jeder mit eigenem Fault-Handler, eigener Dokumentation, eigenem Testfall. Das klingt nach mehr Arbeit. Es ist weniger Arbeit, sobald etwas schiefgeht.
Einen strukturierten Einstieg in den Aufbau sauberer Flows gibt der Artikel Salesforce Flows aufbauen: Vom Solution Design zum fertigen Flow.
Fehler, die ich nur in größeren Organisationen sehe
Die bisherigen Fehler betreffen Unternehmen jeder Größe. Die folgenden drei sind spezifisch für Organisationen ab 50 CRM-Nutzern, wo Komplexität und Teamstrukturen zusätzliche Risiken schaffen.
Fehler: Automations-Wildwuchs ohne Governance
In größeren Salesforce-Orgs gibt es oft mehrere Admins und Entwickler, die unabhängig voneinander Automatisierungen erstellen. Der Vertriebsadmin baut einen Flow für die Lead-Zuweisung. Der Service-Admin baut einen Flow für die Eskalation. Der Entwickler baut einen Apex-Trigger für die Datenvalidierung. Alle drei greifen auf dieselben Objekte zu.
Das Ergebnis: Flows, die sich gegenseitig triggern, Order-of-Execution-Probleme und Debug-Sessions, die Tage dauern. Bei einem meiner Kunden haben wir 47 aktive Flows gezählt, von denen 12 auf das Opportunity-Objekt griffen. Drei davon liefen bei jedem Update, und niemand wusste, in welcher Reihenfolge.
Die Lösung: Eine Automation-Registry. Ein zentrales Dokument, in dem jede Automatisierung mit Objektbezug, Trigger-Bedingung und verantwortlichem Admin erfasst ist. Das klingt bürokratisch. Aber es spart im Fehlerfall Stunden bis Tage.
Fehler: Keine Trennung von Sandbox und Produktion
Automatisierungen direkt im Produktivsystem zu bauen und zu testen, ist ein Fehler, den ich erschreckend oft sehe. Selbst bei Unternehmen, die eigentlich wissen, dass es Sandboxes gibt.
Der typische Ablauf: Der Admin baut einen Flow in der Sandbox, testet ihn mit drei Records, findet alles gut und deployed. In Produktion trifft der Flow auf 50.000 Records mit inkonsistenten Daten. Der Flow schlägt fehl, aber nicht sofort. Sondern nach und nach, bei bestimmten Datensatz-Konstellationen, die in der Sandbox nicht existierten.
Meine Mindestanforderung: Jeder Flow wird mit realistischen Testdaten getestet. Das bedeutet: eine Sandbox mit einem aktuellen Produktions-Snapshot, nicht mit fünf manuell erstellten Test-Records.
Fehler: Automatisierungen ohne Ablaufdatum
Automatisierungen werden gebaut und laufen. Für immer. Auch wenn der Prozess, den sie abbilden, sich längst verändert hat. Bei einem Audit habe ich eine Workflow Rule gefunden, die seit 2019 aktiv war und Leads an einen Mitarbeiter zugewiesen hat, der seit zwei Jahren nicht mehr im Unternehmen war.
Planen Sie für jede Automatisierung einen Review-Zyklus ein. Quartalsweise für kritische Flows, halbjährlich für alles andere. Prüfen Sie: Wird der Flow noch gebraucht? Bildet er den aktuellen Prozess ab? Gibt es Performance-Auffälligkeiten?
Checkliste: Vor jedem Automatisierung-Go-Live prüfen
Diese Checkliste hängt bei mir an jedem Projektboard. Bevor ein Flow aktiviert wird, müssen alle Punkte abgehakt sein:
1. Prozess stabil? Läuft der Prozess seit mindestens vier Wochen manuell ohne wesentliche Änderungen?
2. User eingebunden? Haben die Hauptnutzer bestätigt, dass die Automatisierung ihren Arbeitsfluss unterstützt, nicht stört?
3. Fault Connector vorhanden? Hat jeder Flow-Pfad einen Fehler-Handler, der den Admin benachrichtigt und den Fehler loggt?
4. Sandbox getestet? Wurde der Flow mit realistischen Daten in der Sandbox getestet, inklusive Edge Cases und Bulk-Szenarien?
5. Dokumentiert? Gibt es eine Beschreibung im Flow, einen Eintrag im Admin-Wiki und bei Sub-Flows ein Übersichtsdiagramm?
6. Single Responsibility? Macht der Flow genau eine Sache? Oder wurde er mit Zusatzlogik überladen?
7. Review-Termin gesetzt? Ist ein Review-Datum eingetragen, an dem der Flow auf Aktualität und Performance geprüft wird?
8. Rollback-Plan? Wissen Sie, wie Sie den Flow deaktivieren und die Daten korrigieren, falls etwas schiefgeht?
Diese acht Punkte kosten fünfzehn Minuten vor dem Go-Live. Sie sparen Stunden bis Tage, wenn etwas schiefgeht. Und sie schaffen Vertrauen bei den Nutzern, weil sie sehen, dass Automatisierungen nicht einfach auf sie losgelassen werden.
Wie Sie eine Automatisierungsstrategie aufbauen
Einzelne Fehler zu vermeiden ist wichtig. Aber der nachhaltigere Ansatz ist eine Automatisierungsstrategie, die Fehler systemisch verhindert. Hier die Eckpfeiler, die sich in meinen Projekten bewährt haben:
Dokumentation: Jede Automatisierung wird in einem zentralen Register erfasst. Objekt, Trigger, Zweck, Owner, Erstelldatum, letzter Review. Kein Flow ohne Eintrag.
Testing-Standard: Kein Flow geht live ohne mindestens fünf Testszenarien, davon mindestens zwei Negativtests (was passiert, wenn ein Feld leer ist?). Fault Connector ist Pflicht.
Review-Rhythmus: Quartalsweise Automation-Review. Welche Flows laufen? Welche haben Fehler produziert? Welche sind überflüssig? Dieser Review sollte im Admin-Kalender als fester Termin stehen.
Naming Convention: Flows heißen nach dem Schema: [Objekt]_[Trigger]_[Zweck]. Zum Beispiel: Opportunity_AfterUpdate_StageChange_Notification. Keine kreativen Namen, keine Abkürzungen, die nur der Ersteller versteht.
Diese vier Eckpfeiler klingen nach Overhead. In der Praxis sparen sie enorm viel Zeit, weil Fehler schneller gefunden, Änderungen sicherer deployed und neue Teammitglieder schneller eingearbeitet werden.
Häufige Fragen
Wie erkenne ich, ob ein Flow zu komplex ist?
Wenn Sie einen Flow einem Kollegen nicht in fünf Minuten erklären können, ist er zu komplex. Gleiches gilt, wenn Sie selbst nach zwei Wochen Pause brauchen, um ihn zu verstehen. Mehr als 15 bis 20 Elemente in einem Flow ohne Sub-Flows sind ein weiteres Warnsignal.
Wann sollte ich einen Prozess automatisieren?
Erst wenn der Prozess mindestens vier Wochen stabil manuell läuft und keine nennenswerten Änderungen mehr zu erwarten sind. Automatisieren Sie nie einen Prozess, der sich noch in der Definition befindet. Sie gießen dann Instabilität in Ihren Flow.
Was ist ein Fault Connector und warum ist er wichtig?
Der Fault Connector in Salesforce Flows ist ein spezieller Pfad, der greift, wenn ein Element im Flow fehlschlägt. Ohne diesen Pfad bricht der Flow still ab. Mit einem Fault Connector können Sie den Fehler loggen, eine Benachrichtigung senden und den Datensatz in einem kontrollierten Zustand hinterlassen.
Brauche ich für jeden Flow eine Sandbox?
Ja, mindestens eine Developer Sandbox. Flows, die direkt in der Produktion gebaut und aktiviert werden, riskieren Datenverlust. Bei Record-Triggered Flows trifft jede Aktivierung auf alle bestehenden Datensätze, die den Trigger-Bedingungen entsprechen. Das lässt sich nicht rückgängig machen.
Wie viel Zeit sollte ich für Flow-Dokumentation einplanen?
Etwa dreißig Minuten pro Flow. Das umfasst die Beschreibung im Description-Feld von Salesforce, einen kurzen Eintrag im internen Admin-Wiki und bei komplexen Flows eine Skizze der Logik. Diese Investition zahlt sich beim ersten Änderungsauftrag vollständig aus.
Cheat Sheet: CRM-Automatisierungsfehler
Die sieben häufigsten Automatisierungsfehler mit konkreten Gegenmaßnahmen auf einer Seite. Drucken Sie sich das Cheat Sheet aus und prüfen Sie Ihre bestehenden Automationen gegen diese Liste.
Wie viele Automatisierungen sind zu viele?
Es gibt keine absolute Zahl. Entscheidend ist, ob jede Automatisierung dokumentiert, getestet und regelmäßig reviewed wird. In der Praxis sehe ich Probleme ab 30 bis 40 aktiven Flows pro Org, wenn keine Governance vorhanden ist. Mit einer sauberen Strategie können auch 100+ Flows stabil laufen.
Soll ich Process Builder durch Flows ersetzen?
Ja. Salesforce hat Process Builder offiziell als Legacy markiert und empfiehlt die Migration zu Flows. Die Migration sollte schrittweise erfolgen: Starten Sie mit den Process Buildern, die am häufigsten Fehler produzieren oder am schwierigsten zu warten sind. Salesforce bietet ein Migrate to Flow Tool, das bei einfachen Process Buildern gut funktioniert.
Sie haben das Gefühl, dass Ihre Automatisierungen gewachsen sind, aber niemand mehr den vollen Überblick hat? Genau das ist der Punkt, an dem ein Automatisierungs-Audit Klarheit schafft. Ich analysiere Ihre bestehende Flow-Architektur, identifiziere Redundanzen und konsolidiere, was zusammengehört. Ob es um die Bereinigung historisch gewachsener Automations geht oder um eine saubere Neustrukturierung: Melden Sie sich, und wir bringen Ordnung in Ihre Org.
