Manter registros compartilhados

Resultado: um fato compartilhado está correto no Core, existe um único registro para ele, e os sistemas que o espelham mostram a mudança depois do próximo sync. Leitor: quem mantém o Core. É preciso acesso de edição a Core Record Types; trabalhe por Data views, não por Interfaces.

Escolha o registro certo

Procure antes de criar. Use People para identidade, Organizations para a entidade jurídica e Membership para a participação da pessoa nessa organização. Positions sobrevivem à troca de ocupante; Team e Department são unidades reais; Branch é um local de uma organização, nunca uma segunda organização. Address, City, State e Country descrevem lugares; crie uma City só quando um endereço precisar. Cadence, Classification Term e Tags são catálogos: reutilize uma entrada antes de criar outra.

Decida onde editar

Mudança	Editar em
Nome, identidade, contato ou dados da organização	O registro no Core
Datas, cargo ou equipe da membership	Membership, Positions, Team ou Department no Core
Um lugar	Address no Core, depois City, State ou Country se faltar
Definição, responsável, datas ou ciclo de vida de campanha	Views de intake de Campaign no Core
Definição de cadência	Cadence no Core; revise cada consumidor antes de mudar Key
Executor de tarefa, sujeito de meta ou responsável por observação	O registro em KPIs & OKRs e seu vínculo local
Relação comercial, interação, deal ou inscrição em campanha	O registro no CRM
Conta Slack ou escolha de workspace	Configuração de identidade em Tooling and Access
Valor desatualizado em um mirror	Primeiro o Core; depois investigue o sync. Nunca edite a cópia

Promova uma pessoa ou organização proposta

Linhas criadas pelos mirrors bidirecionais do CRM ou pelo workflow de agendamento do Cal.com devem chegar como Proposed. Revise-as com regularidade.

1. Abra People › by Tag e encontre o grupo da tag que marca a origem, como cal-lead-n8n. Linhas sem Status também precisam de revisão.
2. Procure em People pelo Email* (para uma Organization, procure Website°) um registro existente da mesma pessoa ou empresa.
3. Se houver duplicata, mantenha o registro mais antigo, mova para ele os vínculos necessários e marque o mais novo como Superseded. Ainda não há vínculo de fusão, então anote o registro sobrevivente em Notes.
4. Se for novo, complete o que Health check lista como faltante e mude Status para Active.

Sucesso: um registro Active por pessoa ou empresa, Health check próximo de ✅ e a linha do CRM ainda vinculada a ele depois do próximo sync.

Cadastre um lugar

1. Procure a linha da rua em Address. Reutilize se outra pessoa ou empresa já a usa.
2. Senão, crie o Address, preencha Street Address* e Type e vincule City, State e Country.
3. Se a cidade faltar, crie-a em Cities com Name e State e marque Active. States já tem as divisões dos Estados Unidos e do Brasil; cidades entram uma a uma, nunca por importação em massa.
4. Vincule o endereço a partir da Person (Address), da Organization (Primary Address ou Registered Agent Address) ou da Branch (Address).

Digite Zipcode com cuidado: é número e perde zero à esquerda.

Confira o mirror

Depois de uma correção, confira o valor na origem, depois o mirror correspondente, depois o lookup que o consome. Uma tabela com “mirror” no nome e rótulos iguais não provam a configuração do sync; confira as configurações de sync na base consumidora: base e view de origem, campos incluídos, filtros e última atualização. IDs de registro do Airtable são locais: nunca cole um ID de registro do Core no campo de vínculo de um consumidor. Se o mirror não atualizou, registre a origem e a hora da conferência em vez de criar outra identidade.

Diferenças de nome conhecidas

Origem no Core	Consumidor	Consequência
People: First Name*, Last Name*	Person (mirror) em KPIs & OKRs: Given Name, Family Name	Confira o mapeamento de colunas; não renomeie por suposição
Membership: Membership ID, Membership (Name)	Membership (mirror) em KPIs & OKRs: Membership #, Membership ID	Confira a chave usada pelos workflows; o Daily Digest lê o nome de Membership #
Organizations: Status, Legal Name*	Organization (mirror) em KPIs & OKRs: Lifecycle Status, Legal Name	Nomes da origem e da projeção diferem
Team	Memebership em KPIs & OKRs, Positions no CRM, Grid view em Tooling and Access	Essas tabelas consumidoras modelam equipes
Fórmulas e vínculos da origem	Valores copiados em texto ou número	O tipo de armazenamento no consumidor não prova cálculo local nem relacionamento

Confira os efeitos nos consumidores

Uma mudança de nome pode afetar a identificação de destinatário por nome do Daily Digest. Uma mudança de Key em Cadence pode alterar o casamento de itens devidos e as chaves de período. Uma mudança de status de Membership pode tirar uma pessoa de um seletor de responsável no CRM ou em KPIs & OKRs. Mantenha as restrições de destinatário de teste ao testar notificações.