Skip to main content
Esta página explica o que acontece no Knowledge quando algo muda na origem de um documento. Ela vale para todos os conectores que enviam documentos ao Knowledge: Microsoft 365 (SharePoint), Google Drive, Confluence, GitHub, Pipedrive, Salesbud e Fireflies.

​
Como funciona

Dois ciclos mantêm o Knowledge em dia com a origem: Cada documento é reconhecido por um identificador da origem, e não pelo nome. Uma edição mantém o identificador, e o Knowledge troca o conteúdo antigo pelo novo, sem duplicar. Na maioria dos conectores, um item apagado e criado de novo ganha outro identificador e vira um documento novo. No GitHub, o documento é reconhecido pelo caminho do arquivo, então um arquivo recriado no mesmo caminho continua sendo o mesmo documento.

​
O que cada conector envia

A agenda de cada conector pode ser trocada na configuração dele. Ver Frequência de sync. Depois de cada sincronização, o Knowledge ainda leva alguns minutos para processar os documentos.

​
Resumo por tipo de mudança

As exceções de cada conector estão em Diferenças por conector.

​
Se eu editar um documento, o Knowledge fica com duas versões?

Não. Quando alguém abre um item, altera e salva, a origem mantém o mesmo identificador. A próxima sincronização lê o item de novo e substitui o conteúdo antigo pelo novo. A busca passa a devolver só o texto atual. Exemplo: a equipe abre Política.docx no Word, num site do SharePoint, muda uma cláusula e salva. O SharePoint mantém o arquivo e atualiza a data de modificação. Na próxima sincronização, o documento Política.docx do Knowledge passa a ter a cláusula nova, e a versão anterior sai da busca. Só a versão atual de cada item é indexada. O histórico de versões do SharePoint não entra no Knowledge.

​
E se eu apagar o item antigo e criar a versão nova no lugar?

Na maioria dos conectores, são dois itens diferentes, mesmo com o mesmo nome. A origem dá um identificador novo ao item criado.
  1. Na próxima sincronização, a versão nova entra no Knowledge como um documento novo.
  2. A versão antiga continua no Knowledge até a próxima verificação completa, que percebe que o item não existe mais e o remove.
Nesse intervalo, a busca pode devolver as duas versões. Mais abaixo estão as duas formas de tirar a antiga antes da verificação.
Para atualizar um documento sem passar por esse intervalo, edite o item existente em vez de apagar e criar outro.
No GitHub isso não acontece. O documento é reconhecido pelo caminho, então um arquivo recriado no mesmo caminho continua sendo o mesmo documento e é atualizado na próxima sincronização.

​
Quanto tempo um item apagado leva para sair do Knowledge?

Até a próxima verificação completa. Uma vez por dia, na Janela de manutenção, cada conector lê todo o escopo configurado e remove do Knowledge os documentos cujos itens não existem mais na origem.
A verificação só remove documentos quando consegue ler o escopo inteiro. Se alguma parte do escopo falha (um site, uma pasta, um espaço, um repositório), nada é removido naquele dia, e a remoção fica para a próxima verificação que ler tudo. Com o conector pausado, a Janela de manutenção também fica suspensa.

​
Posso remover o documento antigo antes da verificação?

Sim, de duas formas. As duas ficam na página do contexto, em Knowledge. Sincronização completa. Na aba Conectores, abra o menu ao lado de Sincronizar no conector e escolha Sincronização completa. Ela faz na hora a mesma verificação da Janela de manutenção, com a mesma regra: só remove se ler o escopo inteiro. Remover documento. Na aba Documentos, passe o mouse sobre a linha do documento e clique no ícone de lixeira. O documento sai daquele contexto e continua nos outros contextos em que estiver.
Remover documento é definitivo só quando o item também saiu da origem. Se o item ainda existe e está no escopo do conector, uma sincronização seguinte pode trazê-lo de volta.

