Registo de Atividade Diária

A1Arquitetura: onde se posiciona na plataforma

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

Toda a persistência é executada num único arquivo de documentos nativo de pesquisa; cada consulta transporta o identificador da organização como um filtro obrigatório na camada de consulta mais baixa. O isolamento de inquilinos é, portanto, estrutural — uma propriedade de como cada pedido é composto — e não uma política que depende de o código da aplicação se 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 é registada no arquivo de atividade de ferramentas — e esse arquivo, e não um sistema de análise paralelo, é o que a secção Relatórios agrega. Os números de utilização que vê são os números que a plataforma efetivamente registou.

Tudo o que sai do caminho do pedido — distribuição de notificações, entrega de webhooks, registo de atividades, correio — é executado em threads de segundo plano do tipo "disparar e esquecer". Um endpoint externo lento nunca pode fazer com que a interface encrave, e um efeito secundário falhado é registado em vez de ser repetido silenciosamente gerando inconsistência.

A3Considerações operacionais

As definições ao nível da organização, as ações destrutivas e as ligações estão restritas aos perfis de proprietário e administrador; os recrutadores operam a ferramenta nos registos que conseguem ver. As alterações de perfil aplicam-se no pedido seguinte — a aplicação é feita ao nível da rota e não no menu.

As falhas são apresentadas e não ocultadas: a validação no lado do servidor devolve o campo exato e o motivo, os erros dos fornecedores são citados textualmente quando há integrações envolvidas, e cada escrita confirma ou reporta. As exportações são regeneradas a pedido em vez de serem colocadas em cache — um relatório que descarrega reflete o estado no momento em que o pediu, e não o instantâneo da noite anterior.

Tudo o que escreve é seu para levar: as exportações em CSV e a aplicação Exportação de Dados abrangem os mesmos locais que o próprio produto lê. A saída é tão aberta quanto a entrada — por conceção, e não por concessão.

A4Interaction contract

A interface segue a convenção de pesquisar e selecionar da plataforma: qualquer campo que nomeie um registo real — um candidato, cliente ou vaga — é um seletor de escrever para pesquisar sobre dados em direto, nunca uma cadeia de caracteres escrita livremente, que é o que mantém os registos de atividades e a desduplicação fiáveis. As escolhas estáticas são caixas combinadas de filtrar à medida que escreve em vez de menus pendentes nativos, e as transições de estado fornecem feedback explícito: as confirmações do servidor surgem como notificações toast, os erros de validação nomeiam o campo exato e nada é apresentado como concluído que o servidor não tenha confirmado.

O esquema estrutural (wireframe) e o fluxo abaixo documentam o contrato estrutural da superfície — que painéis existem, por que ordem ocorrem os estados e o que acontece em cada limite — em vez de pixéis. O layout é composto com grelha CSS nativa (grid) e flexbox, adaptando-se de um ecrã de computador largo a uma única coluna sem vistas móveis separadas.