
Lightning Knowledge ist Salesforces Artikelbibliothek für Service Cloud: Mitarbeiter schreiben Artikel, Record Types trennen FAQs von Richtlinien, Data Categories entscheiden, wer was findet, und ein Mitarbeiter muss auch nach der Freigabe noch auf Publish klicken. Die Aktivierung ist einmalig und nicht umkehrbar, sie braucht eine Knowledge User-Lizenz für jeden, der schreibt, und die Grenze, die zuerst zuschlägt, sind Article Versions, nicht Artikel. Planen Sie die Categories, bevor der erste Artikel entsteht. Sobald die Bibliothek existiert, kann ein KI-Agent wie eesel für Salesforce diese Artikel lesen, wenn er eine Antwort auf einen Case entwirft.
Was ist Lightning Knowledge?
Ich arbeite an der Support-Queue bei eesel, und die Frage, die ich zu Salesforce Knowledge am häufigsten höre, ist: "Wo kommt die Antwort eigentlich her, wenn ein Mitarbeiter mitten in einem Case steckt?" Lightning Knowledge ist dieser Ort. Mit der eesel CLI kann ein KI-Coding-Agent Ihren freigegebenen Artikeltext hochladen, etwa exportierte Knowledge-Artikel und Richtlinien, ihm dann Testfragen stellen und die Antworten prüfen, bevor etwas live geht, wobei ein Salesforce-Admin die Verbindung selbst weiterhin freigeben muss.
Salesforces Knowledge-Übersicht sagt, dass Ihre Wissensdatenbank aus Artikeln besteht, also Dokumenten mit Informationen wie dem Zurücksetzen eines Produkts oder dem verfügbaren Speicherplatz. Erfahrene Mitarbeiter und interne Autoren schreiben sie, und Artikel können intern oder extern veröffentlicht werden, an Kunden- und Partnerseiten, öffentliche Websites sowie Social-Media-Beiträge und E-Mails. Laut derselben Seite nutzen Orgs, die neu bei Knowledge sind, Lightning Knowledge.
Zwei Dinge unterscheiden es von einem Ordner voller Google Docs. Artikel sind echte Salesforce-Records, Sie können also Reports darüber erstellen, sie an Cases anhängen und sie mit denselben Berechtigungen steuern wie jedes andere Objekt. Und jeder Artikel durchläuft einen Lebenszyklus aus Draft, Published und archivierten Versionen, und genau dort liegt der meiste Admin-Aufwand. Wenn Sie den Rest des Produkts kartieren, passen meine Leitfäden zur Service Cloud-Übersicht und zum Ticketsystem gut dazu.

Wie unterscheidet sich Lightning Knowledge von Classic Knowledge?
Lightning Knowledge ersetzt benutzerdefinierte Article Types durch Standard-Record-Types und ändert, wer was tun kann. Salesforces Limitations-Seite sagt, dass die Aktivierung Ihr Datenmodell auf Record Types statt Article Types umstellt und dass Sie es danach nicht mehr deaktivieren können. Classic-Berechtigungen kamen aus öffentlichen Gruppen und Article Actions. In Lightning ersetzen Benutzerprofilberechtigungen oder Permission Sets sie.
Dieselbe Seite nennt eine datierte Anweisung, die ich nicht überspringen würde: Orgs müssen demnach das Migrationstool vor dem 1. Juni 2025 ausführen, um den Zugriff auf Knowledge zu behalten. Wenn Sie dies auf einer Classic-Org lesen, fragen Sie Ihren Salesforce-Admin, wo das steht. Salesforces Migrationsseite rät, eine Anfrage bei Support einzureichen, 1 bis 2 Wochen Vorlaufzeit einzuplanen und zuerst in einer Sandbox zu testen.