​
Se eu mudar quem tem acesso a um item, quando o Knowledge respeita a mudança?

O conector lê as permissões de um item no mesmo momento em que lê o conteúdo. A mudança chega ao Knowledge quando o item é relido:
  • Confluence (modo padrão) e Pipedrive releem tudo a cada sincronização, então a permissão nova chega na próxima sincronização.
  • Microsoft 365, Google Drive, GitHub e Confluence com modo incremental só releem o que mudou. Uma mudança só de permissão chega na próxima verificação completa. Se o item também foi editado, chega na próxima sincronização.
  • Fireflies relê as reuniões dos últimos 7 dias a cada sincronização. Reuniões mais antigas recebem a permissão nova na próxima verificação completa.
  • Salesbud não traz permissões da origem. Quem vê os documentos é definido pelas permissões do contexto.
Para que um corte de acesso valha antes, rode uma Sincronização completa no contexto.

​
Diferenças por conector

  • Um arquivo movido para outra biblioteca ou outro site vira um documento novo. O do local antigo sai na próxima verificação completa.
  • Só a versão atual de cada arquivo é lida. O histórico de versões não entra.
  • A verificação completa tem uma trava contra remoção em massa. Se ela fosse remover mais da metade dos documentos do conector, ou se as pastas voltassem vazias, nada é removido e um aviso aparece no conector.
  • Para seguir com a remoção, um admin clica em Liberar remoções e sincronizar nesse aviso. Uma sincronização completa roda com as remoções liberadas.
  • Por padrão, cada sincronização relê todas as páginas dos espaços selecionados. O modo incremental, que lê só as páginas modificadas, é ligado em Data Catalog, na Configuração da carga do conector.
  • Um espaço tirado da seleção do conector sai do Knowledge na próxima sincronização, sem esperar a verificação completa. É o único caso de remoção fora da verificação completa.
  • Páginas apagadas saem na próxima verificação completa.
  • Posts de blog e comentários não são indexados.
  • Só entram arquivos da branch padrão de cada repositório. Issues, pull requests, wikis e outras branches não viram documentos.
  • O documento é reconhecido pelo caminho do arquivo. Renomear ou mover um arquivo cria um documento novo, e o do caminho antigo sai na próxima verificação completa.
  • Apagar e recriar um arquivo no mesmo caminho mantém o mesmo documento.
  • Um repositório apagado, transferido ou fora do alcance do token tem os documentos removidos na próxima verificação completa.
  • Se você desliga o recurso repository_files no conector, os documentos já indexados continuam no Knowledge. Remova-os pelo contexto.
  • Só as notas viram documentos. Negócios, pessoas, organizações e atividades ficam como dados estruturados.
  • Uma nota apagada sai na próxima verificação completa.
  • O Salesbud não informa quando um registro muda, por isso cada sincronização relê todo o histórico.
  • As várias gravações de uma mesma reunião viram um único documento.
  • A remoção só acontece quando a verificação completa lê transcrições, respostas de reuniões e respostas de ligações. Se algum desses recursos estiver desligado no conector, nada é removido.
  • O Fireflies informa só a data da reunião, e não quando a transcrição mudou. Uma edição numa reunião com mais de 7 dias só chega ao Knowledge na verificação completa.
  • Cada execução lê no máximo 500 transcrições, por causa do limite de chamadas da API do Fireflies. Se o workspace tem mais que isso, a verificação completa não consegue ler tudo, e transcrições apagadas no Fireflies continuam no Knowledge. Remova-as pelo contexto.

​
Próximos passos

Frequência de sync

Como escolher de quanto em quanto tempo cada conector busca dados novos.

Knowledge

Como os documentos indexados abastecem a busca e as respostas dos agentes.

Catálogo de conectores

Todos os conectores disponíveis na plataforma.

Microsoft 365 (SharePoint)

Configuração do conector, escopos do Azure AD e limitações.