Uma tabela possui campos, a mesma família de tipos que você acabou de aprender: texto, números, datas, seleções, relações, arquivos. Pode ter visualizações e agregações salvas. Você pode exportá-lo. Você pode relacionar uma linha a uma pessoa, uma empresa ou outra tabela. Fluxos e Workflows podem ler e gravar quando você precisar de uma pesquisa ou de uma atualização simples.

Não possui tipos de registro. Não há Lead versus Contato dentro de uma tabela. Ele não carrega a camada CRM que você obtém em objetos: notas, tarefas e atribuições para usuários Frontline. Se você quiser converter uma linha, registrar uma chamada nela ou atribuir um proprietário a ela, você queria um objeto.

As permissões são um pouco mais flexíveis, de propósito. O esquema de um objeto é o modelo CRM compartilhado, portanto, apenas administradores e proprietários o remodelam. Uma tabela pertence à pessoa que a criou. Os administradores, o criador e qualquer pessoa com acesso total podem alterar as colunas. Isso faz das mesas um bom lugar para uma equipe manter uma lista de trabalho sem abrir um ticket para alterar o modelo da empresa.

Use uma tabela quando a linha suportar dados. Uma empresa patrimonial pode manter uma tabela de taxas, uma lista de carteiras modelo ou um conjunto de códigos de custódia. Uma equipe de vendas pode manter SKUs ou códigos de campanha. As operações podem manter uma lista de locais de escritórios que quase nunca precisam de uma reunião registrada.

O teste é o mesmo da lição de modelo de dados. Você atribuiria um proprietário, escreveria uma nota e voltaria à linha no próximo mês porque o relacionamento mudou? Se sim, é um objeto. Se você procurar apenas para preencher outro registro, é uma tabela.

O Harrington Family Office torna isso concreto. James é um Person. O family office é um Company. O mandato é um Deal. A mudança de beneficiário é um Ticket. Nenhum deles pertence a uma mesa. Os portfólios modelo da empresa sim. Cada carteira tem um nome, um perfil de risco, um mínimo e uma taxa. Os consultores relacionam James ou o negócio como “Balanced Tax-Aware”, em vez de digitar a taxa em um campo de texto em cada contato. Quando a taxa muda, você altera uma linha da tabela. Cada registro vinculado ainda aponta para o portfólio certo.

Uma tabela de taxas pode funcionar da mesma maneira: classe de ações, ponto de interrupção, taxa. Uma lista de custodiantes também pode, se cada custodiante for apenas um código e um nome. Se um custodiante se tornar um relacionamento real, com pessoas, tickets e uma sequência de e-mails, promova essa ideia para um Company ou para um objeto personalizado. Não estique uma mesa em um segundo CRM.

O movimento útil é uma relação. Um campo em People, Deals ou um objeto personalizado pode apontar para uma linha da tabela. James pode ter uma relação de portfólio modelo. O negócio pode ter o mesmo. Você obtém um rótulo limpo, um lugar para clicar e uma lista para manter.

Não copie os valores da tabela em campos de texto “para que apareçam no contato”. É assim que a taxa cobrada por James difere da taxa que está na mesa. Relacione e mostre a relação na visualização. Se você precisar de um número no negócio para uma fórmula, extraia-o da linha relacionada ou mantenha um campo de moeda única que você atualiza propositalmente. Duas cópias manuscritas irão divergir.

As tabelas também são uma boa entrada para automações. Um Workflow pode procurar uma taxa, escrever uma linha quando uma nova classe de compartilhamento aparecer ou manter uma lista sincronizada com um sistema externo. Como a mesa é plana, a automação permanece simples. Você não está convertendo tipos de registro nem mesclando cronogramas. Você está lendo uma lista.

O que você não deve fazer é recriar People ou Companies como uma tabela. Você perde a desduplicação, a sincronização de e-mail, o link automático da empresa, os perfis de IA e o histórico de atividades. Uma tabela “Contatos” é o atalho mais caro do produto. Use o objeto People.

Dê um nome à tabela para a lista que ela representa. “Portfólios modelo.” “Tabela de taxas.” “Códigos de custódia.” Dê as colunas que você procura e pare. Uma tabela que aumenta um status, um proprietário, uma data de fechamento e uma coluna de notas está tentando se tornar um objeto. Ouça isso. Mova o trabalho antes que a equipe invente um processo que a mesa não possa suportar.

As visualizações ainda ajudam. Uma tabela de taxas pode ter uma visualização por classe de ações. Uma lista de portfólio pode ser classificada por risco. As agregações podem totalizar mínimos ou contar linhas. Isso é suficiente. A riqueza deve ficar com James, o family office e o mandato, onde as atividades e os tipos de registro já fazem o trabalho.

Se a coisa for uma pessoa, uma empresa, um negócio, um ticket ou outro substantivo com ciclo de vida, ela é um objeto. Se a coisa for uma lista à qual os objetos devem fazer referência, é uma tabela. Se não tiver certeza, comece com um campo de seleção. Promova-o a uma tabela quando a lista precisar de colunas extras. Promova-o a um objeto quando ele precisar de vida própria.

Faça isso direito e o workspace permanecerá legível. People, empresas, negócios e tickets mantêm os relacionamentos. As tabelas contêm os dados de referência. Max, seus Workflows e um novo consultor podem encontrar a taxa da mesma maneira: na linha do portfólio, não enterrada em uma nota sobre James.

A seguir neste curso configuraremos visualizações, para que os mesmos objetos e tabelas possam mostrar um pipeline, uma lista de trabalho ou um quadro filtrado sem alterar o modelo abaixo.