Die Limitations-Seite listet außerdem auf, was den Sprung nicht geschafft hat, und einige davon überraschen:
- Sternebewertungen sind weg. Es gibt nur noch Thumbs Up und Thumbs Down, und alte 3-, 4- und 5-Sterne-Bewertungen werden zu Thumbs Up.
- Lightning Knowledge unterstützt keine föderierte Suche, und das Public Knowledge Base-Package kann nicht verwendet werden.
- Archivierung lässt sich nicht für ein zukünftiges Datum planen. Salesforce schlägt einen Flow vor, der Artikel über ein Datumsfeld archiviert.
- Die Printable View-Aktion ist nicht verfügbar.
- Nach der Aktivierung ist das Article Type-Feld nicht mehr über SOQL oder die API erreichbar, was benutzerdefinierten Code bricht, der es abfragt.
Wie richten Sie Lightning Knowledge ein?
In fünf Schritten, und der erste lässt sich nicht zurücknehmen. Salesforces Enable-Seite und Setup-Übersicht geben die Reihenfolge vor.
- Testen Sie in einer Sandbox oder Trial-Org. Salesforce rät dazu, bevor Sie es in Production tun, weil die Aktivierung dauerhaft ist. Löschen Sie laut Limitations-Seite zuerst alle installierten Packages, die Article Types enthalten.
- Aktivieren Sie es. Geben Sie in Setup "Knowledge" in Quick Find ein, klicken Sie auf Knowledge Settings, dann auf Edit, wählen Sie Enable Lightning Knowledge und speichern Sie. Sie brauchen einen Article Type, um es zu aktivieren, und die Knowledge User-Lizenz, um die Seite zu sehen.
- Geben Sie Zugriff. Salesforces Seite zum Nutzerzugriff sagt, dass alle internen Nutzer mit Read-Berechtigung veröffentlichte Artikel standardmäßig lesen können. Um mehr als lesen zu dürfen, brauchen Mitarbeiter die Knowledge User-Lizenz, angehakt im Nutzerdatensatz.
- Erstellen Sie Record Types und Page Layouts. Ein Record Type pro Inhaltsart, jeweils mit eigenem Layout.
- Planen Sie Categories, dann veröffentlichen Sie. Richten Sie Data Category Groups ein, entscheiden Sie, welche Channels jeder Typ erhält, und schreiben Sie die ersten Artikel.
Ein Berechtigungsdetail, das einem Support-Admin einen Nachmittag spart: Um Categories an Draft-Artikeln zu sehen, brauchen Standardnutzer sowohl Knowledge User als auch Manage Article, und das Löschen archivierter Artikel braucht Modify All Records. Mein Leitfaden zu Makros hat dieselbe Lektion für eine andere Funktion: testen Sie als Mitarbeiter, nicht als Admin.
Salesforce bietet außerdem einen geführten Setup-Flow, der Lightning Knowledge aktiviert, Artikelautoren festlegt und Data Category Groups erstellt, und der laut Setup-Flow-Seite automatisch einen Standard-FAQ-Record-Type und ein Layout aktiviert.
Wie funktionieren Record Types, Page Layouts und Data Categories?
Record Types entscheiden, was ein Artikel enthält, und Data Categories entscheiden, wo er gefunden werden kann. Salesforces Seite zu Record Types sagt es unverblümt: Ihre FAQ-Seiten unterscheiden sich von Anleitungen, die sich wiederum von Richtlinientexten unterscheiden, und ein Record Type steuert Inhalt und Layout eines Artikels. Ein Page Layout entscheidet dann, welche Felder Mitarbeiter sehen und bearbeiten, je nach Record Type und Profil.
Data Categories sind die Filterebene. Salesforces Best-Practices-Artikel listet die Limits auf:
| Data-Category-Limit | Wert |
|---|---|
| Category Groups | Bis zu 3 |
| Hierarchieebenen pro Gruppe | Bis zu 5 |
| Categories pro Gruppe | Bis zu 100 |
| Categories an einem Artikel, aus einer Gruppe | Bis zu 8 |
| Visibility-Einstellungen | Rollen, Permission Sets oder Profile, gesetzt auf All, None oder Custom |

