Temporalidade no Alfresco: eventos, retenção e bloqueio sem exclusão automática

Autoria institucional: Arquindex · Publicado em 21/10/2026 · Atualizado em 21/10/2026 · Leitura técnica e informativa

ARQ-ARTICLE-20261021-ALFRESCO-TEMPORALIDADE

Resposta direta: no Alfresco, a temporalidade deve começar pela classe documental e pelo evento que inicia a contagem. O sistema pode calcular datas, alertar responsáveis, impedir alterações, abrir uma revisão e registrar decisões. Ele não deve apagar automaticamente um documento apenas porque uma data chegou. A eliminação depende do instrumento aplicável, da competência de quem decide, de impedimentos jurídicos ou operacionais e das evidências exigidas para a destinação.

Por que um prazo cadastrado não é uma política de temporalidade

É comum receber uma planilha com colunas como “tipo documental”, “cinco anos” e “eliminar” e tentar convertê-la diretamente em uma regra de pasta. Esse atalho ignora perguntas essenciais. Cinco anos contados de qual fato? Da produção, do encerramento do processo, do desligamento do empregado, do fim da vigência contratual ou da aprovação de um relatório? O documento está na fase corrente ou intermediária? Existe uma ação judicial, auditoria, investigação, garantia, obrigação contratual ou ordem de preservação que suspenda a contagem? Quem pode confirmar a destinação?

A tabela de temporalidade e destinação é um instrumento de gestão. O software ajuda a executá-lo, mas não cria por conta própria a autoridade arquivística nem substitui a avaliação que fundamentou os prazos. No setor público, a Lei nº 8.159/1991 e os procedimentos do CONARQ definem responsabilidades específicas. A Resolução CONARQ nº 40/2014, com alterações da Resolução nº 44/2020, trata da eliminação de documentos digitais e não digitais no âmbito do SINAR e condiciona o procedimento às instâncias e instrumentos competentes. Empresas privadas também precisam separar obrigações legais, regulatórias, fiscais, trabalhistas, contratuais e necessidades de defesa; não devem copiar automaticamente a tabela de outro órgão.

Por isso, a primeira decisão de projeto não é “qual ação do Alfresco apaga o arquivo?”, e sim “qual evidência prova que o evento ocorreu, qual regra passou a valer e quem pode decidir a etapa seguinte?”. Essa inversão reduz exclusões indevidas e torna a automação auditável.

As seis camadas que precisam continuar separadas

Tags podem ajudar a localizar documentos, mas são frágeis como único mecanismo de temporalidade. Um usuário pode digitar variações, apagar a tag ou aplicá-la ao item errado. Prefira propriedades com valores controlados, validação, permissões e histórico. Categorias também não substituem um plano de classificação formal; elas podem apoiar navegação, desde que a relação com a classe seja definida e governada.

Modelo de metadados para uma implementação verificável

Identidade arquivística

Registre identificador persistente, classe, tipo documental, unidade produtora, processo ou dossiê relacionado, data de produção e responsável pelo registro. O identificador não deve depender apenas do nome do arquivo. Renomear “contrato_final_final2.pdf” não pode romper o vínculo com seu histórico, anexos e aditivos.

Evento e origem da data

Crie campos separados para o tipo de evento, a data do evento e a fonte da confirmação. Um contrato pode ter “término da vigência” como evento; um dossiê funcional pode depender do desligamento; um projeto de engenharia pode aguardar o aceite definitivo. A data calculada de destinação deve ser derivada, e não digitada livremente por qualquer usuário. Se o evento ainda não aconteceu, o sistema deve mostrar “aguardando evento”, em vez de inventar uma data.

Regra e versão

Guarde o código da regra, a versão do instrumento, sua data de aprovação e os prazos aplicados. Quando uma tabela muda, o histórico precisa explicar qual versão sustentou cada cálculo. Recalcular silenciosamente todo o acervo pode antecipar ou adiar destinações sem análise. O plano de migração deve identificar documentos afetados, comparar resultados e exigir aprovação antes da atualização em massa.

Estado e bloqueio

Use estados claros, por exemplo: ativo, aguardando evento, em retenção corrente, em retenção intermediária, elegível para revisão, suspenso, aprovado para transferência, aprovado para eliminação, destinado e erro. O bloqueio precisa ter motivo, responsável, data, abrangência e critério de liberação. Um campo booleano chamado “não apagar” não é suficiente quando ninguém sabe por que foi marcado ou quando deve ser revisto.

Procedimento em nove etapas

1. Delimite o acervo. Liste classes, sistemas de origem, documentos físicos correspondentes e unidades responsáveis. Não comece pelo repositório inteiro.
2. Valide o instrumento. Confirme autoria, aprovação, abrangência, versão, eventos, prazos e destinações. Registre lacunas para decisão, sem preenchê-las por suposição.
3. Modele os metadados. Defina tipos, aspectos, campos obrigatórios, vocabulários, relacionamentos e regras de edição. Documente o dicionário de dados.
4. Mapeie eventos confiáveis. Determine se a data virá de um usuário autorizado, de um workflow, de integração com RH/ERP ou de aceite formal. Trate cancelamentos e reaberturas.
5. Calcule sem executar. Na primeira fase, gere somente datas previstas e relatórios de elegibilidade. Compare uma amostra com cálculo manual.
6. Implemente bloqueios. Teste processos judiciais, auditorias, contratos suspensos, investigação e indisponibilidade do aprovador. Um bloqueio deve prevalecer sobre a data calculada.
7. Crie o workflow de revisão. A tarefa deve mostrar documento, classe, regra, evento, prazos, impedimentos, decisão sugerida e evidências. Permita devolver para correção.
8. Gere o lote de destinação. Agrupe itens aprovados, produza relação verificável e aplique as formalidades cabíveis antes da execução.
9. Execute e reconcilie. Compare o que foi autorizado com o que foi efetivamente processado. Registre falhas, itens não encontrados, hashes e responsável pela conclusão.

