Wann eine eigene Salesforce-App bauen statt zu konfigurieren

Kurze Antwort: Erst konfigurieren, immer. Bauen Sie eigene Software, wenn die Logik ein echtes Unterscheidungsmerkmal ist, wenn sie außerhalb des Lebenszyklus eines einzelnen Datensatzes laufen muss, oder wenn Sie denselben Workaround zum dritten Mal nachbauen. Der Auslöser ist nicht Komplexität, sondern Wiederholung und Verantwortung: einmal konfigurierte Komplexität ist in Ordnung, vierteljährlich neu erklärte Komplexität nicht.

Was unterscheidet konfigurieren, erweitern und bauen?

• Konfigurieren: Standardobjekte, Page Layouts, Validierungsregeln, Flow. Kein deploybarer Code, und es wandert mit der Plattform mit.
• Erweitern: eigene Objekte und Felder plus etwas Apex oder eine Lightning Web Component rund um einen weitgehend standardisierten Prozess. Weiterhin Salesforce-förmig.
• Bauen: eine entworfene Anwendung. Eigenes Datenmodell, Services, Tests und Releasezyklus, ob als Apex und LWC in Ihrer Org oder als paketiertes Produkt.

Die meisten Diskussionen über "bauen oder konfigurieren" drehen sich in Wahrheit um die mittlere Kategorie, wo die ehrliche Antwort meist lautet: erweitern statt ein Projekt starten.

Warum bleibt Konfigurieren die richtige Voreinstellung?

Die Empfehlung von Salesforce ist seit zehn Jahren dieselbe: Prüfen Sie die nativen und deklarativen Funktionen, bevor Sie Code schreiben. Deklarative Arbeit trägt keinen Testcode, kein Repository und keine Upgrade-Steuer und wandert mit jedem Release automatisch mit. Auch die Limits verhalten sich anders. Deklaratives stößt an Design-Limits, etwa wie viele Regeln auf einem Objekt liegen dürfen, Code dagegen an Ausführungs-Governor-Limits wie die Zahl der SOQL-Abfragen, die sich deutlich schwerer wegplanen lassen (Salesforce Developers).

Zudem steigt der Boden. Workflow Rules und Process Builder werden nach dem 31. Dezember 2025 nicht mehr unterstützt, neue lassen sich nicht mehr anlegen, und Salesforce verweist auf das Werkzeug Migrate to Flow (Salesforce Ben). Was Sie heute bauen, konkurriert mit dem, was die Plattform morgen aufsaugt. Das spricht für weniger bauen, nicht für gar nicht bauen.

Wo hört Konfiguration auf, sich zu lohnen?

Das sind die fünf Stolperdrähte, die wir nutzen. Einer ist ein Gespräch. Zwei oder mehr sind eine Entscheidung.

1. Der Flow ist ein Programm geworden. Wenn niemand das Ergebnis durch Lesen vorhersagen kann und eine Änderung einen sorgfältigen Nachmittag kostet, haben Sie bereits Software. Nur in einem Format ohne Tests, ohne Code-Review und ohne lesbaren Diff.
2. Die Anforderung ist ein Datenmodell, kein Bildschirm. Auswertungen, die drei unverbundene Objekte verbinden müssen, oder eine Hierarchie, die das Standardmodell nicht ausdrückt, sind ein Entwurfsproblem. Konfiguration erzeugt dann eine Form, die Sie für immer umgehen.
3. Das Verhalten lebt außerhalb eines Datensatzlebenszyklus. Geplante Verarbeitung, Ereignisaufnahme in Menge, Abgleich zwischen Systemen, Wiederholungen und Idempotenz. Deklarative Automatisierung wird von Datensätzen ausgelöst, diese Dinge nicht.
4. Die Logik ist Ihr Unterschied und ändert sich oft. Preisregeln, Routing-Intelligenz, Berechtigungslogik. Alles, wo 10% besser als der Wettbewerb zählt, verdient Tests, Versionierung und Verantwortliche.
5. Sie zahlen dreimal dafür. Derselbe Workaround, neu gebaut im zweiten Land, in der zweiten Business Unit, in der dritten Kunden-Org. Das ist keine Konfiguration mehr, das ist ein unpaketiertes Produkt.

Wie vergleicht man die echten Kosten ehrlich?