Das Beispiel auf dieser Seite lohnt sich zu merken. Ein Artikel ohne Category erscheint nicht, wenn ein Produktfilter gesetzt ist, während ein Artikel mit der Kennzeichnung All Products sowohl mit als auch ohne Filter erscheint. Salesforces Create-Seite ergänzt, dass Nutzer einen Artikel nur über seine zugewiesene Category, deren übergeordnete Category oder eine ihrer untergeordneten Categories finden, wählen Sie also Categories, nach denen jemand natürlicherweise suchen würde. Sie warnt außerdem, dass Data Categories in Knowledge-Listenansichten nicht angezeigt werden, bauen Sie also stattdessen einen Report, der nach Category filtert.
Mein Rat von der Queue-Seite: beschränken Sie die erste Category Group auf eine Frage, etwa "um welches Produkt geht es hier?" Drei Gruppen am ersten Tag sind der Grund, warum Artikel am Ende in keiner von ihnen landen. Salesforces Planungsseite stimmt bei der Reihenfolge der Arbeit zu und sagt Admins, Category-Hierarchien und ihre Zuordnung zur Rollenhierarchie zu planen, bevor sie eingerichtet werden.
Wie entscheiden Channels, wer einen Artikel sieht?
Channels sind Sichtbarkeitsschalter an jedem Artikel. Salesforce dokumentiert vier Felder in Lightning Knowledge: Visible in Internal App, Visible to Customer, Visible to Partner und Visible in Public Knowledge Base, und der Channels-Artikel sagt, dass sie standardmäßig verborgen sind und zum Page Layout hinzugefügt werden müssen, bevor Autoren sie bearbeiten können. Das Veröffentlichen macht einen Artikel in allen ausgewählten Channels sichtbar, und das Veröffentlichen eines Artikels mit Übersetzungen veröffentlicht laut der Publish-Seite auch die Übersetzungen.
Für externe Leser sagt Salesforces Limitations-Seite, dass Sie Lightning Knowledge-Artikel in Experience Cloud und Salesforce Sites teilen können und Help Center nutzen können, um mit nicht authentifizierten Nutzern zu teilen. Weil Title und URL Name erforderlich sind, können sie nicht aus einem Layout entfernt werden, was auch für Experience Cloud-Sites gilt.
Wenn Sie das mit anderen Help Centern vergleichen, zeigen meine Beiträge zur Gorgias-Wissensdatenbank, HubSpot-Wissensdatenbank und Freshservice-Wissensdatenbank, wie dieselbe Aufgabe mit weniger beweglichen Teilen gelöst wird.
Wie funktionieren Freigaben und Veröffentlichung?
Die Freigabe öffnet das Tor für den Inhalt, veröffentlicht ihn aber nie. Salesforces Approval-Seite sagt, dass Artikel am Ende eines Approval Process nicht automatisch veröffentlicht werden, ein Mitarbeiter muss also auf Publish klicken. Sie sagt außerdem, dass die letzte Approval-Aktion auf "Unlock the record for editing" gesetzt werden muss, damit das möglich ist.

