Relacionamentos têm consequências

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 7 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Campos também são arquitetura · Próximo: Propriedade e ciclo de vida

A pergunta que este módulo responde: O que estou realmente escolhendo quando conecto dois objetos Salesforce?

Desenhar um relacionamento é fácil. No capítulo 2 desenhamos linhas e demos nomes a elas: um Parceiro varejista envia muitos manifestos, uma entrega leva muitos itens, equipes e caminhões se encontram numa Atribuição de equipe. Falamos de cardinalidade, opcionalidade e histórico. Agora implementamos essas linhas no Salesforce, e uma linha num diagrama passa a carregar muito mais peso.

Quando escolho um tipo de relacionamento no Salesforce, não estou só dizendo estes dois registros estão conectados. Também posso estar decidindo quem é dono do filho, se ele pode existir sem o pai, quem pode vê-lo, o que acontece quando o pai é excluído, se ele pode mudar para outro pai, se posso resumi-lo no pai, e o que acontece quando há centenas de milhares de filhos. Um relacionamento não é só uma linha. Ele carrega comportamento.

Comece pelo relacionamento de negócio

Antes de relacionamento de pesquisa ou mestre-detalhes, volte ao negócio. Pegue uma Entrega e seus Itens de entrega: a geladeira, a instalação, o recolhimento. Um item pode existir sem sua entrega? Não. Se a entrega for excluída, os itens devem ir junto? Sim. Os itens precisam de dono próprio ou de segurança própria? Na verdade, não. Alguém deveria mover um item de uma entrega para outra? Por acidente, espero que não.

Agora pegue uma Entrega e a Rota em que ela está. A entrega existe antes de ser roteirizada, pode ser movida para outra rota quando o plano muda, e excluir uma rota nunca deveria excluir as entregas nela. Duas linhas um-para-muitos que parecem iguais num diagrama, com comportamentos completamente diferentes. Repare que ainda não dissemos “relacionamento de pesquisa” nem “mestre-detalhes”. Descreva o comportamento primeiro. A configuração o implementa.

Os tipos de relacionamento

Abra a tela New Field (novo campo) e o Salesforce lhe oferece um punhado de tipos de relacionamento (Object Relationships Overview (opens in a new tab), em inglês):

• Relacionamento de pesquisa (lookup): liga dois objetos. É o arroz com feijão dos relacionamentos no Salesforce.
• Mestre-detalhes: um vínculo pai-filho em que o pai controla o filho.
• Muitos-para-muitos: não é um tipo de campo próprio, e sim um padrão: um objeto de junção do Salesforce (Salesforce Junction Object), um objeto personalizado com dois relacionamentos mestre-detalhes.
• Autorrelacionamento: um relacionamento de pesquisa de um objeto para ele mesmo.
• Hierárquico: um relacionamento de pesquisa especial que só existe no objeto Usuário (User), como o gerente de um usuário.
• Relacionamento de pesquisa externo (external lookup) e relacionamento de pesquisa indireto (indirect lookup): os relacionamentos com e a partir de objetos externos, os objetos __x do módulo 4. Um relacionamento de pesquisa externo aponta para um objeto externo pai; um relacionamento de pesquisa indireto aponta de um objeto externo para um objeto padrão ou personalizado, fazendo a correspondência por um ID externo exclusivo.

A maior parte do seu tempo de design vai para os três primeiros. Vamos pegar um de cada vez.

Relacionamento de pesquisa: estes registros estão conectados

Um relacionamento de pesquisa (lookup) diz: este registro está associado àquele registro. O filho mantém sua própria identidade, seu próprio dono e sua própria vida. Uma Entrega aponta para sua Rota. Se a rota é cancelada, as entregas não somem; voltam para ser roteirizadas de novo.

É engraçado: o campo de relacionamento de pesquisa fica no filho, mas o pai também ganha algo, uma lista relacionada com seus filhos. Então, quando você cria um, dê nome às duas pontas. O Related List Label (rótulo da lista relacionada) é o que as pessoas veem no pai, e o Child Relationship Name (nome do relacionamento filho) é o que desenvolvedores e integrações usam para ir do pai aos filhos. Não aceite os valores padrão.

Um relacionamento de pesquisa pode ser obrigatório ou opcional. Quando é opcional, você decide o que acontece se o registro para o qual ele aponta for excluído, e há três opções (Considerations for Object Relationships (opens in a new tab), em inglês):