Nicht Baukosten gegen Konfigurationskosten, sondern drei Jahre Betrieb auf beiden Seiten.

• Konfiguration trägt: Admin-Stunden je Änderung, ungemessenes Regressionsrisiko, Einarbeitungskosten für jede neue Admin-Person, die den Workaround lernen muss, und eine Obergrenze dessen, was je automatisierbar ist.
• Eigenentwicklung trägt: Anfangsaufwand, Testabdeckung, Code-Review, einen Upgradepfad über drei Releases pro Jahr, und das Risiko, dass die Plattform Ihre Funktion nächstes Jahr kostenlos liefert.

Die Entscheidung kippt fast immer an einer Zahl, die niemand notiert: wie oft sich der Prozess pro Jahr ändert. Häufige Änderung spricht für Code mit Tests, denn Tests sind der Weg, etwas sicher zu ändern. Seltene Änderung spricht für Konfiguration, weil niemand den Muskel pflegen muss.

Was heißt "bauen" heute überhaupt?

Selten eine Anwendung von null. In der Praxis ist es eine von vier Formen: Apex und Lightning Web Components in der Org; eine paketierte Komponente, die Sie in mehrere Orgs installieren; ein Managed Package auf der AppExchange; oder ein Dienst außerhalb von Salesforce, den die Org über eine API oder einen MCP-Server aufruft, mit einer Agent Action davor.

Die paketierten Varianten zählen mehr, als Teams erwarten. Als Package zu bauen erzwingt Versionierung, Upgradepfad und Isolation, die man sonst überspringt, und macht das zweite und dritte Deployment fast kostenlos. Diese Disziplin bringen wir aus der Produktarbeit in Implementierungen: Weil Tekunda als PDO AppExchange-Produkte baut und ausliefert, erbt unsere Implementierungsarbeit wiederverwendbare, getestete Komponenten, statt sie jedes Mal neu zu bauen.

Wie verhindert man, dass die Eigenentwicklung zum nächsten Chaos wird?

1. Geben Sie ihr am ersten Tag Verantwortliche und einen Abkündigungsplan. Code ohne Verantwortliche wird zu Konfiguration, die niemand lesen kann.
2. Legen Sie Konfigurationswerte in Custom Metadata, nicht in den Code. Der Sinn ist, dass das Business sie ohne Sie ändern kann.
3. Schreiben Sie die Tests als Spezifikation, nicht als Abdeckungssteuer.
4. Prüfen Sie jedes Release, ob die Plattform aufgeholt hat. Eigenen Code zu löschen ist ein legitimes Ergebnis.

Gut gemacht ist der Gewinn keine elegante Architektur, sondern Betrieb. Für ASSA ABLOY haben wir die wöchentlichen Cases von 3.000 auf 350 gesenkt, 93% weniger, über 11.000 vernetzte Geräte und bis zu 2,5 Millionen Ereignisse pro Woche, in drei Märkten und ohne zusätzliches Supportpersonal. Dieses Volumen wäre nie ein Flow geworden. Wenn Sie vor derselben Entscheidung stehen, sprechen Sie mit uns vor dem Bauen, nicht während der Rettung.

FAQ

Ist Eigenentwicklung immer teurer als Konfiguration?

Nein. Sie ist teurer im Start und oft billiger in der Änderung. Vergleichen Sie drei Jahre Betrieb, inklusive der Admin-Stunden und des Regressionsrisikos, die Konfiguration still verbraucht.

Wann ist etwas zu komplex für Flow?

Nehmen Sie einen menschlichen Test statt einer Elementzählung: Wenn eine fähige Admin-Person das Verhalten nicht durch Lesen vorhersagen und nicht in einer Stunde sicher ändern kann, ist es Software geworden.

Selbst bauen oder auf der AppExchange kaufen?

Kaufen Sie, wenn die Fähigkeit Standardware ist und eine gelistete App den Großteil abdeckt. Bauen Sie, wenn die Logik der Grund ist, warum Kunden Sie wählen.

Schneidet uns Eigenentwicklung von Plattform-Upgrades ab?

Nicht, wenn sie als Package mit Version und Testsuite gebaut ist. Upgrades blockiert undokumentierter Code ohne Verantwortliche, und das passiert Konfiguration genauso.