Ich habe vor zwei Jahren eine Salesforce-Org geerbt, in der jedes neue Geschäftskonzept als Custom Object angelegt wurde. 87 Custom Objects insgesamt. Niemand wusste mehr, was wofür da war. Reports waren ein Albtraum. Wir haben das Modell auf 12 echte Objects reduziert. Der Rest wurde zu Feldern auf Standard-Objekten oder zu Picklist-Werten.
Das Datenmodell ist das Fundament Ihrer Org. Ist es krumm, baut alles darüber krumm. Reports, Berechtigungen, Migrations, Integrationen, Sharing. Alles wird teurer und langsamer, je länger das Modell mitwächst. Hier sind die sieben Prinzipien, die ich in jedem Salesforce-Projekt anwende.
1. Custom Object oder Custom Field auf Standard-Objekt?
Die häufigste Sünde: jedes neue Konzept landet als eigenes Object. Ein Kunde wollte „Kundenbriefe" tracken und legte ein Custom Object Kundenbrief__c an. Mit eigener Page Layout, eigenen Permission Sets, eigenem Tab. Drei Felder hätten gereicht: Brief-Datum, Brief-Typ (Picklist), Brief-Text. Auf dem Account.
Faustregel: Wenn das neue Konzept eine 1:1-Erweiterung eines Standard-Objekts ist und keine eigene Lifecycle, eigene Permissions oder eigene Reports braucht, sind es Felder. Punkt.
Eigenes Custom Object lohnt sich nur, wenn mindestens drei dieser Punkte zutreffen: eigene Berechtigungen, eigener Lebenszyklus, n-zu-n-Beziehung zu anderen Objects, eigene Page Layouts, eigene Reports oder Dashboards, eigener Workflow.
2. Lookup oder Master-Detail: Die Folgen verstehen
Lookup und Master-Detail sehen im Setup gleich aus. Im Verhalten sind sie zwei verschiedene Welten. Ich erlebe regelmäßig, dass Admins eine Lookup-Beziehung anlegen und sich dann wundern, warum Roll-up Summary Fields fehlen oder Sharing nicht greift.
Master-Detail
Das Child existiert nicht ohne Parent. Löscht man den Parent, geht das Child mit (Cascade Delete). Sharing wird vom Parent geerbt, das Child hat kein eigenes OWD. Roll-up Summary Fields auf dem Parent funktionieren. Maximal zwei Master-Detail-Beziehungen pro Objekt.
Lookup
Lose Verbindung. Child existiert auch ohne Parent. Kein Cascade Delete (außer Sie aktivieren ihn explizit). Eigenes Sharing-Modell, eigene Roles. Keine Roll-ups (außer Sie nutzen Apex Triggers oder Declarative Roll-up Tools). Bis zu 40 Lookups pro Objekt.
3. Junction Objects: M:N richtig modellieren
Eine Many-to-Many-Beziehung in Salesforce braucht ein Junction Object. Das ist ein Custom Object mit zwei Master-Detail-Beziehungen, eine zu jedem der beiden zu verbindenden Objects.
Beispiel aus einem Beratungsprojekt: Ein Kunde wollte Projekte (Custom Object) mit mehreren Beratern verknüpfen, und jeder Berater sollte mehrere Projekte haben können. Falsche Lösung: ein Multi-Picklist auf dem Projekt mit allen Berater-Namen. Hat funktioniert, bis der erste Berater den Namen änderte und die Daten inkonsistent wurden.
Richtige Lösung: ein Junction Object Project_Consultant__c mit Master-Detail zu Project__c und zu User (oder Contact, je nach Setup). Dort kann man zusätzlich rollenspezifische Felder unterbringen: Allokation in Prozent, Start- und Enddatum, Rolle im Projekt.
// Alle Berater eines Projekts mit Allokation
SELECT Project__c, Consultant__c, Allocation_Percent__c
FROM Project_Consultant__c
WHERE Project__c = 'a0X1...'
// Alle Projekte eines Beraters
SELECT Project__r.Name, Allocation_Percent__c, Start_Date__c
FROM Project_Consultant__c
WHERE Consultant__c = '0051...'4. External IDs: Die unsichtbare Migrations-Lebensader
Jedes Objekt, das jemals migriert oder integriert wird, braucht ein External ID Field. Das ist ein Text- oder Number-Field mit den Eigenschaften External ID + Unique. Es speichert die ID aus dem Quellsystem (SAP, alte CRM-Datenbank, ERP, was auch immer).
Warum kritisch: Beim Re-Import oder bei einer Integration matcht Salesforce über die External ID, nicht über den Salesforce-internen 18-stelligen Record-Identifier. Sie können dadurch Upserts machen, ohne die Salesforce-ID kennen zu müssen.
Mehr zur Mechanik der internen IDs habe ich im Artikel zu Salesforce-IDs verstehen erklärt. Für die Migrations-Praxis ist die External ID der eine Hebel, der alles einfacher macht.
Ich setze auf jedem produktiv genutzten Custom Object mindestens eine External ID. Selbst wenn aktuell nichts migriert wird. Die Kosten sind null, der Nutzen bei der nächsten Integration ist enorm.
5. Naming Conventions: Englisch, Singular, konsistent
Benennung ist nicht Geschmack, sondern Architektur. Eine Org mit Project__c, Projekt__c und Project_de__c (alle drei habe ich schon gesehen) ist nicht mehr zu retten ohne Daten-Migration.
Meine Regeln
API-Namen immer Englisch und Singular: Project__c, Invoice__c, Maintenance_Ticket__c. Nicht Projekt__c, nicht Invoices__c. Englisch deshalb, weil alle Salesforce-Standards Englisch sind. Singular, weil das Object einen Datensatz repräsentiert.
Field-Namen folgen dem gleichen Prinzip: Start_Date__c, Total_Amount__c, Customer_Type__c. Kein Camel-Case, keine Umlaute, keine Sonderzeichen. Salesforce konvertiert Spaces in Unterstriche, aber explizit ist besser.
Die Labels (was der User sieht) dürfen Deutsch sein: Projekt, Rechnung, Wartungs-Ticket. Über die Translation Workbench kann man Labels mehrsprachig pflegen, API-Namen sind unveränderlich. Genau deshalb müssen sie sprachneutral und korrekt sein.
6. Field-Typ: Text, Picklist oder Lookup?
Drei Datentypen, die Anfänger oft falsch wählen. Die Wahl entscheidet über Datenqualität, Berichtsfähigkeit und langfristige Wartbarkeit.
Text
Nur, wenn der Wert wirklich unstrukturiert und einmalig ist. Notizen, Beschreibungen, freie Eingaben. Nicht für Status, Kategorie, Land, Branche. Wenn fünf User „Bayern", „bayern", „BY" und „Bay." eintragen, wird Reporting unmöglich.
Picklist
Wenn die Werte aus einem geschlossenen Satz kommen, der sich selten ändert: Status, Priorität, Kategorie. Bis ca. 30 Werte ist Picklist die beste Wahl. Global Picklists wenn der gleiche Werteset auf mehreren Objects gebraucht wird (z.B. Branche).
Lookup
Wenn die Werte selbst Records mit eigenen Daten sind und sich häufig ändern: Account, Produkt, Kategorie als eigenes Object. Vorteil: Werte können zentral gepflegt werden, jeder neue Wert ist sofort überall verfügbar, und man kann Felder am Lookup-Ziel mitziehen.
Der häufigste Fehler
Picklist statt Lookup gewählt, weil es im Setup schneller geht. Sechs Monate später hat die Picklist 200 Werte, niemand weiß mehr welche aktiv sind, und ein User wollte zu einem Wert eine Beschreibung speichern. Dann ist Refactoring teuer. Picklist auf Lookup umzustellen heißt: Daten migrieren, Reports anpassen, Flows anpassen.
CRM-Checkliste für den Mittelstand Kostenlos
7 Punkte, die Sie vor jeder CRM-Entscheidung prüfen sollten. Kompakt, praxisnah, sofort anwendbar.
7. Big Objects: Wann sich der Aufwand lohnt
Big Objects sind die Salesforce-Antwort auf Audit-Logs, Sensor-Daten oder Historien-Tabellen mit Millionen von Records. Sie speichern Daten kostengünstig, brauchen aber Async SOQL für Queries und unterstützen keine Standard-UI.
Wann lohnt sich ein Big Object? Konkret: ab ca. 10 Millionen Records, die nur selten gelesen und nie editiert werden. Beispiele aus meinen Projekten: Maschinen-Telemetrie (alle 5 Minuten ein Datenpunkt pro Anlage), historische Buchungssätze, externe Audit-Trails.
Was Big Objects nicht können: Standard Reports, Triggers, Validation Rules, normale Page Layouts. Sie greifen mit Apex und Async SOQL zu. Wenn Ihr Use Case nicht eindeutig „massive Daten, selten gelesen" ist, sind Big Objects der falsche Hammer.
Architektur-Entscheidungen kosten am wenigsten am Anfang. Wer sie verschiebt, zahlt zehnfach.
Wie ich vorgehe, wenn das Modell schon zu groß ist
Wenn Sie eine bestehende Org haben mit zu vielen Custom Objects: nicht alles auf einmal angehen. Mein Vorgehen ist immer das Gleiche.
Erst eine Inventur. Welche Custom Objects existieren? Wie viele Records pro Object? Welche werden noch genutzt (Last Modified Date prüfen)? Welche sind tatsächlich für Reports oder Workflows kritisch?
Dann eine Konsolidierungs-Strategie. Was kann zu Feldern auf Standard-Objekten werden? Was kann gemerged werden? Was braucht eine neue Struktur? Vorher unbedingt die Datenbereinigung angehen, sonst migrieren Sie Müll mit. Und immer parallel die Datenmigration sauber planen, damit External IDs und Mapping stehen, bevor der erste Record bewegt wird.
Refactoring eines Datenmodells geht in einer mittleren Org realistisch in drei bis sechs Monaten. Davon sind 60 Prozent Analyse und Planung, 30 Prozent Migration, 10 Prozent Cleanup. Die meisten Kunden unterschätzen die Analyse-Phase massiv und wundern sich dann, warum die Migration nicht funktioniert.
Häufige Fragen
Wann lohnt sich ein Custom Object überhaupt?
Wenn das neue Konzept einen eigenen Lebenszyklus, eigene Berechtigungen und eigene Reports braucht. Oder wenn es eine n-zu-n-Beziehung gibt, die als Junction Object abgebildet werden muss. Sonst sind es fast immer Felder auf Standard-Objekten.
Was ist der Unterschied zwischen Lookup und Master-Detail?
Master-Detail erzeugt eine starre Eltern-Kind-Beziehung mit Cascade Delete und Roll-up Summaries. Lookup ist eine lose Beziehung, das Child existiert auch ohne Parent. Master-Detail wenn Sie auf dem Parent aggregieren wollen, sonst Lookup.
Wie viele Custom Objects sind zu viele?
Es gibt keine harte Zahl, aber alles über 30-40 produktive Custom Objects in einer mittelständischen Org ist ein Warnzeichen. Salesforce erlaubt bis zu 200 in der Enterprise Edition, aber Wartbarkeit und Performance leiden lange vorher.
Soll ich API-Namen auf Englisch oder Deutsch wählen?
Immer Englisch und Singular. Project__c, nicht Projekt__c. API-Namen sind unveränderlich, alle Salesforce-Standards sind Englisch, und Integrationen mit anderen Systemen werden einfacher. Die Labels in der UI dürfen Deutsch sein, dafür gibt es die Translation Workbench.
Wann brauche ich External IDs?
Auf jedem Objekt, das jemals migriert oder mit anderen Systemen integriert wird. Praktisch: auf allem. Eine External ID kostet nichts, ist aber bei der nächsten Integration der Hebel, der Upserts ohne Salesforce-ID ermöglicht.
Wenn Ihre Org chaotisches Custom-Object-Wuchs hat, räume ich das mit Ihnen auf. Wir gehen Object für Object durch, identifizieren Konsolidierungspotenzial und bauen einen sauberen Migrations-Plan. Oder Sie starten greenfield und wollen das Datenmodell von Anfang an richtig aufsetzen. Ich begleite Sie von der ersten Skizze bis zum produktiven Go-Live, mit dem Fokus auf einer Architektur, die in fünf Jahren noch trägt.