• Clear the value of this field (limpar o valor deste campo), o padrão. O filho fica, com o relacionamento de pesquisa vazio.
• Don’t allow deletion (não permitir a exclusão) do registro do relacionamento de pesquisa. Tente excluir a rota, e o Salesforce diz não: ela faz parte de um relacionamento.
• Delete this record also (excluir este registro também), uma exclusão em cascata, como num mestre-detalhes. Só é oferecida para um relacionamento de pesquisa personalizado num objeto personalizado, vem desativada por padrão, e a Salesforce precisa ativá-la para a sua org, porque uma exclusão em cascata ignora a segurança e o compartilhamento: os usuários conseguem excluir registros que nem conseguiam ver.

Essa é uma decisão de ciclo de vida escondida numa tela de configuração.

Filtros de pesquisa (lookup filters) restringem o que um usuário pode escolher. Digamos que a Entrega tenha um relacionamento de pesquisa Instalador com Contato, e os instaladores sejam um tipo de registro de contato entre muitos. Um filtro de pesquisa mostra só os instaladores, e pode filtrar pelo registro atual, pelo registro que está sendo pesquisado e pelo usuário: o perfil, o papel ou as permissões dele (Lookup Filters (opens in a new tab), em inglês). É um jeito barato de manter um relacionamento de pesquisa honesto.

Mestre-detalhes: este filho pertence àquele pai

O mestre-detalhes faz uma afirmação muito mais forte. Em aula chamo isso de um vínculo muito apertado. Você não pode ter um detalhe sem o seu mestre; o campo do mestre é obrigatório. O detalhe perde seu próprio campo Proprietário e herda o proprietário do pai. Não há tabela de compartilhamento separada para o detalhe, então você não consegue compartilhar um filho sozinho; ele herda o compartilhamento do pai. É por isso que um objeto de detalhe não pode ter regras de compartilhamento, compartilhamento manual nem filas: todos precisam de um campo Proprietário (Object Relationships Overview (opens in a new tab), em inglês). No Setup, a configuração de compartilhamento dele aparece como Controlled by Parent (Controlado pelo pai). E no próprio campo mestre-detalhes você escolhe uma Sharing Setting (configuração de compartilhamento): se o usuário precisa de acesso Read Only (somente leitura) ou Read/Write (leitura/gravação) ao mestre para criar, editar ou excluir os detalhes dele. Excluir o mestre exclui seus detalhes. E o mestre ganha campos de resumo de totalização.

Então, se o Item de entrega é detalhe da Entrega, estou dizendo: este item pertence a esta entrega a vida inteira. Essa é a pergunta que quero respondida antes que alguém escolha Relacionamento mestre-detalhes no Setup.

A pergunta da exclusão

Eis minha forma favorita de descobrir se pensamos direito: o que deveria acontecer com os filhos se alguém excluir o pai? Todo mundo fica desconfortável. Ótimo. Agora estamos fazendo arquitetura.

Um Parceiro varejista tem centenas de milhares de entregas históricas. Alguém exclui o parceiro. As entregas deveriam desaparecer? Quase certamente não: as reclamações, o faturamento e o histórico dependem delas. Talvez excluir um parceiro nem devesse ser permitido, e o parceiro devesse ser desativado. Com o mestre-detalhes, excluir o mestre exclui em cascata os detalhes e os detalhes deles; restaurar o mestre os traz de volta (Considerations for Object Relationships (opens in a new tab), em inglês). Então, quando alguém diz “o mestre-detalhes nos dá resumos de totalização”, minha resposta é: ótimo. Com o que mais você acabou de concordar?

A propriedade vem de carona

Com um relacionamento de pesquisa, o filho pode ter seu próprio dono. Com o mestre-detalhes, não pode; o acesso segue o mestre. Isso está exatamente certo se o detalhe realmente faz parte do pai. Mas se o filho precisa de dono próprio, de compartilhamento próprio ou de ciclo de vida próprio, o modelo está dizendo que o mestre-detalhes é a escolha errada. O próximo módulo vai mais fundo na propriedade, e o curso de Compartilhamento e Visibilidade vai mais longe ainda. Por enquanto: design de relacionamentos e design de segurança não são conversas separadas. O modelo de dados molda o modelo de segurança antes que alguém escreva uma regra de compartilhamento.

Pai obrigatório ou opcional?