O e-ARQ Brasil, versão 2, aprovado pela Resolução CONARQ nº 50/2022, oferece um modelo de requisitos para sistemas informatizados de gestão arquivística. Ele é referência especialmente para integrantes do SINAR, mas também ajuda equipes privadas a formular requisitos de captura, classificação, acesso, auditoria, preservação e destinação. Isso não significa que instalar Alfresco transforme automaticamente o ambiente em SIGAD aderente; a avaliação depende de configuração, processos, integrações, governança e evidências.

Alfresco Content Services e Governance Services: não são a mesma coisa

Alfresco Content Services oferece repositório, metadados, permissões, versionamento, pesquisa, regras, APIs e recursos de auditoria que podem sustentar um projeto documental. Alfresco Governance Services acrescenta funções específicas de records management, classificação, retenção e disposição. A disponibilidade varia conforme edição, versão, licenciamento e arquitetura. Antes de prometer “temporalidade nativa”, registre exatamente quais componentes estão instalados e suportados.

Em uma implantação Community ou em uma versão legada, parte do comportamento pode ser construída com modelo de conteúdo, regras, jobs, workflows e extensões. Essa alternativa exige testes e manutenção cuidadosos. Uma regra de pasta simples pode mover ou transformar um arquivo, mas não equivale a uma agenda de retenção governada. Da mesma forma, um script executado pelo administrador não substitui segregação de funções e aprovação documental.

Para novos projetos, mantenha ambientes de desenvolvimento, homologação e produção. Use documentos sintéticos para testar datas antigas, eventos futuros, bloqueios, duplicidades e falhas. Registre versão do código, configuração, parâmetros e resultado. Um teste visual com um único arquivo não demonstra que milhares de documentos serão tratados corretamente.

Permissões, auditoria e continuidade

Separe quem cadastra a classe, quem altera a regra, quem confirma o evento, quem aprova a destinação e quem executa a ação final. Contas técnicas devem ter escopo mínimo e credenciais protegidas. Alterações em propriedades críticas precisam aparecer na trilha de auditoria ou em registro complementar imutável. Logs também podem conter dados pessoais e informações sensíveis; defina acesso e retenção para eles.

Faça backup e teste restauração antes de ativar rotinas de destinação. Backup não é justificativa para eliminar sem autorização, nem deve se transformar em retenção infinita de tudo. A política precisa explicar como cópias de segurança expiram, como bloqueios alcançam réplicas relevantes e como uma restauração evita reintroduzir documentos já destinados sem controle.

Monitore filas, tarefas vencidas, documentos sem classe, datas ausentes, regras desativadas e falhas de integração. Indicadores úteis incluem percentual classificado, eventos confirmados, itens elegíveis, bloqueios ativos, tempo de aprovação, erros de execução e reconciliações pendentes. “Quantidade apagada” não deve ser o principal indicador de sucesso.

Erros comuns que o projeto deve impedir

• Contar o prazo desde o upload quando a tabela determina outro evento.
• Aplicar regra de uma classe a todos os documentos de uma pasta.
• Permitir que qualquer usuário altere a data inicial ou retire o bloqueio.
• Apagar anexos sem avaliar o vínculo com o processo ou documento principal.
• Confundir lixeira, exclusão lógica e destruição definitiva.
• Recalcular o acervo após mudança de tabela sem relatório de impacto.
• Usar automação para encobrir lacunas do instrumento de temporalidade.
• Prometer aderência ao e-ARQ apenas com base no nome do produto.
• Executar em massa sem amostra, homologação, backup e plano de reversão.

Checklist de aceite

• Classe, evento, prazo, destinação e versão da regra estão visíveis.
• Documentos sem evento não recebem data fictícia.
• Bloqueio suspende a elegibilidade e exige justificativa para liberação.
• Perfis e segregação de funções foram testados com usuários reais de homologação.
• Alterações de metadados críticos deixam evidência consultável.
• Workflow permite aprovar, rejeitar, devolver e registrar exceção.
• Lote autorizado é reconciliado com o resultado executado.
• Restauração e reversão foram testadas antes da produção.
• O manual distingue obrigação legal, política interna e requisito contratual.
• Responsável por revisar regras e versões está formalmente definido.

Perguntas frequentes

Fontes oficiais e referências técnicas

• CONARQ — e-ARQ Brasil, versão 2, publicação aprovada pela Resolução nº 50, de 6 de maio de 2022. Consulta em 21/10/2026.
• CONARQ — Resolução nº 50/2022. Consulta em 21/10/2026.
• CONARQ — Resolução nº 40/2014, alterada. Página atualizada em 18/08/2021; consulta em 21/10/2026.
• Lei nº 8.159, de 8 de janeiro de 1991, política nacional de arquivos públicos e privados. Consulta em 21/10/2026.
• Alfresco Documentation — Governance Services. Documentação técnica consultada em 21/10/2026; recursos variam por versão e edição.

Limite deste conteúdo: o artigo apresenta método técnico e não substitui avaliação jurídica, arquivística ou regulatória do acervo. Requisitos do setor público não devem ser transplantados para empresas privadas sem análise, e políticas internas não podem contrariar obrigações aplicáveis.

Leituras e soluções relacionadas

• Plano de classificação e tabela de temporalidade: por onde começar.
• Implantação e organização documental com Alfresco ECM.
• Gestão documental e organização de acervos.
• Índice mestre de databook: completude e aprovação.