Lightning Knowledge es la biblioteca de artículos de Salesforce para Service Cloud: los agentes escriben artículos, los record types separan las FAQ de las políticas, las data categories deciden quién encuentra qué, y un agente aún tiene que hacer clic en Publish incluso después de la aprobación. Activarlo es de un solo sentido, necesita una licencia Knowledge User para quien escriba, y el límite que golpea primero son las article versions, no los artículos. Planea las categories antes del primer artículo. Una vez que la biblioteca existe, un agente de IA como eesel para Salesforce puede leer esos artículos cuando redacta la respuesta a un case.
¿Qué es Lightning Knowledge?
Trabajo en la cola de soporte de eesel, y la pregunta que más me hacen sobre Salesforce Knowledge es: "¿de dónde sale realmente la respuesta cuando un agente está en medio de un case?" Lightning Knowledge es ese lugar. Con la eesel CLI, un agente de IA para código puede subir el texto de tus artículos aprobados, como artículos de Knowledge exportados y políticas, hacerle preguntas de prueba y revisar las respuestas antes de que algo salga en vivo, aunque un admin de Salesforce sigue aprobando la conexión en sí.
La visión general de Knowledge de Salesforce dice que tu base de conocimiento se construye con artículos, que son documentos de información como cómo resetear un producto o cuánto almacenamiento admite. Agentes experimentados y redactores internos los escriben, y los artículos pueden publicarse interna o externamente en sitios de clientes y socios, sitios web públicos, y publicaciones en redes sociales y correos. Según la misma página, las orgs nuevas en Knowledge usan Lightning Knowledge.
Dos cosas lo diferencian de una carpeta de Google Docs. Los artículos son registros reales de Salesforce, así que puedes generar reports sobre ellos, adjuntarlos a cases y controlarlos con los mismos permisos que cualquier otro objeto. Y cada artículo pasa por un ciclo de vida de versiones draft, published y archivadas, que es donde vive la mayor parte del trabajo admin. Si estás mapeando el resto del producto, mis guías sobre el resumen de Service Cloud y el sistema de tickets encajan bien junto a esta.
¿En qué se diferencia Lightning Knowledge de Classic Knowledge?
Lightning Knowledge sustituye los article types personalizados por record types estándar, y cambia quién puede hacer qué. La página de limitaciones de Salesforce dice que activarlo cambia tu modelo de datos para usar record types en lugar de article types, y que no puedes desactivarlo después. Los permisos de Classic venían de grupos públicos y article actions. En Lightning, los permisos de perfil de usuario o los permission sets los sustituyen.
La misma página señala una instrucción con fecha que yo no me saltaría: dice que las orgs debían ejecutar la herramienta de migración antes del 1 de junio de 2025 para conservar el acceso a Knowledge. Si estás leyendo esto en una org Classic, pregúntale a tu admin de Salesforce en qué está ese tema. La página de migración de Salesforce dice que hay que abrir una solicitud con Support, dejar de 1 a 2 semanas de margen y probar primero en una sandbox.
La página de limitaciones también lista lo que no hizo el salto, y algunas de estas cosas sorprenden:
- Las valoraciones por estrellas desaparecieron. Solo existen thumbs up y thumbs down, y las viejas valoraciones de 3, 4 y 5 estrellas se convierten en thumbs up.
- Lightning Knowledge no admite búsqueda federada, y el paquete Public Knowledge Base no se puede usar.
- El archivado no se puede programar para una fecha futura. Salesforce sugiere un Flow que archive artículos según un campo de fecha.
- La acción Printable View no está disponible.
- Después de activarlo, el campo Article Type ya no es accesible por SOQL ni por la API, lo que rompe el código personalizado que lo consulta.
¿Cómo configuras Lightning Knowledge?
En cinco movimientos, y el primero no tiene vuelta atrás. La página de activación y el resumen de configuración de Salesforce dan la secuencia.
- Prueba en una sandbox o una org de prueba. Salesforce dice que lo hagas antes de production porque activarlo es permanente. Según la página de limitaciones, primero elimina cualquier paquete instalado que contenga article types.
- Actívalo. En Setup, escribe Knowledge en Quick Find, haz clic en Knowledge Settings, luego en Edit, selecciona Enable Lightning Knowledge y guarda. Necesitas un article type para activarlo, y la licencia Knowledge User para ver la página.
- Da acceso a las personas. La página de acceso de usuarios de Salesforce dice que todos los usuarios internos con permiso Read pueden leer los artículos publicados por defecto. Para hacer algo más que leer, los agentes necesitan la licencia Knowledge User, marcada en su registro de usuario.
- Crea record types y page layouts. Un record type por cada tipo de contenido, cada uno con su propio layout.
- Planea las categories, luego publica. Configura los category groups de data, decide a qué channels va cada tipo, y escribe los primeros artículos.
Un detalle de permisos que le ahorra una tarde a un admin de soporte: para ver categories en artículos draft, los usuarios estándar necesitan tanto Knowledge User como Manage Article, y borrar artículos archivados necesita Modify All Records. Mi guía de macros tiene la misma lección para otra función: prueba como agente, no como admin.
Salesforce también ofrece un flujo de configuración guiado que activa Lightning Knowledge, elige autores de artículos y crea category groups de data, y según su página de flujo de configuración, activa automáticamente un record type y un layout de FAQ por defecto.
¿Cómo funcionan los record types, los page layouts y las data categories?
Los record types deciden qué contiene un artículo, y las data categories deciden dónde se puede encontrar. La página de record types de Salesforce lo dice sin rodeos: tus páginas de FAQ son distintas de los tutoriales, que a su vez son distintos de las declaraciones de política, y un record type controla el contenido y el layout de un artículo. Luego, un page layout decide qué campos ven y editan los agentes, según el record type y el perfil.
Las data categories son la capa de filtro. El artículo de mejores prácticas de Salesforce lista los límites:
| Límite de data category | Valor |
|---|---|
| Category groups | Hasta 3 |
| Niveles de jerarquía por grupo | Hasta 5 |
| Categories por grupo | Hasta 100 |
| Categories en un artículo, de un grupo | Hasta 8 |
| Configuración de visibilidad | Roles, permission sets o perfiles, en All, None o Custom |
El ejemplo de esa página vale la pena recordarlo. Un artículo sin category no aparece cuando hay un filtro de producto activo, mientras que un artículo etiquetado como All Products aparece tanto con filtro como sin él. La página de creación de Salesforce añade que los usuarios solo encuentran un artículo a través de su category aplicada, la category padre de esa o una de sus hijas, así que elige categories que una persona buscaría de forma natural. También advierte que las data categories no aparecen en las vistas de lista de Knowledge, así que construye un report que filtre por category en su lugar.
Mi consejo, desde el lado de la cola: mantén el primer category group limitado a una pregunta, como "¿de qué producto se trata?" Tres grupos el primer día es la razón por la que los artículos terminan en ninguno de ellos. La página de planificación de Salesforce coincide en el orden del trabajo, al decirle a los admins que planeen las jerarquías de categories y cómo se mapean con la jerarquía de roles antes de configurarlas.
¿Cómo deciden los channels quién ve un artículo?
Los channels son interruptores de visibilidad en cada artículo. Salesforce documenta cuatro campos en Lightning Knowledge: Visible in Internal App, Visible to Customer, Visible to Partner y Visible in Public Knowledge Base, y su artículo sobre channels dice que están ocultos por defecto y deben añadirse al page layout antes de que los autores puedan editarlos. Publicar hace que un artículo sea visible en todos los channels seleccionados, y publicar un artículo con traducciones también publica las traducciones, según la página de publicación.
Para lectores externos, la página de limitaciones de Salesforce dice que puedes compartir artículos de Lightning Knowledge en Experience Cloud y Salesforce Sites, y usar Help Center para compartir con usuarios no autenticados. Como Title y URL Name son obligatorios, no se pueden quitar de un layout, lo cual también aplica a los sitios de Experience Cloud.
Si estás comparando esto con otros help centers, mis publicaciones sobre la base de conocimiento de Gorgias, la base de conocimiento de HubSpot y la base de conocimiento de Freshservice muestran el mismo trabajo hecho con menos piezas móviles.
¿Cómo funcionan las aprobaciones y la publicación?
La aprobación da paso al contenido, pero nunca lo publica. La página de aprobaciones de Salesforce dice que los artículos no se publican automáticamente al final de un approval process, así que un agente debe hacer clic en Publish. También dice que hay que configurar la acción final de aprobación como "Unlock the record for editing" para que eso pueda pasar.
Otras reglas de esa página y de la página de publicación:
- Los aprobadores se pueden elegir manualmente, asignar desde un campo de jerarquía, enviar a una queue, o fijar a usuarios específicos, con hasta
25por paso. - Los approval processes cubren solo la etapa de draft a publicación. Salesforce dice que no están disponibles para traducción ni archivado.
- Un agente con la acción Publish Articles ve tanto Publish como Submit for Approval, así que limita esa acción a un grupo pequeño si quieres que la aprobación signifique algo.
- No puedes desbloquear un artículo que está en un approval process, y los artículos programados para publicarse antes de la aprobación salen en vivo sin importar el estado de la aprobación.
- La publicación programada corre en intervalos de 15 minutos, así que el minuto exacto no está garantizado.
Hay un punto donde las propias páginas de Salesforce se contradicen: la página de publicación dice que hagas clic en Cancel Publication para cancelar una publicación programada, pero también dice que el botón no está disponible desde un draft en Lightning Experience, y la página de limitaciones dice que no se puede cancelar una publicación programada en absoluto. Pruébalo en una sandbox antes de prometerles a los autores que pueden retirar un artículo programado.
Las workflow rules son algo separado. Pueden enviar alertas por correo, actualizar campos o enviar outbound messages cuando un artículo cumple ciertos criterios, pero Salesforce señala que las tasks no son compatibles con el workflow de artículos. Si tu problema es un artículo desactualizado en lugar de uno lento, mis guías sobre una auditoría de base de conocimiento con IA y detectar contenido de ayuda desactualizado son los chequeos que yo haría.
¿Cómo funcionan las versiones de artículo?
Cada artículo puede tener una versión draft, una published y varias archivadas. La página de versiones de Salesforce dice que para guardar la versión anterior marcas Flag as new version al publicar, y la nueva versión recibe el siguiente número secuencial.
El vínculo con el case es la parte inteligente. Cuando un artículo está adjunto a un case y se publica una nueva versión, la versión adjunta se marca como desactualizada, así que Version 2 se convierte en "Version 2 (outdated)" y el case conserva un registro permanente de lo que el agente realmente leyó. Por defecto, el sistema almacena hasta 10 versiones por artículo, más las que estén adjuntas a cases, y esas versiones vinculadas a cases no cuentan contra el límite por artículo.
Dos particularidades de Lightning: solo puedes borrar versiones archivadas y draft, y en artículos con más de 30 versiones, según la página de limitaciones, las que superan 30 aparecen en Classic pero no en Lightning. Varios agentes también pueden editar el mismo artículo a la vez y sobrescribirse entre sí sin aviso, así que Salesforce dice que hay que decirle a los autores que editen solo los artículos que tienen asignados.
¿Qué cuesta Lightning Knowledge y quién necesita una licencia?
Salesforce no lista un precio independiente para Knowledge en su página de precios de Service. Aparece como una fila de función "Knowledge Management" en la comparación de ediciones, y no pude confirmar con el texto de la página qué columnas de edición la incluyen, así que consúltalo con tu representante. Los precios de lista por usuario en esa página son:
| Edición | Precio de lista por usuario al mes |
|---|---|
| Starter Suite | 25 $ |
| Pro Suite | 100 $ |
| Core | 195 $ |
| Advanced | 395 $ |
| Max | 550 $ |
Dos add-ons de IA se relacionan directamente con los artículos: la página muestra Knowledge Creation y Enterprise Knowledge como "Available for purchase" bajo Core y Advanced. Para los redactores, la licencia que importa es Knowledge User, que según Salesforce es necesaria para hacer algo más que leer artículos. Mi guía de precios desglosa los precios actuales de Service Cloud de Salesforce, y el uso de IA se mide por separado en Flex Credits.
¿Con qué límites deben planificar los admins?
El límite que sorprende a la gente son las versiones, no los artículos. La página de escalabilidad de Salesforce dice que el total de versiones es igual a artículos multiplicado por versiones retenidas por artículo multiplicado por traducciones por versión, y da un ejemplo de 100.000 artículos con 5 versiones y 5 traducciones cada uno, lo que da 2.500.000 versiones.
Asignaciones por defecto según la edición, de la misma página:
| Edición | Artículos | Versiones por artículo | Idiomas |
|---|---|---|---|
| Essentials | 500 | 10 | 1 |
| Professional | 500 | 10 | 1 |
| Enterprise | 50.000 | 10 | 5 |
| Developer | 50.000 | 10 | 5 |
| Unlimited | 150.000 | 10 | 10 |
Una advertencia honesta: esa tabla usa los nombres de edición más antiguos, mientras que la página de precios ahora muestra Core, Advanced y Max, y ninguna de las dos páginas mapea una con la otra. Puedes pedirle a Salesforce Support que suba los límites, y las orgs creadas antes de Spring '18 tienen por defecto 16 idiomas. Classic Knowledge permitía 25 article types, mientras que Lightning Knowledge permite hasta 200 record types por objeto.
Otros límites de esa página que afectan a los equipos de soporte: un campo de texto enriquecido puede contener hasta 100 enlaces a otros artículos, el footer de Knowledge no está en la Lightning Service Console (añade el componente de Knowledge a una página de registro en su lugar), y la opción de crear un artículo al cerrar un case solo existe en Classic. Y como prometí en las FAQ, no puedes usar macros con artículos de Knowledge ni insertar artículos en macros, así que mi guía de macros y esta describen dos bibliotecas separadas.
¿Cómo usan los agentes de IA Lightning Knowledge?
Los artículos alimentan las funciones de IA que Salesforce vende para Service, y los agentes de terceros también los leen. Hay tres detalles de Salesforce que importan.
Redacción. Einstein Knowledge Creation de Salesforce permite a los agentes redactar artículos a partir de un case, incident o work order usando prompt templates, y luego revisar, editar y guardar. Salesforce dice que solo cobra por los artículos que generas.
Grounding. En Ground with Knowledge, los campos Title y Summary son obligatorios. Salesforce dice que la indexación puede tardar varias horas, los artículos nuevos se indexan una vez cada 24 horas, y los usuarios solo ven respuestas fundamentadas en campos y versiones a los que tienen acceso. Solo se admiten campos String y Text Area, y los campos encriptados no.
Fuentes externas. La página de Unified Knowledge de Salesforce dice que está programada para retirarse con la versión Summer '27, con Enterprise Knowledge impulsado por Data 360 como reemplazo.
Mi opinión: la barra de calidad para un agente de IA es la misma que para un agente humano, solo que menos indulgente. Title y summary son los campos obligatorios para el grounding, así que un summary vago como "Returns info" te va a costar más que cualquier mejora de modelo. Mis guías sobre alucinaciones de IA en soporte y entrenamiento de base de conocimiento profundizan más.
smava muestra el otro lado de esto, en Zendesk en lugar de Salesforce. Entre el 8 de agosto y el 8 de septiembre de 2026, eesel gestionó cerca de 27.000 tickets para smava y su marca hermana, ejecutó cerca de 14.400 búsquedas entre las macros y el help center, y preparó cerca de 15.300 respuestas en borrador para que las aprobaran personas. SaunaSpace hace lo mismo en Gorgias, redactando desde su help center y tickets pasados con una voz tranquila y directa, con una persona que siempre envía. En ambos casos, el agente trabaja a partir de contenido de ayuda que una persona ya escribió. Por eso arreglaría los artículos antes de comprar cualquier IA.
En Salesforce mismo, la integración de eesel funciona como un agente sobre Cases: lee el case con el contexto del contacto y la cuenta, redacta o envía respuestas, añade notas internas, actualiza campos y enruta a queues, y su página dice que aprende de cases pasados y artículos de knowledge. Los precios están en la página de precios de eesel: planes de créditos fijos donde un ticket o chat es 1 crédito, desde 500 créditos por 299 $ al mes, con 100 créditos gratis durante 7 días. Si prefieres que Salesforce sea quien gestione la IA, mira agentes de Agentforce, el resumen de alternativas a Agentforce y mejor IA para Service Cloud.
¿Qué haría yo antes de escribir el primer artículo?
Esta es la checklist que le daría a un admin de soporte:
- Pruébalo primero en una sandbox. Activarlo es permanente, y Salesforce repite esa advertencia en varias de sus páginas.
- Elige como máximo tres record types: FAQ, how-to y policy. Añade más solo cuando un layout realmente sea distinto.
- Empieza con un category group y planéalo frente a tu jerarquía de roles.
- Añade los campos de channel al layout desde el primer día, o los autores no podrán configurarlos.
- Decide quién puede publicar. Si las aprobaciones importan, restringe la acción Publish Articles y configura el paso final de aprobación para que desbloquee el record.
- Escribe el campo summary para un agente, no solo para una persona. Title y summary son los dos campos obligatorios para el grounding.
- Revisa las versiones y los vínculos con cases cada mes, y archiva lo que nadie lee. Mi guía de gestión de conocimiento con IA tiene un ritmo de revisión.
Si tus artículos alimentan a un bot, mis publicaciones sobre escribir artículos con IA, conectar la IA al conocimiento de tu empresa y búsqueda en el help center combinan bien con esta. Guías vecinas de Service Cloud: fusión de cases, enrutamiento Omni-Channel, Enhanced Messaging y resúmenes de case. Para bibliotecas multilingües, mira soporte multilingüe y traducción de Salesforce, y para una mirada externa, el mejor software de gestión de conocimiento.
Prueba eesel para Salesforce Service Cloud
Si tus agentes ya tienen los artículos pero igual vuelven a escribir la respuesta, eesel funciona como una nueva incorporación que se conecta a tu org de Service Cloud, lee cada case nuevo con el historial de la cuenta y tus artículos de knowledge, y deja una respuesta en borrador como comentario interno para que tu agente la apruebe. Tu admin controla lo que puede ver, y puedes simularlo sobre cases pasados antes de que toque uno real. Gratis para probar con 100 créditos.