O filho pode existir antes de sabermos quem é o pai? Isso importa mais do que parece. Se as entregas chegam no manifesto na noite anterior e as rotas são montadas depois, uma Rota obrigatória na Entrega significaria que a roteirização precisa acontecer antes até de o registro poder ser criado. O relacionamento físico precisa sustentar o ciclo de vida real. Por isso não projeto relacionamentos só a partir de um diagrama estático. Quero saber: como eles nascem, podem existir sozinhos, podem se mover, e como morrem?

O filho pode trocar de pai?

Por padrão, um filho mestre-detalhes não pode ser movido para outro pai. Você pode permitir isso, selecionando Permitir reatribuição de pai (Allow reparenting) no relacionamento (Considerations for Object Relationships (opens in a new tab), em inglês). Meu instinto é conservador: se o negócio diz que o filho pertence a um pai a vida inteira, não facilito movê-lo. Um item mudar de uma entrega para outra deveria ser um evento de negócio deliberado, não uma edição de campo. De novo, a configuração não é a arquitetura. A regra de ciclo de vida é, e a configuração a implementa.

Mais duas coisas que pegam as equipes depois. Você não consegue criar um relacionamento mestre-detalhes num objeto que já tem dados; você cria um relacionamento de pesquisa, preenche em todos os registros e depois converte. E só consegue converter de volta para relacionamento de pesquisa se não houver campos de resumo de totalização no mestre. Preste atenção também no que a conversão faz com a segurança: transformar um relacionamento de pesquisa em mestre-detalhes define o compartilhamento do filho como Controlado pelo pai, e transformar um mestre-detalhes de volta em relacionamento de pesquisa define o padrão para toda a organização do filho como Public Read/Write (leitura/gravação pública) (Considerations for Object Relationships (opens in a new tab), em inglês). Registros que ontem eram privados hoje estão abertos, até alguém perceber. Escolha cedo.

Resumos de totalização são úteis, mas não são de graça

Gosto de resumos de totalização. Contar os itens de uma entrega, somar os valores das linhas de uma fatura, encontrar a data mais recente: nativo, sem código. O campo mestre-detalhes fica no filho, mas o resumo de totalização fica no pai. Só que eles vêm com letras miúdas (Roll-Up Summary Field (opens in a new tab), em inglês):

• Calcular os valores de totalização depois de certas mudanças (um novo campo de resumo, uma fórmula da qual ele depende alterada, um recálculo forçado) pode levar até 30 minutos, dependendo de quantos registros são afetados. Já vi gente se perguntando por que o número no pai ainda não mudou.
• Eles não conseguem resumir tudo. Um campo de numeração automática não pode ser o campo que você agrega. E um resumo de totalização só consegue resumir um campo de fórmula se essa fórmula não buscar dados em outro objeto e não usar uma função que muda sozinha, como NOW() ou TODAY(). Uma fórmula de “dias de atraso” construída sobre TODAY() muda toda noite sem que ninguém salve um registro, então não há nada a partir do qual o resumo de totalização possa recalcular. Esse tipo de número precisa de um flow agendado, ou de um relatório.
• O filtro também tem limites: nada de área de texto longo, lista de opções de seleção múltipla, Descrição, campos de sistema como Última atividade, fórmulas entre objetos ou campos de relacionamento de pesquisa.
• Os resumos de totalização não aparecem nas páginas de edição, então uma regra de validação pode usar um, mas não consegue mostrar o erro ali.

E não inverta a decisão. Não diga: “Precisamos de um resumo de totalização, então isto tem de ser mestre-detalhes.” Diga: “Este filho realmente pertence a este pai, a propriedade e o ciclo de vida se encaixam, e um dos benefícios são os resumos de totalização nativos.” Se a semântica não se encaixa, resolva o cálculo de outro jeito. Não distorça o modelo de dados para ganhar um recurso.

Então qual é o outro jeito? Você mesmo constrói o resumo: um campo no pai que guarda o valor calculado, e uma automação que o mantém atualizado. Digamos que o Parceiro varejista seja um relacionamento de pesquisa a partir da Entrega, como deve ser, e o negócio queira Entregas em aberto (Open Deliveries) no parceiro. Adicione um campo numérico, Entregas em aberto, ao parceiro. Depois um flow acionado por registro, ou um trigger Apex quando o volume ou a lógica pedirem código, recalcula esse campo sempre que uma entrega muda. Funciona sobre um relacionamento de pesquisa, pode filtrar por qualquer coisa e pode usar datas e fórmulas que um resumo de totalização nativo não consegue.

