Suporte Okai

Aplica-se a: Logs de acesso, trilhas de alteração e auditoria para investigar permissões, exclusões, mudanças de status e rastreabilidade.

Log responde a uma pergunta de rastreabilidade

Consultar logs não é abrir uma lista para procurar culpados. O objetivo é reconstruir uma linha do tempo confiável: qual conta entrou, em qual workspace, quando uma ação aconteceu, qual item foi afetado e que tipo de evento a Okai registrou naquele momento.

Esse histórico ajuda quando há dúvida sobre acesso indevido, alteração de status, exclusão, mudança de permissão, edição de cadastro, atualização de configuração ou diferença entre o que alguém lembra e o que ficou registrado. A consulta fica mais útil quando começa com uma pergunta específica, como quem alterou esta tarefa ontem à tarde, quando este convite foi aceito ou se alguém visualizou o item antes da reunião.

O log mostra eventos observáveis pelo produto. Ele não substitui contexto operacional, aprovação formal, ata, evidência anexada ou justificativa escrita. Se a pergunta envolve motivo, decisão de negócio ou interpretação de uma regra, use o log para ancorar data, pessoa e ação, e combine essa informação com o registro funcional correspondente.

Boa investigação começa estreita: Antes de pesquisar, escreva a hipótese em uma frase: preciso confirmar se a permissão de Ana foi alterada no workspace Jurídico em 3 de junho. Essa frase define pessoa, ação, ambiente e período, que são os filtros que mais reduzem ruído.

Defina o recorte antes de abrir a tela

A maioria das consultas difíceis falha por recorte fraco, não por falta de log. Um relato como alguém excluiu algo ontem costuma gerar muitos eventos parecidos. Já um recorte com item, área, horário aproximado, workspace e ação esperada permite comparar eventos próximos e separar acesso, tentativa, alteração efetiva e automações do sistema.

• Workspace: confirme o ambiente antes de pesquisar. Logs de outro workspace podem mostrar pessoas e ações reais, mas não respondem à pergunta certa.
• Pessoa ou conta: use e-mail, nome exibido ou identificador interno quando disponível. Em contas corporativas, confira se a pessoa entrou pelo e-mail esperado.
• Período: trabalhe com data, horário aproximado e fuso. Se o relato veio de outra localidade, converta ou amplie a janela para não perder o evento.
• Tipo de evento: diferencie login, visualização, criação, edição, exclusão, convite, alteração de permissão e processamento automático.
• Item afetado: tenha em mãos nome, código, URL, projeto, tarefa, norma, documento ou configuração relacionada à investigação.

Não conclua pelo primeiro evento parecido: Dois eventos próximos podem envolver o mesmo item sem terem o mesmo significado. Abrir uma página, carregar uma lista e salvar uma alteração são registros diferentes. Compare tipo de evento, horário, pessoa e item antes de documentar a conclusão.

Consultar acesso e alteração

1. Abra a área de logs na administração: Use o menu de configuração ou administração do workspace para acessar logs, auditoria ou registros de atividade. Confirme no cabeçalho que o workspace ativo é o mesmo da situação investigada.
2. Comece pelo período mais provável: Informe a data e uma janela de horário próxima ao relato. Quando houver incerteza, amplie aos poucos, por exemplo de uma hora para um dia, em vez de buscar todo o histórico de uma vez.
3. Filtre por pessoa, item ou tipo de evento: Use o filtro que estiver mais seguro. Se você sabe a pessoa, comece por ela. Se sabe o item, procure por ele. Se sabe apenas que houve exclusão ou permissão, use o tipo de evento e depois refine.
4. Leia os eventos em sequência: Ordene por horário e observe o que aconteceu antes e depois da ação principal. A linha do tempo costuma revelar se houve login recente, troca de workspace, abertura do item, edição, salvamento, falha, desfazimento ou nova alteração por outra pessoa.
5. Abra o registro funcional relacionado: Quando o log apontar uma tarefa, projeto, documento, convite ou configuração, confira também o registro na área correspondente da Okai. A auditoria mostra o evento; a tela funcional mostra o estado atual e, quando houver, evidências ou comentários.

