ENTSCHEIDUNGSPRINZIP
Die bessere Lösung bleibt auch nach dem Go-live beherrschbar.
Die Frage ist nicht, wie viel Code eine Lösung enthält. Entscheidend ist, ob sie den Bedarf sauber erfüllt und Teams sie auch bei späteren Änderungen noch verstehen und kontrollieren können.
ENTSCHEIDUNGSPRINZIP
Nicht möglichst wenig Custom – sondern passend zum Bedarf
Salesforce-Standard sollte genutzt werden, wenn er den fachlichen Bedarf sinnvoll abdeckt. Reicht das nicht, können Low-Code oder Custom die bessere Wahl sein – solange der zusätzliche Aufwand nachvollziehbar begründet ist.
Die Folgen für Betrieb und Weiterentwicklung mitbewerten
Eine heute schnelle Lösung kann später teuer werden, wenn Berechtigungen, Automatisierungen, Tests oder Verantwortlichkeiten unnötig kompliziert werden. Deshalb gehört der spätere Betrieb in die Entscheidung.
Die beste Lösung ist die, deren Nutzen und zusätzliche Komplexität in einem vernünftigen Verhältnis stehen.
AUSNAHMEN
Die bewusste Ausnahme sichtbar halten
Eine Abweichung vom Standard ist nicht automatisch ein Fehler. Problematisch wird sie erst, wenn später niemand mehr weiß, warum sie nötig war, welche Alternative geprüft wurde und unter welchen Annahmen sie weiterhin gilt.
Dokumentieren Sie deshalb bewusst gewählte Ausnahmen mit Begründung, Owner und einem klaren Prüfauslöser.
Ein konkretes Architekturbeispiel können Sie im Szenario Standard oder individuell? durchspielen.
Drei Lösungswege im Vergleich
Standard, Low-Code und Custom haben jeweils ihren Platz. Entscheidend ist, welche Variante den Bedarf mit vertretbarer Komplexität und langfristig beherrschbarem Betrieb erfüllt.
Die Entscheidung ist kein Ranking. Jede Variante ist sinnvoll, wenn sie bewusst gewählt und über den Lebenszyklus beherrschbar bleibt.
ENTSCHEIDUNG FESTHALTEN
Nutzen, Betriebsfolgen und Prüfauslöser gemeinsam dokumentieren.
Eine Lösungsentscheidung sollte nicht nur die gewählte Variante festhalten. Wichtig ist auch, welchen Nutzen sie schafft, welche zusätzliche Komplexität entsteht und wann die Entscheidung erneut geprüft werden sollte.
- Welchen konkreten fachlichen Nutzen schafft die gewählte Variante?
- Welche neuen Abhängigkeiten, Berechtigungen oder Betriebsaufgaben entstehen?
- Welche Alternative wurde verworfen – und warum?
- Welche Änderung würde eine erneute Bewertung auslösen?
LEBENSZYKLUS
Die Entscheidung über den Lebenszyklus prüfen
Eine Lösung kann heute sinnvoll sein und später trotzdem zum Problem werden. Prüfen Sie deshalb nicht nur die Umsetzung, sondern auch Betrieb, Weiterentwicklung und mögliche Ablösung.
Passt die Lösung weiterhin zum fachlichen Bedarf?
Sind Abhängigkeiten, Berechtigungen und Verantwortlichkeiten noch nachvollziehbar?
Lassen sich Änderungen zuverlässig testen und ausrollen?
Ist der Betriebs- und Supportaufwand weiterhin angemessen?
Weitere Prüfkriterien (2)
Gibt es neue Plattformfunktionen, die die Ausnahme inzwischen ersetzen könnten?
Hat sich Volumen, Risiko oder Nutzung so verändert, dass die Entscheidung neu bewertet werden sollte?
NÄCHSTE SCHRITTE
Die nächsten konkreten Schritte
01
Bedarf verstehen
Beschreiben Sie zuerst das fachliche Ziel und die Einschränkungen, die wirklich gelöst werden müssen.
02
Optionen abwägen
Vergleichen Sie Standard, Low-Code und Custom nach denselben Kriterien – nicht nur nach Umsetzungsaufwand.
03
Betrieb absichern
Dokumentieren Sie Auswirkungen, Owner und Prüfauslöser, bevor die Lösung dauerhaft in den Betrieb geht.
Standard zuerst – aber nicht um den Preis einer Lösung, die den eigentlichen Bedarf verfehlt.
Häufige Fragen zur Lösungswahl
Ist Custom grundsätzlich schlechter als Standard?
Nein. Custom ist dann sinnvoll, wenn Standard und Low-Code den fachlichen Bedarf nicht sauber abdecken. Entscheidend ist, dass der zusätzliche Aufwand für Entwicklung, Tests und Betrieb bewusst akzeptiert wird.
Wann ist Low-Code die bessere Wahl?
Wenn Plattformfunktionen ergänzt werden müssen, ohne eine vollständig eigene technische Lösung aufzubauen. Trotzdem sollten Abhängigkeiten, Automatisierungen und spätere Wartung genauso kritisch betrachtet werden wie bei Custom Code.
Wie verhindern wir, dass eine Ausnahme dauerhaft zum Sonderweg wird?
Dokumentieren Sie Begründung, Owner und Prüfauslöser. Sobald sich Plattformfunktionen, Anforderungen oder Risiken ändern, kann die Ausnahme bewusst neu bewertet werden.
Quellen und weitere Informationen
Produktnamen und Funktionen können sich ändern. Die verlinkten Primärquellen bilden die Grundlage für diese Einordnung und werden vor einer Veröffentlichung erneut geprüft.
- Salesforce Well-Architected – ÜberblickGeprüft am
Unterstützt Kriterien für bewusste Plattform- und Architekturentscheidungen über Nutzen, Kontrolle und Lebenszyklus; aktuelle Plattformgrenzen erneut prüfen.
- Salesforce Well-Architected – IntentionalGeprüft am
Unterstützt Kriterien für bewusste Plattform- und Architekturentscheidungen über Nutzen, Kontrolle und Lebenszyklus; aktuelle Plattformgrenzen erneut prüfen.
- Salesforce Platform Decision GuidesGeprüft am
Unterstützt Kriterien für bewusste Plattform- und Architekturentscheidungen über Nutzen, Kontrolle und Lebenszyklus; aktuelle Plattformgrenzen erneut prüfen.
Themen dieses Beitrags
SO KÖNNTE ES IM ALLTAG AUSSEHEN
Drei Ansichten, die Lösungsentscheidungen nachvollziehbar machen.
Fiktive Arbeitsbereiche zeigen Entscheidung, Abhängigkeiten und den nächsten Betriebsschritt. Redaktionelle Illustrationen, keine Live-Produktscreenshots.
Angebotsprüfung · Berechtigungssatz
Illustrative konfigurierte Setup-Ansicht: Objektzugriff und Freigaberecht sind getrennt.
Mit dem Finger wischen oder mit gedrückter Maustaste ziehen. Alternativ die Bildauswahl oder Pfeiltasten nutzen.
Bild 1 von 3: Angebotsprüfung · Berechtigungssatz
Passend weiterlesen
Salesforce-Integration: Robust statt Punkt-zu-Punkt
Eine direkte Verbindung zwischen zwei Systemen kann völlig sinnvoll sein. Problematisch wird es erst, wenn mit jeder neuen Anforderung weitere Sonderwege entstehen und niemand mehr klar sagen kann, wer für Daten, Fehler und Änderungen verantwortlich ist. Robuste Integration beginnt deshalb nicht mit einem bestimmten Tool, sondern mit klaren Systemgrenzen, Datenverträgen, Fehlerwegen und Betriebsverantwortung.
Beitrag lesen
Angebote in Salesforce: Welche Revenue-Lösung passt?
Ob Standardfunktionen, CPQ oder eine umfassendere Revenue-Lösung sinnvoll sind, hängt nicht zuerst vom Produktnamen ab. Entscheidend ist, wie Produkte, Preise, Freigaben, Verträge und nachgelagerte Systeme heute zusammenspielen. Je klarer diese Regeln und Systemgrenzen vorab sind, desto leichter lässt sich der passende Lösungsumfang wählen.
Beitrag lesen
KI in Salesforce: Welche Aufgaben sich wirklich lohnen
Nicht jede Aufgabe wird durch KI besser. Sinnvoll ist KI dort, wo Kontext verstanden, Informationen zusammengeführt oder ein Entwurf vorbereitet werden muss – und wo der Nutzen gegenüber einer einfachen Automatisierung wirklich erkennbar ist. Der beste Einstieg beginnt deshalb nicht mit Agentforce, sondern mit einer klar begrenzten Aufgabe und einem überprüfbaren Ergebnis.
Beitrag lesen