Mas agora acertar é responsabilidade sua, e é aí que essas coisas dão errado. A automação precisa disparar em toda mudança que importa: um filho novo, um filho editado, um filho excluído, um filho restaurado, e um filho movido para outro pai, o que significa recalcular tanto o pai antigo quanto o novo. Ela precisa aguentar uma carga de dados de 200 registros por vez sem bater nos limites. Reconte em vez de somar e subtrair, para que um evento perdido não deixe o número errado para sempre. Planeje um jeito de recalcular tudo, para a primeira carga e para o dia em que o número desandar. E lembre-se de que agora todo salvamento de filho atualiza o pai, então um pai com milhares de filhos traz de volta o bloqueio que veremos daqui a pouco. Um resumo de totalização nativo faz tudo isso por você; um personalizado é um pequeno software que passa a ser seu.

Três níveis de profundidade: empilhando mestre-detalhes

A plataforma tem uma forma, e o mestre-detalhes tem duas dimensões dela. A primeira é a profundidade.

Você pode empilhar mestre-detalhes em até três níveis de detalhe personalizados, e esse é o fundo (Considerations for Object Relationships (opens in a new tab), em inglês). Em aula desenho uma conta com um pedido (um), o pedido com seus itens (dois) e os itens com seus detalhes (três), e aí tento acrescentar um quarto e o Salesforce não deixa. Na Steve Trucking poderia ficar assim: uma Entrega é o mestre; seus Itens de entrega são o primeiro nível; as Tarefas de instalação (Install Tasks) de um item são o segundo; e as Etapas da tarefa (Task Steps) de cada tarefa são o terceiro. Um quarto nível, digamos uma Nota da etapa (Step Note), tem de ser um relacionamento de pesquisa.

Click to enlarge

Algumas regras vêm junto com a pilha:

• Objetos padrão não podem ficar do lado de detalhe de um objeto personalizado. Um objeto personalizado pode ser detalhe de Conta; Conta não pode ser detalhe do seu.
• Um objeto só pode aparecer uma vez numa pilha de vários níveis. O Salesforce não quer que você dê a volta em si mesmo: um subdetalhe não pode ser também o mestre do seu próprio mestre.
• O mestre não consegue totalizar o último nível diretamente. Se a Entrega quer o número de Etapas da tarefa, a Tarefa de instalação totaliza suas etapas, o Item de entrega totaliza esses resumos, e a Entrega totaliza os itens: um nível de cada vez.
• A propriedade e o compartilhamento vêm do topo. Todo nível herda o proprietário e o acesso do mestre.
• Excluir o mestre exclui tudo abaixo dele, e restaurá-lo traz tudo de volta.

Três níveis costumam ser mais que suficientes. Se o seu design fica pedindo um quarto, pergunte se cada nível realmente pertence ao de cima a vida inteira. E lembre-se de que é você quem escolhe qual ligação quebra a corrente. O quarto nível não precisa ser o relacionamento de pesquisa: talvez uma Tarefa de instalação não pertença de verdade ao seu Item de entrega, ela é agendada e atribuída por conta própria, então essa ligação vira um relacionamento de pesquisa, e agora a Tarefa de instalação começa uma nova corrente, com a Etapa da tarefa e a Nota da etapa abaixo dela. Escolha a ligação em que o filho realmente tem vida própria, e faça dela o relacionamento de pesquisa.

Click to enlarge

Agora a Tarefa de instalação tem proprietário próprio e compartilhamento próprio, uma entrega pode ser excluída sem levar junto suas tarefas de instalação, e a Tarefa de instalação pode ter mais dois níveis abaixo dela. Essa é a troca: a corrente fica mais curta, e a vida da tarefa de instalação é só dela.

Dois pais de largura: o objeto de junção do Salesforce

Primeiro, uma palavra sobre palavras, porque “objeto de junção” quer dizer duas coisas, e eu ensino as duas.

No capítulo 2 encontramos o objeto de junção lógico: a junção de duas ideias-chave que vira uma coisa própria, com atributos próprios. Um cachorro sabe muitos truques, um truque é conhecido por muitos cachorros, e o Truque do cachorro fica entre eles, guardando o nível de habilidade e a data. Isso é um objeto de junção lógico, no modelo lógico, muito antes de alguém decidir entre relacionamento de pesquisa e mestre-detalhes.