Use mais de um caminho quando a pergunta for sensível: Para uma investigação de exclusão, permissão ou alteração crítica, pesquise por pessoa e por item. Se os dois caminhos levam ao mesmo evento, a conclusão fica mais forte. Se divergem, a divergência é parte do diagnóstico e deve ser investigada antes de fechar o chamado.

Como interpretar o que apareceu

Um evento de log normalmente combina quem executou, quando executou, de onde executou ou em qual contexto, qual ação foi registrada e qual objeto foi afetado. Nem todo evento terá todos os detalhes visíveis na mesma profundidade, especialmente quando a ação veio de integração, importação, rotina interna ou processamento assíncrono.

• Acesso confirma entrada, tentativa, sessão ou abertura de área. Ele não significa, sozinho, que houve alteração.
• Visualização confirma que uma página, item ou lista foi consultado. Ela não prova aceite, aprovação, edição ou ciência formal.
• Criação indica que um registro novo nasceu naquele momento, mas pode ser preciso conferir se ele foi preenchido manualmente, importado ou gerado por fluxo do produto.
• Edição indica mudança em dados existentes. Quando o log mostra campos alterados, compare valor anterior, valor novo e contexto do item.
• Exclusão ou arquivamento exige atenção ao tipo de remoção. Em alguns fluxos, o item deixa a lista principal sem desaparecer definitivamente.
• Alteração de permissão deve ser lida junto com papel, grupo, workspace e data de vigência do acesso.

Sistema também executa ações: Quando o responsável do evento aparece como sistema, serviço, importador ou integração, investigue o fluxo que disparou a ação. Não traduza isso automaticamente como ação manual de uma pessoa.

Feche a linha do tempo

Depois de localizar os eventos relevantes, transforme a consulta em uma conclusão verificável. Uma boa devolutiva não precisa copiar todos os registros encontrados; ela precisa explicar o que foi confirmado, o que não foi encontrado e quais limites a consulta tem.

1. Registre a pergunta investigada: Escreva a dúvida original de forma objetiva, como confirmar quem alterou o status da tarefa X em 4 de junho.
2. Anote os filtros usados: Inclua workspace, período, fuso, pessoa, tipo de evento e item pesquisado. Isso permite que outra pessoa reproduza a consulta se a auditoria pedir.
3. Descreva os eventos relevantes: Informe data, horário, conta, ação e item. Quando houver eventos próximos, diga por que um deles é o evento principal e os demais são contexto.
4. Separe confirmação de ausência: Se nada apareceu, registre que não houve evento encontrado dentro daqueles filtros. Isso é diferente de afirmar que a ação nunca aconteceu em qualquer condição.
5. Vincule a conclusão ao chamado ou à auditoria: Cole a conclusão no chamado, relatório interno ou registro de auditoria. Preserve os detalhes necessários, mas evite expor dados pessoais ou informações sensíveis além do necessário.

Quando a conclusão depender de política interna, aprovação ou conversa fora da Okai, deixe isso explícito. O log pode confirmar que uma permissão mudou às 16h12, mas talvez não informe por que a mudança foi solicitada ou se a aprovação estava em outro canal.

Quando o evento esperado não aparece

A ausência de resultado não deve virar conclusão apressada. Primeiro revise as hipóteses que mais costumam deslocar a busca: ambiente errado, horário impreciso, fuso diferente, tipo de evento inadequado, item renomeado, ação feita por integração ou relato baseado no estado atual do item, não no momento da alteração.

• Confira se a pessoa estava no workspace correto no momento da ação.
• Amplie o período para antes e depois do horário informado, principalmente quando o relato veio de e-mail, agenda ou conversa sem fuso claro.
• Pesquise pelo item e não só pela pessoa. Outra conta, grupo, integração ou administrador pode ter executado a ação.
• Troque o tipo de evento. Uma mudança percebida como exclusão pode ter sido arquivamento, cancelamento, alteração de status ou perda de permissão de visualização.
• Verifique se o item mudou de nome, projeto, coleção ou pasta depois do evento.
• Consulte o estado atual do registro funcional para confirmar se a alteração realmente existe ou se a diferença vem de filtro aplicado na tela.

Não corrija a narrativa para caber no log: Se o histórico não sustenta a hipótese inicial, trate como descoberta. Ajustar rótulos, ignorar eventos próximos ou escolher somente o trecho conveniente compromete a auditoria. Reabra a pergunta, amplie o recorte e documente o que foi encontrado.