Weitere Regeln von dieser Seite und der Publish-Seite:
- Approver können manuell ausgewählt, aus einem Hierarchiefeld zugewiesen, an eine Queue gesendet oder auf bestimmte Nutzer festgelegt werden, mit bis zu
25pro Schritt. - Approval Processes decken nur die Phase von Draft bis Publication ab. Salesforce sagt, sie stehen nicht für Übersetzung oder Archivierung zur Verfügung.
- Ein Mitarbeiter mit der Publish Articles-Aktion sieht sowohl Publish als auch Submit for Approval, beschränken Sie diese Aktion also auf eine kleine Gruppe, wenn die Freigabe etwas bedeuten soll.
- Sie können einen Artikel, der sich in einem Approval Process befindet, nicht entsperren, und Artikel, die vor der Freigabe zur Veröffentlichung geplant sind, gehen unabhängig vom Freigabestatus live.
- Geplante Veröffentlichung läuft in 15-Minuten-Intervallen, die genaue Minute ist also nicht garantiert.
An einer Stelle widersprechen sich Salesforces eigene Seiten: Die Publish-Seite sagt, Sie sollen auf Cancel Publication klicken, um eine geplante Veröffentlichung abzubrechen, sagt aber auch, dass der Button in Lightning Experience von einem Draft aus nicht verfügbar ist, und die Limitations-Seite sagt, dass Sie eine geplante Veröffentlichung überhaupt nicht abbrechen können. Testen Sie es in einer Sandbox, bevor Sie Autoren versprechen, dass sie einen geplanten Artikel zurückziehen können.
Workflow Rules sind etwas anderes. Sie können E-Mail-Benachrichtigungen senden, Felder aktualisieren oder Outbound Messages verschicken, wenn ein Artikel Kriterien erfüllt, aber Salesforce weist darauf hin, dass Tasks für Article Workflow nicht unterstützt werden. Wenn Ihr Problem ein veralteter Artikel ist statt ein langsamer, sind meine Leitfäden zu einem KI-Wissensdatenbank-Audit und zum Erkennen veralteter Hilfe-Inhalte die Checks, die ich durchführen würde.
Wie funktionieren Artikelversionen?
Jeder Artikel kann eine Draft-, eine Published- und mehrere archivierte Versionen haben. Salesforces Versions-Seite sagt, dass Sie zum Speichern der vorherigen Version beim Veröffentlichen Flag as new version anhaken, und die neue Version erhält die nächste laufende Nummer.
Die Case-Verknüpfung ist der clevere Teil. Wenn ein Artikel an einen Case angehängt ist und eine neue Version veröffentlicht wird, wird die angehängte Version als veraltet markiert, sodass Version 2 zu "Version 2 (outdated)" wird und der Case einen dauerhaften Nachweis behält, was der Agent tatsächlich gelesen hat. Standardmäßig speichert das System bis zu 10 Versionen pro Artikel, plus alle an Cases angehängten, und diese case-verknüpften Versionen zählen nicht gegen das Limit pro Artikel.
Zwei Lightning-Eigenheiten: Sie können nur archivierte und Draft-Versionen löschen, und bei Artikeln mit mehr als 30 Versionen erscheinen laut Limitations-Seite die über 30 in Classic, aber nicht in Lightning. Mehrere Mitarbeiter können außerdem denselben Artikel gleichzeitig bearbeiten und sich ohne Warnung gegenseitig überschreiben, Salesforce rät daher, Autoren zu sagen, nur Artikel zu bearbeiten, die ihnen zugewiesen sind.
Was kostet Lightning Knowledge und wer braucht eine Lizenz?
Salesforce listet auf seiner Service-Preisseite keinen eigenständigen Preis für Knowledge. Es erscheint als Funktionszeile "Knowledge Management" im Edition-Vergleich, und ich konnte aus dem Seitentext nicht bestätigen, welche Edition-Spalten es einschließen, fragen Sie also Ihren Ansprechpartner. Die Listenpreise pro Nutzer auf dieser Seite sind:
| Edition | Listenpreis pro Nutzer und Monat |
|---|---|
| Starter Suite | 25 $ |
| Pro Suite | 100 $ |
| Core | 195 $ |
| Advanced | 395 $ |
| Max | 550 $ |
Zwei KI-Add-ons beziehen sich direkt auf Artikel: Die Seite zeigt Knowledge Creation und Enterprise Knowledge als "Available for purchase" unter Core und Advanced. Für Autoren ist die Knowledge User-Lizenz die entscheidende, die laut Salesforce nötig ist, um mehr als Artikel zu lesen. Salesforces aktuelle Service Cloud-Preise schlüsselt mein Preisleitfaden auf, und die KI-Nutzung wird separat über Flex Credits abgerechnet.
Mit welchen Limits sollten Admins planen?
Die Grenze, die überrascht, sind Versionen, nicht Artikel. Salesforces Scalability-Seite sagt, die Gesamtzahl der Versionen entspricht Artikeln mal aufbewahrten Versionen pro Artikel mal Übersetzungen pro Version, und nennt als Beispiel 100.000 Artikel mit je 5 Versionen und 5 Übersetzungen, was 2.500.000 Versionen ergibt.