O Salesforce usa o termo de forma mais estreita. Quando o Salesforce diz objeto de junção, quer dizer um objeto personalizado com dois relacionamentos mestre-detalhes (Create a Many-to-Many Object Relationship (opens in a new tab), em inglês). Vou chamar isso de objeto de junção do Salesforce (Salesforce Junction Object). Todo objeto de junção do Salesforce é um objeto de junção lógico, mas nem todo objeto de junção lógico vira um objeto de junção do Salesforce: construa um com um mestre-detalhes e um relacionamento de pesquisa, ou com dois relacionamentos de pesquisa, e ele continua sendo um objeto de junção lógico, só que não do tipo Salesforce. (Nem o próprio Salesforce é perfeitamente consistente: a sua referência de objetos chama alguns objetos padrão construídos com relacionamentos de pesquisa de “objetos de junção”. No exame, assuma a definição estreita.)

Conhecimento para o exame. Um objeto de junção do Salesforce é um objeto personalizado com dois relacionamentos mestre-detalhes, e é isso que o Salesforce quer dizer quando fala em “objeto de junção”. O objeto de junção lógico é a ideia de modelagem mais ampla: qualquer objeto que une dois outros num muitos-para-muitos e carrega atributos próprios, não importa como seja construído.

A segunda dimensão é a largura. Um filho pode ter dois pais mestre-detalhes? Sim. Três? Não. Cada objeto personalizado pode ter até dois relacionamentos mestre-detalhes (Considerations for Object Relationships (opens in a new tab), em inglês). Dois pais mestre-detalhes é como você constrói um objeto de junção do Salesforce para um muitos-para-muitos. Equipe e Caminhão se encontram numa Atribuição de equipe, e, como vimos no capítulo 2, isso não é encanamento: ela tem uma data, uma rota, talvez um status. A junção é onde o relacionamento vira um conceito de negócio. As dicas da Salesforce para construir uma: dê a ela um nome que diga o que ela é, faça o nome do registro ser uma numeração automática, e renomeie a lista relacionada de cada mestre com o nome do outro mestre, para que a página da Equipe mostre “Caminhões” e a página do Caminhão mostre “Equipes” (Create a Many-to-Many Object Relationship (opens in a new tab), em inglês).

Eis a sutileza. Um dos dois pais é o principal, e é aquele cujo campo mestre-detalhes você criou primeiro. Não há nenhuma indicação visual de qual é, então é uma clássica pergunta de prova, e uma clássica surpresa.

O que o principal decide? Três coisas (Create a Many-to-Many Object Relationship (opens in a new tab), em inglês):

• Aparência. As páginas da junção usam a cor e o ícone do mestre principal.
• Proprietário. Os registros de junção herdam o proprietário do registro mestre principal. Você nunca vê isso, porque um detalhe não tem campo Proprietário; só importa se mais tarde você remover os dois relacionamentos mestre-detalhes.
• Divisão, se a sua org usa divisões, do mesmo jeito.

E o outro é o secundário. O que isso significa?

• Ele é o próximo da fila para virar principal. Exclua o campo mestre-detalhes principal ou converta-o em relacionamento de pesquisa, e o secundário vira o principal.
• Ele define o escopo dos relatórios. O Salesforce lhe dá dois tipos de relatório: “Primary master with junction object and secondary master” (mestre principal com objeto de junção e mestre secundário) e “Secondary master with junction object and primary master” (mestre secundário com objeto de junção e mestre principal). O mestre listado primeiro decide quais registros o relatório pode mostrar.
• Ele conta tanto quanto para o acesso. É assim que eu digo: a propriedade vem do principal, o acesso vem dos dois, e o mais restritivo vence. Uma junção, como qualquer detalhe, não tem tabela de compartilhamento própria. O Salesforce verifica o acesso do usuário aos dois registros mestres, pela Sharing Setting de cada campo mestre-detalhes. Se as duas estiverem como Read/Write, o usuário precisa de Read/Write na equipe e no caminhão para editar a Atribuição de equipe (Considerations for Object Relationships (opens in a new tab), em inglês).
• Ele exclui tanto quanto. Exclua qualquer um dos mestres, a equipe ou o caminhão, e os registros de junção dele vão para a Lixeira. Exclua os dois e eles somem de vez.

Click to enlarge

