O Lightning Knowledge é a biblioteca de artigos da Salesforce para o Service Cloud: os agentes escrevem artigos, os record types separam FAQs de políticas, as data categories decidem quem encontra o quê, e um agente ainda precisa clicar em Publish mesmo depois da aprovação. Ativar é uma via de mão única, exige uma licença Knowledge User para quem escreve, e o limite que bate primeiro são as article versions, não os artigos. Planeje as categories antes do primeiro artigo. Depois que a biblioteca existir, um agente de IA como a eesel para Salesforce pode ler esses artigos ao redigir a resposta de um case.
O que é o Lightning Knowledge?
Eu trabalho na fila de suporte da eesel, e a pergunta que mais ouço sobre o Salesforce Knowledge é: "de onde vem a resposta, na prática, quando um agente está no meio de um case?" O Lightning Knowledge é esse lugar. Com a eesel CLI, um agente de IA para código pode subir o texto dos seus artigos aprovados, como artigos de Knowledge exportados e políticas, fazer perguntas de teste e checar as respostas antes de qualquer coisa ir ao ar, embora um admin da Salesforce continue aprovando a conexão em si.
A visão geral do Knowledge da Salesforce diz que sua base de conhecimento é construída a partir de artigos, documentos de informação como redefinir um produto ou quanto armazenamento ele suporta. Agentes experientes e redatores internos os escrevem, e artigos podem ser publicados interna ou externamente, em sites de clientes e parceiros, sites públicos, e posts em redes sociais e e-mails. Segundo a mesma página, orgs novas em Knowledge usam o Lightning Knowledge.
Duas coisas o diferenciam de uma pasta de Google Docs. Os artigos são registros de verdade da Salesforce, então você pode gerar relatórios sobre eles, anexá-los a cases e controlá-los com as mesmas permissões de qualquer outro objeto. E cada artigo passa por um ciclo de vida de versões draft, published e arquivadas, e é aí que mora a maior parte do trabalho administrativo. Se você está mapeando o resto do produto, meus guias sobre a visão geral do Service Cloud e o sistema de tickets ficam bem ao lado deste.
Em que o Lightning Knowledge difere do Classic Knowledge?
O Lightning Knowledge substitui article types personalizados por record types padrão, e muda quem pode fazer o quê. A página de limitações da Salesforce diz que ativar muda seu modelo de dados para usar record types em vez de article types, e que você não pode desativar depois. As permissões do Classic vinham de grupos públicos e article actions. No Lightning, permissões de perfil de usuário ou permission sets as substituem.
A mesma página aponta uma instrução com prazo que eu não pularia: diz que orgs precisavam rodar a ferramenta de migração antes de 1º de junho de 2025 para manter o acesso ao Knowledge. Se você está lendo isso em uma org Classic, pergunte ao seu admin da Salesforce como está essa situação. A página de migração da Salesforce diz para abrir uma solicitação com o Support, reservar de 1 a 2 semanas de prazo e testar primeiro em uma sandbox.
A página de limitações também lista o que não fez a travessia, e algumas dessas coisas surpreendem:
- As avaliações por estrelas acabaram. Só existem thumbs up e thumbs down, e as antigas avaliações de 3, 4 e 5 estrelas viram thumbs up.
- O Lightning Knowledge não suporta busca federada, e o pacote Public Knowledge Base não pode ser usado.
- O arquivamento não pode ser agendado para uma data futura. A Salesforce sugere um Flow que arquive artigos com base em um campo de data.
- A ação Printable View não está disponível.
- Depois de ativar, o campo Article Type não pode mais ser acessado por SOQL nem pela API, o que quebra código personalizado que o consulta.
Como configurar o Lightning Knowledge?
Em cinco movimentos, e o primeiro não tem volta. A página de ativação e a visão geral de configuração da Salesforce dão a sequência.
- Teste em uma sandbox ou org de teste. A Salesforce diz para fazer isso antes de production porque ativar é permanente. Segundo a página de limitações, apague primeiro qualquer pacote instalado que contenha article types.
- Ative. No Setup, digite Knowledge no Quick Find, clique em Knowledge Settings, depois em Edit, selecione Enable Lightning Knowledge e salve. Você precisa de um article type para ativar, e da licença Knowledge User para ver a página.
- Dê acesso às pessoas. A página de acesso de usuários da Salesforce diz que todos os usuários internos com permissão Read podem ler artigos publicados por padrão. Para fazer mais do que ler, os agentes precisam da licença Knowledge User, marcada no registro do usuário.
- Crie record types e page layouts. Um record type para cada tipo de conteúdo, cada um com seu próprio layout.
- Planeje as categories e só depois publique. Configure os data category groups, decida para quais channels cada tipo vai, e escreva os primeiros artigos.
Um detalhe de permissões que economiza uma tarde de um admin de suporte: para ver categories em artigos draft, usuários padrão precisam tanto de Knowledge User quanto de Manage Article, e apagar artigos arquivados exige Modify All Records. Meu guia de macros traz a mesma lição para outra funcionalidade: teste como agente, não como admin.
A Salesforce também oferece um fluxo de configuração guiado que ativa o Lightning Knowledge, escolhe autores de artigos e cria data category groups, e que ativa automaticamente um record type e layout de FAQ padrão, segundo sua página de fluxo de configuração.
Como funcionam record types, page layouts e data categories?
Os record types decidem o que um artigo contém, e as data categories decidem onde ele pode ser encontrado. A página de record types da Salesforce é direta: suas páginas de FAQ são diferentes de tutoriais, que por sua vez são diferentes de declarações de política, e um record type controla o conteúdo e o layout de um artigo. Um page layout então decide quais campos os agentes veem e editam, de acordo com o record type e o perfil.
As data categories são a camada de filtro. O artigo de boas práticas da Salesforce lista os limites:
| Limite de data category | Valor |
|---|---|
| Category groups | Até 3 |
| Níveis de hierarquia por grupo | Até 5 |
| Categories por grupo | Até 100 |
| Categories em um artigo, de um grupo | Até 8 |
| Configurações de visibilidade | Roles, permission sets ou perfis, definidos como All, None ou Custom |
O exemplo dessa página vale a pena lembrar. Um artigo sem category não aparece quando um filtro de produto está ativo, enquanto um artigo marcado como All Products aparece com e sem o filtro. A página de criação da Salesforce acrescenta que os usuários só encontram um artigo pela category aplicada, pela category pai dela ou por uma das filhas, então escolha categories que uma pessoa procuraria naturalmente. Ela também avisa que data categories não aparecem nas list views do Knowledge, então construa um relatório que filtre por category em vez disso.
Meu conselho, do lado da fila: mantenha o primeiro category group limitado a uma pergunta, como "sobre qual produto é isso?" Três grupos no primeiro dia é o motivo pelo qual os artigos acabam não entrando em nenhum deles. A página de planejamento da Salesforce concorda com a ordem do trabalho, dizendo aos admins para planejar as hierarquias de categories e como elas mapeiam para a hierarquia de roles antes de configurá-las.
Como os channels decidem quem vê um artigo?
Channels são interruptores de visibilidade em cada artigo. A Salesforce documenta quatro campos no Lightning Knowledge: Visible in Internal App, Visible to Customer, Visible to Partner e Visible in Public Knowledge Base, e seu artigo sobre channels diz que eles ficam ocultos por padrão e precisam ser adicionados ao page layout antes que os autores possam editá-los. Publicar torna um artigo visível em todos os channels selecionados, e publicar um artigo com traduções também publica as traduções, segundo a página de publicação.
Para leitores externos, a página de limitações da Salesforce diz que você pode compartilhar artigos do Lightning Knowledge no Experience Cloud e no Salesforce Sites, e usar o Help Center para compartilhar com usuários não autenticados. Como Title e URL Name são obrigatórios, eles não podem ser removidos de um layout, o que também vale para sites do Experience Cloud.
Se você está comparando isso com outros help centers, meus posts sobre a base de conhecimento da Gorgias, a base de conhecimento da HubSpot e a base de conhecimento da Freshservice mostram o mesmo trabalho feito com menos peças móveis.
Como funcionam aprovações e publicação?
A aprovação condiciona o conteúdo, mas nunca o publica. A página de aprovação da Salesforce diz que artigos não são publicados automaticamente ao fim de um approval process, então um agente precisa clicar em Publish. Também diz para configurar a ação de aprovação final como "Unlock the record for editing" para que isso seja possível.
Outras regras dessa página e da página de publicação:
- Aprovadores podem ser escolhidos manualmente, atribuídos a partir de um campo de hierarquia, enviados para uma queue, ou definidos para usuários específicos, com até
25por etapa. - Approval processes cobrem só a etapa de draft até a publicação. A Salesforce diz que não estão disponíveis para tradução nem arquivamento.
- Um agente com a ação Publish Articles vê tanto Publish quanto Submit for Approval, então limite essa ação a um grupo pequeno se quiser que a aprovação signifique alguma coisa.
- Você não pode desbloquear um artigo que está em um approval process, e artigos agendados para publicação antes da aprovação vão ao ar independentemente do status de aprovação.
- A publicação agendada roda em intervalos de 15 minutos, então o minuto exato não é garantido.
Há um ponto em que as próprias páginas da Salesforce se contradizem: a página de publicação diz para clicar em Cancel Publication para cancelar uma publicação agendada, mas também diz que o botão não fica disponível a partir de um draft no Lightning Experience, e a página de limitações diz que não dá para cancelar uma publicação agendada de jeito nenhum. Teste em uma sandbox antes de prometer aos autores que podem retirar um artigo agendado.
Workflow rules são outra coisa. Podem enviar alertas por e-mail, atualizar campos ou enviar outbound messages quando um artigo atende critérios, mas a Salesforce observa que tasks não são suportadas para o workflow de artigos. Se o seu problema é um artigo desatualizado em vez de lento, meus guias sobre uma auditoria de base de conhecimento com IA e detecção de conteúdo de ajuda desatualizado são as verificações que eu faria.
Como funcionam as versões de artigo?
Cada artigo pode ter uma versão draft, uma published e várias arquivadas. A página de versões da Salesforce diz que, para guardar a versão anterior, você marca Flag as new version ao publicar, e a nova versão recebe o próximo número sequencial.
O vínculo com o case é a parte inteligente. Quando um artigo está anexado a um case e uma nova versão é publicada, a versão anexada é marcada como desatualizada, então Version 2 vira "Version 2 (outdated)" e o case mantém um registro permanente do que o agente realmente leu. Por padrão, o sistema armazena até 10 versões por artigo, mais as que estiverem anexadas a cases, e essas versões vinculadas a cases não contam no limite por artigo.
Duas peculiaridades do Lightning: você só pode apagar versões arquivadas e draft, e em artigos com mais de 30 versões, as que passam de 30 aparecem no Classic mas não no Lightning, segundo a página de limitações. Vários agentes também podem editar o mesmo artigo ao mesmo tempo e se sobrescrever sem aviso, então a Salesforce recomenda dizer aos autores para editarem só os artigos atribuídos a eles.
Quanto custa o Lightning Knowledge e quem precisa de licença?
A Salesforce não lista um preço autônomo para Knowledge na sua página de preços do Service. Ele aparece como uma linha de funcionalidade "Knowledge Management" na comparação de edições, e eu não consegui confirmar pelo texto da página quais colunas de edição o incluem, então confira com seu representante. Os preços de tabela por usuário nessa página são:
| Edição | Preço de tabela por usuário por mês |
|---|---|
| Starter Suite | US$ 25 |
| Pro Suite | US$ 100 |
| Core | US$ 195 |
| Advanced | US$ 395 |
| Max | US$ 550 |
Dois add-ons de IA se relacionam diretamente com artigos: a página mostra Knowledge Creation e Enterprise Knowledge como "Available for purchase" no Core e no Advanced. Para redatores, a licença que importa é a Knowledge User, que a Salesforce diz ser necessária para fazer mais do que ler artigos. Os preços atuais do Service Cloud da Salesforce estão detalhados no meu guia de preços, e o uso de IA é medido separadamente em Flex Credits.
Quais limites os admins devem planejar?
O limite que surpreende é o de versões, não o de artigos. A página de escalabilidade da Salesforce diz que o total de versões é igual a artigos multiplicados por versões retidas por artigo multiplicadas por traduções por versão, e dá um exemplo de 100.000 artigos com 5 versões e 5 traduções cada, o que dá 2.500.000 versões.
Alocações padrão por edição, da mesma página:
| Edição | Artigos | Versões por artigo | Idiomas |
|---|---|---|---|
| Essentials | 500 | 10 | 1 |
| Professional | 500 | 10 | 1 |
| Enterprise | 50.000 | 10 | 5 |
| Developer | 50.000 | 10 | 5 |
| Unlimited | 150.000 | 10 | 10 |
Uma ressalva honesta: essa tabela usa os nomes de edição mais antigos, enquanto a página de preços agora mostra Core, Advanced e Max, e nenhuma das duas páginas mapeia uma para a outra. Você pode pedir à Salesforce Support para aumentar os limites, e orgs criadas antes da Spring '18 têm 16 idiomas por padrão. O Classic Knowledge permitia 25 article types, enquanto o Lightning Knowledge permite até 200 record types por objeto.
Outros limites dessa página que afetam equipes de suporte: um campo de texto rico pode conter até 100 links para outros artigos, o rodapé do Knowledge não está na Lightning Service Console (em vez disso, adicione o componente Knowledge a uma página de registro), e a opção de criar um artigo ao fechar um case só existe no Classic. E, como prometido no FAQ, você não pode usar macros com artigos de Knowledge nem inserir artigos em macros, então meu guia de macros e este aqui descrevem duas bibliotecas separadas.
Como agentes de IA usam o Lightning Knowledge?
Os artigos alimentam os recursos de IA que a Salesforce vende para Service, e agentes de terceiros também os leem. Três detalhes da Salesforce importam.
Redação. O Einstein Knowledge Creation da Salesforce permite que agentes redijam artigos a partir de um case, incident ou work order usando prompt templates, e depois revisem, editem e salvem. A Salesforce diz que só cobra pelos artigos que você gera.
Grounding. No Ground with Knowledge, os campos title e summary são obrigatórios. A Salesforce diz que a indexação pode levar várias horas, artigos novos são indexados uma vez a cada 24 horas, e usuários só veem respostas fundamentadas em campos e versões que podem acessar. Só são suportados campos String e Text Area, e campos criptografados não.
Fontes externas. A página do Unified Knowledge da Salesforce diz que ele está previsto para ser descontinuado no release Summer '27, com o Enterprise Knowledge, baseado no Data 360, como substituto.
Minha opinião: a régua de qualidade para um agente de IA é a mesma de um agente humano, só que menos tolerante. Title e summary são os campos obrigatórios de grounding, então um summary vago como "Returns info" vai custar mais do que qualquer upgrade de modelo. Meus guias sobre alucinações de IA no suporte e treinamento de base de conhecimento aprofundam mais.
A smava mostra o outro lado disso, na Zendesk em vez da Salesforce. Entre 8 de agosto e 8 de setembro de 2026, a eesel tratou cerca de 27.000 tickets para a smava e sua marca irmã, rodou cerca de 14.400 buscas pelas macros e pelo help center, e preparou cerca de 15.300 respostas em rascunho para pessoas aprovarem. A SaunaSpace faz o mesmo na Gorgias, redigindo a partir do help center e de tickets anteriores em uma voz calma e direta, sempre com uma pessoa enviando. Nos dois casos, o agente trabalha a partir de conteúdo de ajuda que uma pessoa já escreveu. É por isso que eu arrumaria os artigos antes de comprar qualquer IA.
Na própria Salesforce, a integração da eesel roda como um agente em Cases: lê o case com o contexto de contato e conta, redige ou envia respostas, adiciona notas internas, atualiza campos e roteia para queues, e sua página diz que aprende com cases anteriores e artigos de knowledge. Os preços estão na página de preços da eesel: planos de créditos fixos em que um ticket ou chat custa 1 crédito, a partir de 500 créditos por US$ 299 por mês, com 100 créditos grátis por 7 dias. Se você preferir deixar a IA por conta da Salesforce, veja Agentforce agents, o apanhado de alternativas ao Agentforce e melhor IA para Service Cloud.
O que eu faria antes de escrever o primeiro artigo?
Aqui está a checklist que eu daria a um admin de suporte:
- Rode primeiro em uma sandbox. Ativar é permanente, e a Salesforce repete esse aviso em várias das suas páginas.
- Escolha no máximo três record types: FAQ, how-to e policy. Adicione mais só quando um layout realmente for diferente.
- Comece com um category group e planeje-o de acordo com sua hierarquia de roles.
- Adicione os campos de channel ao layout no primeiro dia, ou os autores não conseguirão defini-los.
- Decida quem pode publicar. Se aprovações importam, restrinja a ação Publish Articles e configure a etapa final de aprovação para desbloquear o record.
- Escreva o campo summary para um agente, não só para uma pessoa. Title e summary são os dois campos obrigatórios para grounding.
- Revise versões e vínculos com cases mensalmente, e arquive o que ninguém lê. Meu guia de gestão do conhecimento com IA tem um ritmo de revisão.
Se seus artigos alimentam um bot, meus posts sobre escrever artigos com IA, conectar IA ao conhecimento da empresa e busca no help center combinam bem com este. Guias vizinhos de Service Cloud: fusão de cases, roteamento Omni-Channel, Enhanced Messaging e resumos de case. Para bibliotecas multilíngues, veja suporte multilíngue e tradução Salesforce, e para uma visão externa, melhor software de gestão do conhecimento.
Teste a eesel para o Salesforce Service Cloud
Se seus agentes já têm os artigos mas ainda assim redigitam a resposta, a eesel funciona como uma nova contratada que se conecta à sua org do Service Cloud, lê cada case novo com o histórico da conta e seus artigos de knowledge, e deixa uma resposta em rascunho como comentário interno para seu agente aprovar. Seu admin controla o que ela pode ver, e você pode simulá-la em cases anteriores antes que ela toque em um de verdade. Grátis para testar com 100 créditos.
