> ## Documentation Index > Fetch the complete documentation index at: https://strattumai.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Atualização e remoção de documentos > O que acontece no Knowledge quando um documento é editado, recriado, apagado ou muda de permissão na origem, em cada conector de documentos, e quando cada mudança aparece. 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)](/data-pipelines/connectors/microsoft-365.md), [Google Drive](/data-pipelines/connectors/google-drive.md), [Confluence](/data-pipelines/connectors/confluence.md), [GitHub](/data-pipelines/connectors/github.md), [Pipedrive](/data-pipelines/connectors/pipedrive.md), Salesbud e Fireflies. ## Como funciona Dois ciclos mantêm o Knowledge em dia com a origem: | Ciclo | Quando roda | O que faz | | - | - | - | | **Sincronização** | Na agenda de cada conector | Lê o que é novo ou mudou e atualiza o Knowledge. **Não remove** documentos que saíram da origem. A exceção é o Confluence, que remove na hora os espaços tirados da seleção | | **Verificação completa** | Uma vez por dia, na Janela de manutenção, ou quando você pede uma **Sincronização completa** | Lê todo o escopo do conector e remove do Knowledge o que não existe mais na 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 | Conector | O que vira documento | Como o documento é reconhecido | Como uma edição é percebida | Agenda padrão (UTC) | | - | - | - | - | - | | Microsoft 365 (SharePoint) | Arquivos das bibliotecas dos sites selecionados | ID do arquivo no SharePoint | Data de modificação do arquivo | A cada 6 horas | | Google Drive | Arquivos das pastas configuradas | ID do arquivo no Drive | Data de modificação do arquivo | A cada 6 horas | | Confluence | Páginas e anexos dos espaços selecionados | ID da página ou do anexo | Cada sincronização relê todas as páginas. Com o modo incremental ligado, só as modificadas | A cada 6 horas | | GitHub | Arquivos Markdown, texto, CSV, PDF e Word da branch padrão de cada repositório | Repositório e caminho do arquivo | Commit novo na branch padrão | A cada 2 horas | | Pipedrive | Notas | ID da nota | Cada sincronização relê todas as notas | A cada 6 horas | | Salesbud | Transcrições de reuniões e respostas de reuniões e ligações | A reunião ou a ligação | Cada sincronização relê todo o histórico | A cada 4 horas | | Fireflies | Transcrição e resumo de cada reunião | ID da reunião | Cada sincronização relê as reuniões dos últimos 7 dias | Uma vez por dia, às 06:00 | A agenda de cada conector pode ser trocada na configuração dele. Ver [Frequência de sync](/data-pipelines/sync-frequency.md). Depois de cada sincronização, o Knowledge ainda leva alguns minutos para processar os documentos. ## Resumo por tipo de mudança | Mudança na origem | Como o Knowledge trata | Quando aparece | | - | - | - | | Item editado e salvo | O mesmo documento, com o conteúdo novo no lugar do antigo | Na próxima sincronização | | Item apagado e criado de novo, mesmo com o mesmo nome | Um documento novo. O antigo continua até ser removido. No GitHub, um arquivo recriado no mesmo caminho é o mesmo documento | O novo, na próxima sincronização. O antigo sai na próxima verificação completa | | Item apagado | Documento removido | Na próxima verificação completa | | Arquivo salvo com outro nome ("Salvar como") | Um documento novo, separado do original | Na próxima sincronização | | Permissão alterada sem editar o item | O mesmo documento, com a nova lista de acesso | Quando o item é relido. Veja [a pergunta sobre permissões](#se-eu-mudar-quem-tem-acesso-a-um-item-quando-o-knowledge-respeita-a-mudança) | | Item restaurado da lixeira | O documento volta ao Knowledge | No máximo na próxima verificação completa | As exceções de cada conector estão em [Diferenças por conector](#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. > [!TIP] > > 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. | Item | Valor | | - | - | | Frequência | Uma vez por dia, por conector | | Horário padrão | 03:00 no fuso configurado no servidor da instalação. Sem fuso configurado, vale UTC (00:00 no horário de Brasília) | | Onde ajustar | Em Microsoft 365, Google Drive e Confluence: em **Conectores**, abra o conector em **Editar** e vá em **Sincronização** > **Janela de manutenção**. Nos demais conectores vale o horário padrão | > [!WARNING] > > 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. > [!NOTE] > > **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 > **Microsoft 365 (SharePoint)** > > * 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. > **Google Drive** > > * 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. > **Confluence** > > * 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. > **GitHub** > > * 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. > **Pipedrive** > > * 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. > **Salesbud** > > * 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. > **Fireflies** > > * 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](/data-pipelines/sync-frequency.md)** > > Como escolher de quanto em quanto tempo cada conector busca dados novos. > **[Knowledge](/knowledge/overview.md)** > > Como os documentos indexados abastecem a busca e as respostas dos agentes. > **[Catálogo de conectores](/connectors/overview.md)** > > Todos os conectores disponíveis na plataforma. > **[Microsoft 365 (SharePoint)](/data-pipelines/connectors/microsoft-365.md)** > > Configuração do conector, escopos do Azure AD e limitações. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.