Mais algumas regras: os dois mestres podem ter resumos de totalização a partir da junção, e as fórmulas e regras de validação da junção podem alcançar campos dos dois. Mas uma junção não pode ser mestre de mais nada, então não pode ficar no meio de uma pilha, e os dois mestres não podem ser o mesmo objeto; um muitos-para-muitos de um objeto com ele mesmo precisa de outro design. E se um pai tem mais de 200 registros de junção e a junção totaliza para o outro pai, o Salesforce não deixa você excluir esse pai até que tenha removido registros suficientes.

Então: qual pai deveria ser o principal? Crie primeiro aquele que é dono do significado. Numa Atribuição de equipe, quem faz o trabalho é a equipe, então eu criaria a Equipe primeiro. E depois anote isso, porque nada na tela vai contar para a próxima pessoa.

Dito tudo isso, não acabo com muitos objetos de junção do Salesforce. Normalmente um objeto tem um pai mestre-detalhes, e ele é do mesmo tipo de dado: dados de cliente sob dados de cliente, transacionais sob transacionais (lembre-se dos tipos de dados do capítulo 2: de cliente, transacionais, de referência). Quando o outro pai é de outro tipo, geralmente um objeto de referência, esse relacionamento é um relacionamento de pesquisa. Um Item de entrega pertence à sua Entrega: mestre-detalhes, os dois transacionais. Ele aponta para o Produto que carrega com um relacionamento de pesquisa, porque um produto é dado de referência com vida própria, e ninguém quer que excluir um produto leve junto anos de histórico de entregas. O Item de entrega continua sendo um objeto de junção lógico entre uma entrega e os produtos nela; só não é um objeto de junção do Salesforce.

Autorrelacionamentos: quando a linha volta

Um objeto pode se relacionar consigo mesmo: uma conta pai, um gerente, um centro de distribuição que responde a um hub regional. O Salesforce já traz dois que você vai encontrar em quase toda org: Conta para Conta, o campo Conta pai que monta a hierarquia de contas, e Caso para Caso, o Caso pai do módulo 2, que agrupa casos relacionados. Um autorrelacionamento precisa ser um relacionamento de pesquisa, e um registro não pode apontar para si mesmo, embora dois registros possam apontar um para o outro (Considerations for Object Relationships (opens in a new tab), em inglês). No objeto Usuário é um tipo especial próprio, o relacionamento hierárquico, usado para coisas como o gerente de um usuário. A mecânica é fácil; o nome é o que importa. Um relacionamento de pesquisa de Centro de distribuição para Centro de distribuição chamado Distribution_Center__c não ajuda ninguém. Pai? Reserva? Excedente? Dê ao relacionamento o nome do papel, não do objeto para o qual ele aponta.

Click to enlarge

Hierárquico: o relacionamento próprio do objeto Usuário

Este é pequeno, e é exatamente o tipo de fato pouco conhecido e único que eu esperaria ver numa prova. Hierárquico é um relacionamento de pesquisa especial que só existe no objeto Usuário (User). Ele liga um usuário a outro usuário, e o Salesforce não deixa a corrente dar a volta: um usuário não pode apontar para si mesmo, direta ou indiretamente (Object Relationships Overview (opens in a new tab), em inglês). Se o gerente da Maria é o Dev, o gerente do Dev não pode ser a Maria, nem ninguém que responda, subindo a cadeia, à Maria.

Essa é a diferença em relação aos autorrelacionamentos acima. Na Conta ou num objeto personalizado, dois registros podem apontar um para o outro. No Usuário, a hierarquia tem de continuar sendo uma hierarquia. E é o único jeito de relacionar Usuário com Usuário: um relacionamento de pesquisa comum de Usuário para ele mesmo não é oferecido.

Você já tem um. O campo padrão Manager (Gerente) do Usuário é um relacionamento hierárquico, e as aprovações podem usá-lo: envie esta solicitação ao gerente de quem a enviou. Você também pode criar os seus, digamos um Contato de escalonamento ou um Aprovador substituto, e uma aprovação pode seguir por ele do mesmo jeito (ApprovalProcess, Metadata API (opens in a new tab), em inglês). Não confunda com a hierarquia de papéis, que determina o acesso aos registros. Um campo hierárquico é só um relacionamento entre usuários; ele não compartilha nenhum registro.

Conhecimento para o exame. O relacionamento hierárquico só existe no objeto Usuário, como o campo padrão Manager, e um usuário não pode apontar para si mesmo, direta ou indiretamente. Ele não é a hierarquia de papéis.

Relacionamentos também têm limites

