Arquitetura
Entenda limites do sistema, responsabilidade pelos dados e conexões entre ferramentas.
Mapa do sistema
| Camada | Responsabilidade | Leitura ou gravação |
|---|---|---|
| Base KPI | Indicadores, metas, objetivos, tarefas, programações e observações | Configuração e persistência da coleta |
| Espelhos Core Record Types | Pessoas, organizações, memberships, cadências, tags e campanhas | Projeções e vínculos locais; colunas Tags em todas as tabelas |
| Tooling and Access | Identidades, Tool Account, Tool Workspace e Identity Binding | Resolução de destinatário e origem de credenciais |
| Communication | Message, Channel, Notification Rule e espelho de membership | Registros de entrega |
| Data Table n8n | Cache de tokens por workspace | Credenciais e metadados de atualização |
| Slack | Solicitações, interações e evidências originais | Modal, digest e origem de anexos |
Configuração → itens previstos → destinatário → cache → solicitação Slack → resposta → Observation → atualização da mensagem. Evaluation é uma camada separada; nenhum workflow deste sistema a preenche.
Relacionamentos existentes
Milestone ← Task → Metric Target → Metric conecta objetivos ao trabalho mensurável. Recurrence Configuration → Metric Target e → Membership define a coleta. Observation → Metric, Membership e Recurrence Configuration registra a resposta. Evaluation pode vincular Observations e Metric Targets, e Milestone.Diagnostics pode vincular Evaluations. Não há vínculo direto Milestone–Metric Target nem tabela própria de Key Result/Cycle no esquema verificado.
Versão e limites da implementação
O esquema embutido nos workflows se identifica como communication-collection.v5. Contém IDs fixos de base, tabela e campo. A seleção de credenciais é dinâmica por workspace, mas os KPIs continuam nesta base configurada; não há roteamento automático entre bases de clientes. A referência descreve entidades canônicas preservando nomes atuais em inglês e campos de referência em texto. As 26 tabelas estão em Entidades.
Base legada Operations
A base legada “Operations” não faz parte deste sistema. Ela reunia vários sistemas que depois foram separados no Core e nas bases “- Pedro”. A tabela Set Recurring dela era o modelo antigo de KPI: cada linha era um molde, e uma automação clonava uma Task por pessoa a cada ciclo.
Em 21/10/2026, as 252 linhas ativas (Stage Assigned, não arquivadas) foram migradas para cá. Linhas idênticas foram unidas, resultando em 159 Metrics, 193 Metric Targets e 193 Recurrence Configurations, todas Active, Version 1, com início em 21/10/2026 e sem histórico de Observation. O dia da semana antigo ficou como texto em Event Schedule. Seis linhas ficaram de fora: sem responsável ou de uma empresa de teste. Esta base agora pergunta pelo Daily Digest, sem uma Task por ocorrência.
Pausar a automação Set Recurring do Operations ainda está pendente: o Work Item “Pause Operations Set Recurring so KPIs are not asked twice” estava To Do em 28/10/2026. Até isso ser feito, uma pessoa pode receber a mesma KPI pelas duas bases. Confira na base legada Operations se Set Recurring continua ligada. Descrições de campo daqui que trazem @airtable_table: Operation V2 - Pedro[...] usam um nome antigo desta base de KPI, não a base legada Operations. A chave interna operation do workflow Daily Digest também é só um rótulo; ela aponta para esta base.