BDS0.1

Arquitetura e responsabilidades

O que a Communication mantém, o que espelha e o que nunca conhece.

Revisado 2026-10-28Markdown

A Communication mantém quatro tabelas: Channel, Channel Binding, Notification Rule e Message. O Core mantém Organization, Person, Membership, Department, Team, Classification Term e Tags. O Tooling and Access mantém Tool e Tool Workspace. Os nove mirrors são cópias somente leitura; só as colunas de vínculo criadas nesta base são locais.

Siga os dados

Core e Tooling → mirrors na Communication → vínculos locais a partir de Channel, Channel Binding, Notification Rule e Message. Um Channel fica em um Tool e um Tool Workspace. Um Channel Binding aponta um Channel para um assunto (Team, Department, Organization ou Agreement) com um propósito. Uma Notification Rule indica o canal, o tipo de registro e o público (Team, Department ou Membership). Uma Message vincula seu Channel, sua Rule e seus destinatários (Membership ou Person).

Os fluxos n8n gravam linhas de Message de fora da base. O Daily Digest resolve o destinatário no Slack pelo Tooling and Access, depois encontra a Membership do destinatário nesta base pelo Membership # compartilhado e grava a linha de entrega. Veja Entregas do Daily Digest.

Mirrors e direção do sync

Mirror Origem Colunas locais
Organization (mirror) Core Record Types, Organizations Channel Bindings, Tags (local)
Person (mirror) Core Record Types, People Messages (Recipient), Tags
Membership (mirror) Core Record Types, Membership Notification Rules (Audience), Messages (Recipient), Tags
Department (mirror) Core Record Types, Department Channel Bindings, Notification Rules (Audience), Tags
Team (mirror) Core Record Types, Team Channel Bindings, Notification Rules (Audience), Tags
Classification Term (mirror) Core Record Types, Classification Term Notification Rules (Record Type), Tags
Tags (mirror) Core Record Types, Tags Vínculos inversos de todas as tabelas
Tool (mirror) Tooling and Access, Tools Channels, Tags
Tool Workspace (mirror) Tooling and Access, Tools Workspaces Channels, Tags

As descrições das tabelas declaram um sync de mão única, somente leitura, a partir da origem. Confira a view de origem e o intervalo de atualização nas configurações de sync do Airtable antes de contar com eles. Vínculos da origem que chegam como vínculo (por exemplo Membership → Member) não têm inverso aqui; vários chegam como texto (por exemplo Organization → Memberships) e não podem ser seguidos dentro desta base.

Preserve os limites

A Communication nunca vincula Relationship, Deal, Receivable ou Observation. Uma base consumidora lê as mensagens por uma view sincronizada própria e as vincula localmente; esse sync ainda não existe. Uma Message é uma tentativa de entrega, não uma conversa nem um resultado de negócio: a resposta de KPI é uma Observation no KPIs & OKRs, o contato comercial é uma Interaction no CRM. Um Channel Binding diz para onde vão as mensagens de um assunto; não concede acesso. Uma Notification Rule diz quem é avisado; nunca decide quem pode ler um registro.

Regras registradas no Systems Central

O Systems Central lista seis regras para este sistema. Nenhuma é imposta pela própria base.

Regra Aplicação
A message is one delivery attempt, unique by external ID Revisão manual
A sent message is never edited Revisão manual
Work finds its channel through a channel binding Revisão manual
The person behind an account comes from its binding Automação e revisão manual
Communication never knows sales or billing records Não aplicada
Email threads map to one interaction, emails to messages Não aplicada (Email Logging inativo)

Corrija os fatos na origem

Corrija pessoas, organizações, memberships e catálogos no Core; ferramentas e workspaces no Tooling and Access. Corrija canais, bindings, regras e vínculos de mensagens aqui. As descrições dos mirrors declaram as cópias como somente leitura; não use uma coluna de mirror para corrigir um fato da origem.