Was technische Schulden in Salesforce sind und warum KI-Agenten sie sichtbar machen
Zuletzt geprüft: 14. Oktober 2026
Technische Schulden in Salesforce sind Konfiguration, Automatisierung und Code, die jede weitere Änderung an einer Org aufwendiger machen. Sie sind für frühere Anforderungen, unter Zeitdruck oder mit dem damaligen Funktionsumfang der Plattform entstanden. Jede gewachsene Salesforce-Org hat solche Schulden. Über die Qualität der Arbeit im Team sagen technische Schulden wenig aus.
Spürbar werden technische Schulden, sobald sich die Org verändern soll. Eine neue Anforderung dauert länger, weil das Team erst verstehen muss, was schon existiert. Mit KI-Agenten kommt ein zweiter Effekt hinzu, denn ein Agent arbeitet mit genau dem Kontext, den die Org ihm bietet.
Wie sich technische Schulden in Salesforce von denen einer Codebasis unterscheiden
In Salesforce liegen technische Schulden vor allem in Metadaten, also in Feldern, Flows, Berechtigungen, Seitenlayouts und Reports. Apex-Code macht in vielen Orgs nur einen Teil davon aus.
Ein großer Teil dieser Metadaten entsteht per Klick im Setup, oft durch Admins, Developer und Partner zur selben Zeit. Ein neues Feld kostet wenige Minuten. Welche Flows, Reports und Apex-Klassen ein Feld verwenden, lässt sich über die Metadaten nachvollziehen. Ob eine dieser Abhängigkeiten von einer Änderung fachlich betroffen ist, zeigen die Metadaten dagegen nicht. Fehlt die Feldbeschreibung, kann das Team den fachlichen Bezug falsch einschätzen. Eine Anpassung für den Vertrieb verändert dann einen Prozess, auf den sich der Kundenservice verlässt.
| Klassische Codebasis | Salesforce-Org | |
|---|---|---|
| Wo die Schulden liegen | Im Quellcode und seinen Abhängigkeiten | In Metadaten wie Feldern, Flows, Berechtigungen, Layouts, Reports und Code |
| Wer sie erzeugt | Vor allem Developer | Admins, Developer, Partner und installierte Pakete |
| Wie sie sichtbar werden | Compiler, Tests und statische Analyse | Oft erst bei einer Folgeanforderung, die auf eine schwer erweiterbare Lösung trifft |
| Was den Abbau bremst | Fehlende Tests | Fehlender fachlicher Kontext zu Abhängigkeiten zwischen Metadaten |
Trotz dieser Unterschiede funktionieren die Praktiken, mit denen Softwareteams technische Schulden abbauen, auch in Salesforce. Ob ein Team konfiguriert oder programmiert, ändert daran wenig.
Warum sich in Salesforce-Orgs technische Schulden ansammeln
Technische Schulden in Salesforce haben drei typische Ursachen. Die Plattform entwickelt sich mit drei Releases pro Jahr weiter. Über die Jahre arbeiten wechselnde Teams und Partner an derselben Org. Dazu kommen Anforderungen, die schneller live gehen müssen, als eine skalierbare Umsetzung Zeit braucht.
Am deutlichsten zeigt sich die Weiterentwicklung der Plattform bei der Automatisierung. Salesforce lässt schon länger keine neuen Workflow-Regeln und keine neuen Prozesse im Prozessgenerator (Process Builder) mehr zu. Seit dem 31. Dezember 2025 unterstützt Salesforce beide Werkzeuge nicht mehr. Bestehende Automatisierungen laufen weiter, Fehler darin behebt Salesforce aber nicht mehr. Was vor vielen Jahren das empfohlene Vorgehen war, gilt heute als Altlast.
Ein typisches Beispiel ist ein zentrales Objekt in einer älteren Org. In den ersten Jahren setzt eine Workflow-Regel dort ein Feld. Für eine spätere Anforderung reicht die Workflow-Regel nicht mehr aus, deshalb kommt ein Prozess im Prozessgenerator hinzu. Danach implementiert ein anderes Team einen Flow und ein Integrationsprojekt ergänzt einen Apex-Trigger. Jede neue Anforderung an dieses Objekt beginnt heute damit, das Zusammenspiel der vier Automatisierungen zu verstehen.
Salesforce beschreibt diese Lage ohne Vorwurf. Laut dem Decision Guide zu Record-Triggered Automation laufen in gewachsenen Orgs häufig Flows und Apex-Trigger auf demselben Objekt. Als Ursache nennt der Guide die Weiterentwicklung der Plattform oder „legacy technical debt“. Architekten sollen einen solchen Zustand als bewusst getragenen Kompromiss behandeln, der kein Endzustand ist.
Im Projektalltag kommt Zeitdruck hinzu. Typische Auslöser sind feste Go-Live-Termine, Änderungswünsche kurz vor einem Release und Projektpläne ohne Zeit für Nacharbeit. Muss ein Projekt zum Quartalsende live gehen, erweitert jemand ein bestehendes Profil, statt ein passendes Permission Set anzulegen. Eine solche Abkürzung kann eine bewusste und vertretbare Entscheidung sein. Teuer wird die Abkürzung, wenn niemand sie festhält und die nächste Anforderung auf ihr aufsetzt. Installierte Pakete bringen außerdem eigene Felder und Automatisierungen mit. Wird das alte Paket nach einem Wechsel des Anbieters nicht deinstalliert, bleiben diese Felder und Automatisierungen in der Org.
Woran du technische Schulden in deiner Org erkennst
Technische Schulden zeigen sich in der Org an wiederkehrenden Merkmalen. Für sich genommen ist keines davon ein Fehler. Zusammen machen die Merkmale sichtbar, wo Änderungen mehr Aufwand kosten als nötig:
- mehrere Automatisierungsarten auf demselben Objekt, etwa Workflow-Regeln, Flows und Apex-Trigger nebeneinander
- Felder, die seit Jahren niemand befüllt, und Felder ohne Beschreibung
- umfangreiche Profile, deren Rechte sich in wiederverwendbare Permission Sets aufteilen ließen
- Apex-Klassen auf alten API-Versionen
- fest eingetragene URLs und Datensatz-IDs in Code und Formeln
- Reports und Dashboards, die niemand mehr öffnet
Der Salesforce Health Check erkennt keines dieser Merkmale, weil er Sicherheitseinstellungen gegen einen Standard bewertet. Welche Fragen der Health Check beantwortet und welche nicht, beschreibt unser Beitrag Was der Salesforce Health Check zeigt und was er verschweigt.
Was technische Schulden kosten, sobald KI-Agenten die Org lesen
Sobald KI-Agenten mit einer Org arbeiten, bestimmen technische Schulden die Qualität der Ergebnisse. Das gilt für KI-Agenten im Kundenkontakt genauso wie für KI-Coding-Agenten, die Änderungen an der Org schreiben.
Ein KI-Agent, der Kundenanfragen beantwortet oder Vorgänge für Mitarbeitende erledigt, liest Felder, Feldbeschreibungen, Datensätze und Berechtigungen. Gibt es drei Felder für denselben Kundenstatus, muss der Agent raten, welches Feld gilt. Fehlt eine Feldbeschreibung, kennt der Agent nur den Feldnamen und leitet die Bedeutung daraus ab.
KI-Coding-Agenten lesen die Org auf andere Weise. Ein KI-Coding-Agent nimmt bestehende Flows und bestehenden Apex-Code als Vorlage, wenn er neue Automatisierungen schreibt. Findet der Agent in der Org überwiegend ältere Lösungsansätze, überträgt er sie in neue Änderungen. Wie das bei Flows aussieht, zeigt unser Beitrag zu KI-Coding-Agenten und aktuellen Flow Best Practices.
Guter Kontext hilft auch in die andere Richtung. Auch Menschen deuten ein Feld manchmal falsch, etwa wenn der Feldname mehr verspricht, als das Feld enthält. Steht diese Annahme in einer Anforderung, fällt der Fehler oft erst im Test auf. Ein KI-Coding-Agent, der klare Feldbeschreibungen liest, kann den Widerspruch zwischen Anforderung und Metadaten schon vor der Umsetzung bemerken. In unseren Projekten ist genau das schon mehrfach passiert.
Technische Schulden, die bisher vor allem Menschen Zeit gekostet haben, wirken mit KI-Agenten in jeder Antwort und jeder generierten Änderung weiter. Deshalb lohnt sich vor jedem KI-Vorhaben die Frage, in welchen Bereichen der Org ein KI-Agent sicher starten kann und wo er es noch schwer haben wird. Bereiche mit wenig technischen Schulden sind gute erste Einsatzorte.
Technische Schulden sichtbar machen und priorisieren
Am Anfang des Abbaus steht eine Bestandsaufnahme der ganzen Org, weil technische Schulden in Salesforce über viele Bereiche verteilt sind. Den Salesforce Optimizer, der lange eine solche Übersicht geliefert hat, hat Salesforce mit den Releases Winter '26 und Summer '26 abgeschaltet.
Nicht jede Altlast muss weg. Der Abbau lohnt sich zuerst dort, wo technische Schulden die nächste geplante Änderung bremsen oder einem KI-Anwendungsfall im Weg stehen. Ein ungenutztes Feld auf einem Objekt, das sich selten ändert und das kein KI-Agent liest, kann warten. Drei Felder für denselben Status auf dem Objekt, das ein KI-Agent lesen soll, gehören nach vorn.
Bei dieser Reihenfolge hilft das Plattform-Assessment. Wir ordnen jeden Befund einer von drei Gruppen zu: Quick Wins, größere Aufräumarbeiten und strukturelle Themen, die erst mit einem künftigen Vorhaben anstehen. Die ersten beiden Gruppen kann dein Team direkt in ein Refactoring-Backlog übernehmen. Die strukturellen Themen gehören in das Technical Refinement des Vorhabens, das sie berührt.
Technische Schulden im Sprint-Alltag abbauen
Am verlässlichsten baut ein Team technische Schulden ab, wenn der Abbau in jedem Sprint einen festen Platz hat. In Softwareteams ist das seit Langem gängige Praxis. Salesforce-Teams können die folgenden Bausteine übernehmen.
Ein eigenes Refactoring-Backlog
Jede gefundene Altlast bekommt einen Eintrag in einem eigenen Refactoring-Backlog, getrennt vom Backlog für neue Features. So geht ein Befund nicht in Notizen oder Chatverläufen verloren. Das Team schätzt und plant Altlasten wie jede andere Aufgabe.
Technical Refinement für gemeinsame Standards
Im Technical Refinement legt das Team neben anstehenden Anforderungen auch fest, welche technischen Standards künftig gelten. Seit Spring '25 gibt es Genehmigungsprozesse in Flow (Flow Approval Processes). Ein Team kann im Refinement beschließen, neue Genehmigungen ab sofort nur noch in Flow umzusetzen, obwohl die klassischen Genehmigungsprozesse weiterhin funktionieren. Bestehende Genehmigungsprozesse wandern dann Schritt für Schritt ins Refactoring-Backlog.
Bei Workflow-Regeln und Prozessgenerator haben viele Teams gewartet, bis Salesforce eine Frist gesetzt hat, und mussten dann unter Zeitdruck migrieren. Ein Team, das früher entscheidet, plant die Migration in seinen normalen Sprints.
Ein festes Budget in jedem Sprint
Salesforce empfiehlt im Well-Architected Framework, bewusst Entwicklungskapazität für den Abbau technischer Schulden zu reservieren. Ein Team, das seine gesamte Kapazität in neue Features steckt, hat laut Salesforce keine Zeit für Verbesserungen und häuft dadurch technische Schulden an.
In der Praxis hat sich ein fester Anteil jedes Sprints bewährt, der nur für Einträge aus dem Refactoring-Backlog reserviert ist. Unserer Erfahrung nach sind 15 Prozent der Kapazität ein guter Wert. Weil der Anteil feststeht, muss das Team ihn nicht in jedem Sprint gegen das nächste Release verhandeln. Teams ohne Sprints übertragen das Prinzip auf einen festen Anteil pro Monat oder pro Salesforce-Release.
Teamregeln, die auch KI-Coding-Agenten lesen
Was das Team im Technical Refinement beschließt, gehört in schriftliche Teamregeln, etwa in die Definition of Done oder in ein Dokument mit den vereinbarten Standards. Solche Regeln helfen neuen Teammitgliedern beim Einstieg. Gleichzeitig dienen die Teamregeln KI-Coding-Agenten als Projektvorgabe. Ein KI-Coding-Agent, der die Regel „neue Genehmigungen nur in Flow“ kennt, schlägt deutlich seltener einen klassischen Genehmigungsprozess vor.
Technische Schulden dauerhaft im Blick behalten
Technische Schulden entstehen laufend neu, auch in einem Team mit festem Budget. Jedes Release, jedes Projekt und jede KI-generierte Änderung verändert die Org. Salesforce empfiehlt im Well-Architected Framework deshalb, Konfigurationsabweichungen quartalsweise zu erkennen und zu beheben, damit sich keine Konfigurationsschulden ansammeln.
Wiederkehrende Plattform-Reviews setzen genau diesen Rhythmus um. Jedes Review vergleicht die Org mit dem letzten Referenzzustand und zeigt, welche technischen Schulden neu entstanden sind. So sieht das Team, ob das feste Budget im Sprint mehr abbaut, als gleichzeitig neu entsteht.
Mit dem Plattform-Assessment entsteht das Refactoring-Backlog, das feste Budget baut es Sprint für Sprint ab. Die Reviews zeigen in jedem Quartal, ob der Abbau mit den Veränderungen in der Org Schritt hält.