Standardkontingente nach Edition, von derselben Seite:
| Edition | Artikel | Versionen pro Artikel | Sprachen |
|---|---|---|---|
| Essentials | 500 | 10 | 1 |
| Professional | 500 | 10 | 1 |
| Enterprise | 50.000 | 10 | 5 |
| Developer | 50.000 | 10 | 5 |
| Unlimited | 150.000 | 10 | 10 |
Ein ehrlicher Vorbehalt: Diese Tabelle nutzt die älteren Edition-Namen, während die Preisseite inzwischen Core, Advanced und Max zeigt, und keine der beiden Seiten ordnet eine der anderen zu. Sie können Salesforce Support bitten, die Limits anzuheben, und Orgs, die vor Spring '18 erstellt wurden, haben standardmäßig 16 Sprachen. Classic Knowledge erlaubte 25 Article Types, während Lightning Knowledge bis zu 200 Record Types pro Objekt erlaubt.
Weitere Limits auf dieser Seite, die Support-Teams betreffen: Ein Rich-Text-Feld kann bis zu 100 Links zu anderen Artikeln enthalten, der Knowledge-Footer ist nicht in der Lightning Service Console (fügen Sie statt dessen die Knowledge-Komponente zu einer Record-Seite hinzu), und die Option, beim Schließen eines Cases einen Artikel zu erstellen, gibt es nur in Classic. Und wie in der FAQ versprochen: Sie können Makros nicht mit Knowledge-Artikeln verwenden oder Artikel in Makros einfügen, mein Leitfaden zu Makros und dieser hier beschreiben also zwei getrennte Bibliotheken.
Wie nutzen KI-Agenten Lightning Knowledge?
Artikel füttern die KI-Funktionen, die Salesforce für Service verkauft, und auch Agenten von Drittanbietern lesen sie. Drei Details von Salesforce sind wichtig.
Schreiben. Mit Salesforces Einstein Knowledge Creation können Mitarbeiter Artikel aus einem Case, Incident oder Work Order mithilfe von Prompt-Vorlagen entwerfen und dann prüfen, bearbeiten und speichern. Laut Salesforce wird nur für die Artikel abgerechnet, die Sie generieren.
Grounding. Bei Ground with Knowledge sind Title und Summary Pflichtfelder. Salesforce sagt, die Indexierung kann mehrere Stunden dauern, neue Artikel werden einmal alle 24 Stunden indexiert, und Nutzer sehen nur fundierte Antworten aus Feldern und Versionen, auf die sie Zugriff haben. Unterstützt werden nur String- und Text Area-Felder, verschlüsselte Felder nicht.
Externe Quellen. Salesforces Unified Knowledge-Seite sagt, dass es mit dem Summer '27-Release abgeschaltet werden soll, mit Enterprise Knowledge auf Basis von Data 360 als Ersatz.
Meine Einschätzung: Die Qualitätslatte für einen KI-Agenten ist dieselbe wie für einen Mitarbeiter, nur unversöhnlicher. Title und Summary sind die erforderlichen Grounding-Felder, also kostet Sie ein vages Summary wie "Returns info" mehr als jedes Modell-Upgrade. Meine Leitfäden zu KI-Halluzinationen im Support und zum Training der Wissensdatenbank gehen tiefer.
smava zeigt die andere Seite davon, auf Zendesk statt Salesforce. Zwischen dem 8. August und dem 8. September 2026 bearbeitete eesel rund 27.000 Tickets für smava und seine Schwestermarke, führte rund 14.400 Suchen über die Makros und das Help Center aus und bereitete rund 15.300 Antwortentwürfe zur Freigabe vor. SaunaSpace macht dasselbe auf Gorgias, entwirft aus seinem Help Center und vergangenen Tickets in einer ruhigen, direkten Stimme, wobei immer ein Mensch sendet. In beiden Fällen arbeitet der Agent mit Hilfe-Inhalten, die bereits ein Mensch geschrieben hat. Deshalb würde ich Artikel in Ordnung bringen, bevor ich irgendeine KI kaufe.
Auf Salesforce selbst läuft eesels Integration als Agent auf Cases: Sie liest den Case mit Kontakt- und Account-Kontext, entwirft oder sendet Antworten, fügt interne Notizen hinzu, aktualisiert Felder und routet an Queues, und ihre Seite sagt, dass sie aus früheren Cases und Knowledge-Artikeln lernt. Die Preise stehen auf der eesel-Preisseite: feste Credit-Pläne, bei denen ein Ticket oder Chat 1 Credit kostet, ab 500 Credits für 299 $ im Monat, mit 100 kostenlosen Credits für 7 Tage. Wenn Sie lieber Salesforce selbst die KI übernehmen lassen, siehe Agentforce-Agenten, die Zusammenstellung Agentforce-Alternativen und beste KI für Service Cloud.
Was würde ich tun, bevor ich den ersten Artikel schreibe?
Hier ist die Checkliste, die ich einem Support-Admin geben würde:
- Führen Sie es zuerst in einer Sandbox aus. Die Aktivierung ist dauerhaft, und Salesforce wiederholt diese Warnung auf mehreren Seiten.
- Wählen Sie höchstens drei Record Types: FAQ, How-to und Policy. Fügen Sie weitere nur hinzu, wenn sich ein Layout wirklich unterscheidet.
- Beginnen Sie mit einer Category Group und planen Sie sie im Abgleich mit Ihrer Rollenhierarchie.
- Fügen Sie die Channel-Felder am ersten Tag zum Layout hinzu, sonst können Autoren sie nicht setzen.
- Entscheiden Sie, wer veröffentlichen darf. Wenn Freigaben wichtig sind, beschränken Sie die Publish Articles-Aktion und setzen Sie den letzten Freigabeschritt auf das Entsperren des Records.
- Schreiben Sie das Summary-Feld für einen Agenten, nicht nur für einen Mitarbeiter. Title und Summary sind die beiden Pflichtfelder für Grounding.
- Prüfen Sie Versionen und Case-Verknüpfungen monatlich und archivieren Sie, was niemand liest. Mein Leitfaden zum KI-Wissensmanagement hat einen Review-Rhythmus.
Wenn Ihre Artikel einen Bot füttern, passen meine Beiträge zum Schreiben von Artikeln mit KI, zum Verbinden von KI mit Unternehmenswissen und zur Help-Center-Suche gut dazu. Benachbarte Service Cloud-Leitfäden: Case Merge, Omni-Channel-Routing, Enhanced Messaging und Case-Zusammenfassungen. Für mehrsprachige Bibliotheken siehe mehrsprachigen Support und Salesforce-Übersetzung, und für eine Außenperspektive beste Software für Wissensmanagement.
eesel für Salesforce Service Cloud ausprobieren
Wenn Ihre Mitarbeiter die Artikel bereits haben, die Antwort aber trotzdem neu eintippen, arbeitet eesel wie eine neue Kollegin, die sich in Ihre Service Cloud-Org einklinkt, jeden neuen Case mit der Historie des Accounts und Ihren Knowledge-Artikeln liest und eine Antwort als internen Kommentar zur Freigabe durch Ihren Mitarbeiter hinterlässt. Ihr Admin steuert, was sie sehen darf, und Sie können sie an vergangenen Cases simulieren, bevor sie einen echten berührt. Kostenlos testen mit 100 Credits.
