Registro Diário de Atividades

A1Arquitetura: onde se posiciona na plataforma

Registro Diário de Atividades is a first-class module of the Produtividade e Bem-estar do Recrutador suite inside the authenticated Expertini ATS workspace. A plataforma é intencionalmente renderizada no servidor: cada visualização é preparada pelo servidor da aplicação e enviada como HTML completo, sem framework no lado do cliente, sem scripts de CDN de terceiros e sem pipeline de compilação entre os dados e a página. O que é renderizado é exatamente o que o servidor processou — a propriedade que torna a interface auditável.

Toda a persistência é executada em um único armazenamento de documentos nativo de busca; cada consulta carrega o identificador da organização como um filtro obrigatório na camada mais baixa de consulta. O isolamento de tenants é, portanto, estrutural — uma propriedade de como cada requisição é composta — e não uma política que depende de o código do aplicativo lembrar de verificar.

Availability is governed by the platform's tool registry: this tool is registered from the Starter plan, and access is enforced server-side by the registry gate on every request — never by hiding a button. Plans also carry a monthly distinct-tool quota (3 / 5 / 15 / 30 / 45 across Trial→Business, unlimited on Enterprise), counted at the same chokepoint. The pricing page states both honestly: what is available, and how much of it the month includes.

A2Modelo de dados e mapa de dependências

In production the tool reads and writes ats_planner_logs, job requisitions (ats_jobs), pipeline applications (ats_applications). Documents are plain, explicitly-mapped fields — mappings are provisioned ahead of first write, so term filters and aggregations behave deterministically instead of depending on inferred types.

Cada abertura distinta é registrada no log de atividades da ferramenta — e esse registro, e não um sistema paralelo de análise, é o que a seção de Relatórios consolida. Os números de uso visualizados são os dados efetivamente registrados pela plataforma.

Tudo o que sai do caminho da solicitação — disparo de notificações, entrega de webhooks, registro de atividades em diário, e-mails — é executado em threads de segundo plano no modelo fire-and-forget. Um endpoint externo lento nunca fará a interface travar, e uma falha de efeito secundário é registrada em log em vez de ser repetida silenciosamente gerando inconsistências.

A3Considerações operacionais

Configurações em nível organizacional, ações destrutivas e conexões são restritas às funções de proprietário e administrador; recrutadores utilizam a ferramenta nos registros que podem visualizar. Alterações de função passam a valer na requisição seguinte — o controle é feito na rota, não no menu.

As falhas são exibidas, não ignoradas: a validação no servidor retorna o campo e o motivo exatos, os erros de fornecedores são citados textualmente quando há integrações envolvidas e cada gravação confirma ou reporta o status. As exportações são geradas novamente mediante solicitação, em vez de serem armazenadas em cache — um relatório baixado reflete o banco de dados no momento da solicitação, não um snapshot da noite anterior.

Tudo o que foi registrado é seu: as exportações em CSV e o aplicativo de Exportação de Dados abrangem os mesmos repositórios que o próprio produto consulta. A saída é tão acessível quanto a entrada — por definição de projeto, e não por concessão.

A4Interaction contract

A interface segue a convenção de busca e seleção da plataforma: qualquer campo que nomeie um registro real — um candidato, cliente ou vaga — é um seletor de digitação para pesquisa sobre dados em tempo real, nunca uma cadeia de texto digitada livremente, o que mantém as trilhas de atividade e a desduplicação confiáveis. As opções estáticas são menus com filtro por digitação em vez de listas suspensas nativas, e as transições de estado oferecem feedback explícito: as confirmações do servidor aparecem como notificações temporárias (toasts), os erros de validação identificam o campo exato e nada é exibido como concluído sem a confirmação do servidor.

O wireframe e o fluxo abaixo documentam a estrutura funcional da interface — quais painéis existem, em que ordem os estados ocorrem e o que acontece em cada extremidade — em vez de pixels. O layout é composto com CSS grid e flexbox nativos e se adapta de monitores amplos a uma única coluna sem a necessidade de visualizações móveis separadas.