Arquitetura e responsabilidades

O Core é o único escritor dos registros compartilhados. Toda outra base é um domínio: espelha as tabelas do Core de que precisa, liga seus próprios registros aos mirrors e nunca edita os fatos compartilhados. Quando um mirror e o Core divergem, o Core está certo. Essa regra está proposta, ainda não adotada; sua aceitação é um Work Item aberto.

Quem pode gravar no Core

Escritor	O que grava	Evidência
Pessoas que mantêm o Core	Qualquer tabela do Core, por Data views e intakes em grid	Data views
Mirrors bidirecionais do CRM	Novas People e Organizations criadas a partir das tabelas People e Companies do CRM	Exceção bidirecional do CRM (abaixo); views do Core chamadas Base Fields - Two Way Sync
n8n Cal.com Booking Intake	Novas linhas de People com Status Proposed e a tag cal-lead-n8n	Agendamento Cal.com
Automação do Airtable no Core	coreId em novas linhas de Campaign	Automações

O CRM é uma exceção a “o Core nunca é bidirecional”, com dois guarda-corpos: linhas nascidas em um domínio entram como Proposed e o Core as promove, e cada linha tem uma chave de duplicidade visível (e-mail para Person, site ou domínio para Organization). Nada grava Proposed automaticamente: uma linha criada pelo CRM sem Status fica em branco até alguém preenchê-lo. A exceção ainda não foi escrita na regra proposta do Core. Confirme nas configurações de sync do CRM que a configuração bidirecional está ativa antes de contar com ela.

Quem lê o Core

Os mirrors são reconhecidos pelo nome da tabela e pelo formato dos campos. O nome da tabela sozinho não prova a view de origem, os campos incluídos nem o comportamento de atualização.

Sistema	Tabelas do Core espelhadas	Nomes das tabelas locais
KPIs & OKRs	People, Organizations, Membership, Positions, Department, Team, Cadence, Tags, Campaign	Person (mirror), Organization (mirror), Membership (mirror), Position (mirror), Department (mirror), Memebership, Cadence (mirror), op:tags, Sync - Campaign
CRM	People, Organizations, Membership, Organization Relationships, Classification Term, Team, Department, Positions, Tags, Campaign	People, Companies, Membership (mirror), BusinessRelationship (mirror), schema:DefinedTerm, Team, Positions, Department, bds:position, Tags, Campaign (mirror)
Tooling and Access	People, Organizations, Membership, Department, Team, Tags	Person (mirror), Organization (mirror), Membership (mirror), Department (mirror), Grid view, Tags (mirror)
Communication	People, Organizations, Membership, Department, Team, Classification Term, Tags	Person (mirror), Organization (mirror), Membership (mirror), Department (mirror), Team (mirror), Classification Term (mirror), Tags (mirror)
Systems Central	Organizations, Membership, Tags	Organization (mirror), Membership (mirror), Tags (mirror)
Products & Services	Organizations, Tags	Organization (mirror), Tags (mirror)

Três nomes locais escondem um mirror de Team: Memebership em KPIs & OKRs, Positions no CRM e Grid view em Tooling and Access. Address, Cities, States, Countries e Branch não têm consumidor.

O que está verificado em cada sync

Contrato	Direção	O que se sabe
Campaign → CRM	Unidirecional	View de origem Sync - Campaign com 16 campos; linhas excluídas na origem são mantidas no CRM. Verificado em 21/10/2026.
Tags → Tooling, Communication, Systems Central, Products	Unidirecional	Só Name, Kind e notes; linhas removidas na origem são mantidas. Verificado na UI do Airtable em 22/10/2026.
People e Organizations → CRM	Bidirecional por regra	Não confirmado nas configurações de sync. O Core tem uma view Base Fields - Two Way Sync em cada tabela.
Todos os outros mirrors	Não verificado	View de origem, campos, filtros e atualização são desconhecidos.

Um Work Item pede um contrato de sync escrito por domínio: escritor, atualização e regra de conflito. Enquanto ele não existir, trate o valor de um mirror como possivelmente desatualizado e confira o Core primeiro.

Regras que decorrem do espelhamento

• Vínculos entre mirrors só sobrevivem quando as duas tabelas são espelhadas juntas. Por isso Person, Organization, Membership, Position, Department e Team viajam como conjunto.
• IDs de registro do Airtable são locais de cada base. Nunca cole um ID de registro do Core no campo de vínculo de um consumidor.
• Uma coluna que um domínio acrescenta em um mirror, como um vínculo local de Tags, pertence a esse domínio e nunca chega ao Core.
• Cada base comporta no máximo 20 tabelas sincronizadas no plano atual, então cada novo mirror gasta uma vaga.

Diagrama apenas do caminho consumidor de KPIs & OKRs. Não afirma sincronização automática.