Cada objeto pode ter no máximo dois relacionamentos mestre-detalhes. Campos de relacionamento de pesquisa e mestre-detalhes, juntos, contam como campos de relacionamento: 40 por objeto por padrão, no máximo 50 mediante solicitação. Campos de resumo de totalização: 25 por objeto por padrão, no máximo 40 (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab), em inglês). A Salesforce acrescenta que aumentar qualquer um desses limites pode afetar o desempenho.

Você não precisa projetar com esses números em mente; precisa perceber quando está perto deles. Um objeto com relacionamento atrás de relacionamento pendurado nele está lhe dizendo algo. Talvez ele seja mesmo tão central. Ou talvez o modelo esteja errado. (E vale a regra de folga do capítulo 18: fique bem abaixo de um limite, medido contra o terceiro ano.)

A pergunta dos 10 mil filhos

Depois há o pai com filhos demais. A própria orientação da Salesforce é não passar de cerca de 10 mil registros filhos para um único pai mestre-detalhes (Considerations for Object Relationships (opens in a new tab), em inglês), e o guia dela sobre acesso a registros em escala diz o mesmo para relacionamentos pai-filho em geral (Parent-Child Data Skew (opens in a new tab), em inglês). O registro 10.001 não quebra a org. Mas a partir daí, salvar um filho pode bloquear o pai, e mudanças de compartilhamento no pai se propagam por todos os filhos.

Então, quando vejo um pai, números enormes de filhos, pergunto: por que estão todos sob o mesmo pai, quem é dono deles, como são consultados, e que automação mexe no pai? Todas as entregas sob uma única conta “Steve Trucking” passariam de 10 mil em poucos dias. Um um-para-muitos inocente vira um problema de desequilíbrio (skew). O próximo módulo dá uma prévia do desequilíbrio, e a Parte 2 vai fundo.

Não projete a linha pelo recurso

Este é o hábito que quero deste módulo. Não comece por “preciso de um resumo de totalização”, “preciso que seja obrigatório”, “quero compartilhamento herdado”. Essas são pistas de implementação. Comece pelo negócio: o filho tem vida própria, quem é dono dele, ele pode existir sozinho, pode se mover, o que acontece quando o pai vai embora, o relacionamento carrega dados, e quão grande cada lado pode ficar? Depois escolha o relacionamento que implementa as respostas.

Click to enlarge

Além do exame: o que a IA muda. A IA consegue propor relacionamentos em segundos. Ela não consegue lhe dizer se o negócio algum dia vai excluir o pai. Diagramar mais rápido não torna um relacionamento errado mais barato de reverter depois que milhões de registros e dezenas de automações dependem dele.

O que um arquiteto decide aqui

• Se o filho tem ciclo de vida próprio ou realmente pertence ao pai, e se a propriedade e o acesso devem ser próprios ou herdados.
• Se o filho pode existir sem um pai, mudar entre pais, ou sobreviver à exclusão do pai.
• O que cada relacionamento de pesquisa faz quando o pai é excluído: limpar, bloquear ou excluir em cascata.
• Se um muitos-para-muitos é encanamento ou um conceito de negócio, se o objeto de junção lógico vira um objeto de junção do Salesforce, qual pai é o principal, e o que os dois pais significam para o acesso.
• Se o modelo se encaixa na forma da plataforma: três níveis de detalhe personalizados de profundidade, dois pais mestre-detalhes de largura, os limites de relacionamentos e de resumos de totalização.
• Se o número e a distribuição esperados de filhos criam um risco de desequilíbrio que deveria mudar o design.

Um relacionamento é um conjunto de promessas sobre como dois dados se comportam juntos. Faça-as de forma deliberada.

Para saber mais

• Salesforce Help, Considerations for Object Relationships (opens in a new tab) (em inglês), consultado em 2026-10-13.
• Salesforce Help, Object Relationships Overview (opens in a new tab) e Create a Many-to-Many Object Relationship (opens in a new tab) (em inglês), consultados em 2026-10-13.
• Salesforce Help, Roll-Up Summary Field (opens in a new tab) (em inglês), consultado em 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (em inglês), consultado em 2026-10-13.
• Salesforce Help, Lookup Filters (opens in a new tab) (em inglês), consultado em 2026-10-13.
• Salesforce Help, Increase the Maximum Relationships Allowed per Object (opens in a new tab) e Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (em inglês), consultados em 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (em inglês), consultado em 2026-10-02.