As relações têm consequências

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto 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 sustenta-se sozinho. Anterior: Os campos também são arquitetura · Próximo: Propriedade e ciclo de vida

A pergunta que este módulo responde: O que estou realmente a escolher quando ligo dois objetos Salesforce?

Desenhar uma relação é fácil. No capítulo 2 desenhámos linhas e demos-lhes nomes: um Parceiro retalhista envia muitos manifestos, uma entrega leva muitos artigos, equipas e camiões encontram-se numa Atribuição de equipa. Falámos 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 relação no Salesforce, não estou só a dizer estes dois registos estão ligados. Também posso estar a decidir quem é dono do filho, se pode existir sem o pai, quem o pode ver, o que acontece quando o pai é eliminado, se pode passar para outro pai, se o posso resumir no pai, e o que acontece quando há centenas de milhares de filhos. Uma relação não é só uma linha. Carrega comportamento.

Comece pela relação de negócio

Antes de relação de pesquisa ou mestre-detalhe, volte ao negócio. Pegue numa Entrega e nos seus Itens de entrega: o frigorífico, a instalação, a recolha. Um item pode existir sem a sua entrega? Não. Se a entrega for eliminada, os itens devem ir com ela? 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 numa Entrega e na Rota em que está. A entrega existe antes de ter rota, pode ser movida para outra rota quando o plano muda, e eliminar uma rota nunca deveria eliminar as entregas que contém. Duas linhas um-para-muitos que parecem iguais num diagrama, com comportamentos completamente diferentes. Repare que ainda não dissemos «relação de pesquisa» nem «mestre-detalhe». Descreva primeiro o comportamento. A configuração implementa-o.

Os tipos de relação

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

• Relação de pesquisa (lookup): liga dois objetos. É o pão nosso de cada dia das relações no Salesforce.
• Mestre-detalhe: uma ligação pai-filho em que o pai controla o filho.
• Muitos-para-muitos: não é um tipo de campo próprio, mas sim um padrão: um objeto de junção do Salesforce (Salesforce Junction Object), um objeto personalizado com duas relações mestre-detalhe.
• Autorrelação: uma relação de pesquisa de um objeto para ele próprio.
• Hierárquica: uma relação de pesquisa especial que só existe no objeto Utilizador (User), como o gestor de um utilizador.
• Relação de pesquisa externa (external lookup) e relação de pesquisa indireta (indirect lookup): as relações com objetos externos e a partir deles, os objetos __x do módulo 4. Uma relação de pesquisa externa aponta para um objeto externo pai; uma relação de pesquisa indireta 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 num de cada vez.

Relação de pesquisa: estes registos estão ligados

Uma relação de pesquisa (lookup) diz: este registo está associado àquele registo. O filho mantém a sua própria identidade, o seu próprio dono e a sua própria vida. Uma Entrega aponta para a sua Rota. Se a rota é cancelada, as entregas não desaparecem; voltam a ter de ser planeadas.

É curioso: o campo de relação de pesquisa fica no filho, mas o pai também ganha algo, uma lista relacionada com os seus filhos. Por isso, quando cria uma, 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 da relação filha) é o que os programadores e as integrações usam para ir do pai aos filhos. Não aceite os valores por defeito.

Uma relação de pesquisa pode ser obrigatória ou opcional. Quando é opcional, decide o que acontece se o registo para o qual aponta for eliminado, 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), a opção por defeito. O filho fica, com a relação de pesquisa vazia.
• Don’t allow deletion (não permitir a eliminação) do registo da relação de pesquisa. Tente eliminar a rota, e o Salesforce diz que não: faz parte de uma relação.
• Delete this record also (eliminar também este registo), uma eliminação em cascata, como numa mestre-detalhe. Só é oferecida para uma relação de pesquisa personalizada num objeto personalizado, vem desativada por defeito, e a Salesforce tem de a ativar para a sua org, porque uma eliminação em cascata ignora a segurança e a partilha: os utilizadores conseguem eliminar registos que nem sequer conseguiam ver.

É uma decisão de ciclo de vida escondida num ecrã de configuração.

Filtros de pesquisa (lookup filters) restringem o que um utilizador pode escolher. Digamos que a Entrega tem uma relação de pesquisa Instalador para Contacto, e os instaladores são um tipo de registo de contacto entre muitos. Um filtro de pesquisa mostra só os instaladores, e pode filtrar pelo registo atual, pelo registo que está a ser pesquisado e pelo utilizador: o perfil, a função ou as permissões dele (Lookup Filters (opens in a new tab), em inglês). É uma forma barata de manter uma relação de pesquisa honesta.

Mestre-detalhe: este filho pertence àquele pai

A mestre-detalhe faz uma afirmação muito mais forte. Nas aulas chamo-lhe uma ligação muito apertada. Não pode ter um detalhe sem o seu mestre; o campo do mestre é obrigatório. O detalhe perde o seu próprio campo Proprietário e herda o proprietário do pai. Não há tabela de partilha separada para o detalhe, por isso não consegue partilhar um filho sozinho; herda a partilha do pai. É por isso que um objeto de detalhe não pode ter regras de partilha, partilha manual nem filas: todas precisam de um campo Proprietário (Object Relationships Overview (opens in a new tab), em inglês). No Setup, a sua definição de partilha aparece como Controlled by Parent (Controlado pelo pai). E no próprio campo mestre-detalhe escolhe uma Sharing Setting (definição de partilha): se o utilizador precisa de acesso Read Only (só de leitura) ou Read/Write (leitura/escrita) ao mestre para criar, editar ou eliminar os detalhes dele. Eliminar o mestre elimina os seus detalhes. E o mestre ganha campos de resumo de totalização.

Por isso, se o Item de entrega é detalhe da Entrega, estou a dizer: este item pertence a esta entrega a vida inteira. É a pergunta a que quero resposta antes de alguém escolher Relação mestre-detalhe no Setup.

A pergunta da eliminação

Eis a minha forma favorita de descobrir se pensámos bem: o que deveria acontecer aos filhos se alguém eliminar o pai? Toda a gente fica desconfortável. Ótimo. Agora estamos a fazer arquitetura.

Um Parceiro retalhista tem centenas de milhares de entregas históricas. Alguém elimina o parceiro. As entregas deveriam desaparecer? Quase de certeza que não: as reclamações, a faturação e o histórico dependem delas. Talvez eliminar um parceiro nem devesse ser permitido, e o parceiro devesse ser desativado. Com a mestre-detalhe, eliminar o mestre elimina em cascata os detalhes e os detalhes destes; restaurar o mestre trá-los de volta (Considerations for Object Relationships (opens in a new tab), em inglês). Por isso, quando alguém diz «a mestre-detalhe dá-nos resumos de totalização», a minha resposta é: ótimo. Com que mais acabou de concordar?

A propriedade vem por arrasto

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

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 o planeamento das rotas tem de acontecer antes sequer de o registo poder ser criado. A relação física tem de sustentar o ciclo de vida real. Por isso não projeto relações só a partir de um diagrama estático. Quero saber: como nascem, podem existir sozinhas, podem mover-se, e como morrem?

O filho pode mudar de pai?

Por defeito, um filho mestre-detalhe não pode ser movido para outro pai. Pode permiti-lo, selecionando Permitir reatribuição de pai (Allow reparenting) na relação (Considerations for Object Relationships (opens in a new tab), em inglês). O 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 passar de uma entrega para outra deveria ser um evento de negócio deliberado, não uma edição de campo. Mais uma vez, a configuração não é a arquitetura. A regra de ciclo de vida é, e a configuração implementa-a.

Mais duas coisas que apanham as equipas mais tarde. Não consegue criar uma relação mestre-detalhe num objeto que já tem dados; cria uma relação de pesquisa, preenche-a em todos os registos e depois converte. E só consegue voltar a converter para relação de pesquisa se não houver campos de resumo de totalização no mestre. Preste também atenção ao que a conversão faz à segurança: transformar uma relação de pesquisa em mestre-detalhe define a partilha do filho como Controlado pelo pai, e transformar uma mestre-detalhe de novo em relação de pesquisa define o padrão para toda a organização do filho como Public Read/Write (leitura/escrita pública) (Considerations for Object Relationships (opens in a new tab), em inglês). Registos que ontem eram privados hoje estão abertos, até alguém reparar. Escolha cedo.

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

Gosto de resumos de totalização. Contar os artigos de uma entrega, somar os valores das linhas de uma fatura, encontrar a data mais recente: nativo, sem código. O campo mestre-detalhe fica no filho, mas o resumo de totalização fica no pai. Só que vêm com letras pequeninas (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 de que depende alterada, um recálculo forçado) pode levar até 30 minutos, conforme o número de registos afetados. Já vi gente a perguntar-se porque é que o número no pai ainda não mudou.
• Não conseguem resumir tudo. Um campo de numeração automática não pode ser o campo que agrega. E um resumo de totalização só consegue resumir um campo de fórmula se essa fórmula não for buscar dados a 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 todas as noites sem que ninguém guarde um registo, por isso 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 relação de pesquisa.
• Os resumos de totalização não aparecem nas páginas de edição, por isso uma regra de validação pode usar um, mas não consegue mostrar o erro lá.

E não inverta a decisão. Não diga: «Precisamos de um resumo de totalização, por isso isto tem de ser mestre-detalhe.» Diga: «Este filho pertence realmente a este pai, a propriedade e o ciclo de vida encaixam, e um dos benefícios são os resumos de totalização nativos.» Se a semântica não encaixa, resolva o cálculo de outra forma. Não distorça o modelo de dados para ganhar uma funcionalidade.

Então qual é a outra forma? Constrói o resumo você mesmo: um campo no pai que guarda o valor calculado, e uma automação que o mantém atualizado. Digamos que o Parceiro retalhista é uma relação de pesquisa a partir da Entrega, como deve ser, e o negócio quer Entregas em aberto (Open Deliveries) no parceiro. Acrescente um campo numérico, Entregas em aberto, ao parceiro. Depois um flow acionado por registo, ou um trigger Apex quando o volume ou a lógica pedirem código, recalcula esse campo sempre que uma entrega muda. Funciona sobre uma relação 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 estas coisas correm mal. A automação tem de disparar em todas as mudanças que importam: um filho novo, um filho editado, um filho eliminado, um filho restaurado, e um filho movido para outro pai, o que significa recalcular tanto o pai antigo como o novo. Tem de aguentar uma carga de dados de 200 registos de cada vez sem bater nos limites. Volte a contar em vez de somar e subtrair, para que um evento perdido não deixe o número errado para sempre. Planeie uma forma de recalcular tudo, para a primeira carga e para o dia em que o número se desviar. E lembre-se de que agora cada vez que se guarda um filho o pai é atualizado, por isso um pai com milhares de filhos traz de volta o bloqueio que vamos ver daqui a pouco. Um resumo de totalização nativo faz tudo isto por si; um personalizado é um pequeno software que passa a ser seu.

Três níveis de profundidade: empilhar mestre-detalhe

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

Pode empilhar relações mestre-detalhe até três níveis de detalhe personalizados, e esse é o fundo (Considerations for Object Relationships (opens in a new tab), em inglês). Nas aulas desenho uma conta com uma encomenda (um), a encomenda com os seus artigos (dois) e os artigos com os seus detalhes (três), e depois tento acrescentar um quarto e o Salesforce não deixa. Na Steve Trucking poderia ficar assim: uma Entrega é o mestre; os 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 os Passos da tarefa (Task Steps) de cada tarefa são o terceiro. Um quarto nível, digamos uma Nota do passo (Step Note), tem de ser uma relação de pesquisa.

Click to enlarge

Algumas regras vêm com a pilha:

• Os 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 dê a volta sobre si próprio: 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 Passos da tarefa, a Tarefa de instalação totaliza os seus passos, o Item de entrega totaliza esses resumos, e a Entrega totaliza os itens: um nível de cada vez.
• A propriedade e a partilha vêm do topo. Cada nível herda o proprietário e o acesso do mestre.
• Eliminar o mestre elimina tudo o que está abaixo dele, e restaurá-lo traz tudo de volta.

Três níveis costumam ser mais do que suficientes. Se o seu design continua a pedir um quarto, pergunte se cada nível pertence realmente ao de cima a vida inteira. E lembre-se de que é o próprio que escolhe qual ligação quebra a corrente. O quarto nível não tem de ser a relação de pesquisa: talvez uma Tarefa de instalação não pertença de verdade ao seu Item de entrega, é marcada e atribuída por conta própria, por isso essa ligação passa a ser uma relação de pesquisa, e agora a Tarefa de instalação começa uma nova corrente, com o Passo da tarefa e a Nota do passo abaixo dela. Escolha a ligação em que o filho tem realmente vida própria, e faça dela a relação de pesquisa.

Click to enlarge

Agora a Tarefa de instalação tem proprietário próprio e partilha própria, uma entrega pode ser eliminada sem levar consigo as 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 encontrámos o objeto de junção lógico: a junção de duas ideias-chave que se torna uma coisa própria, com atributos próprios. Um cão sabe muitos truques, um truque é conhecido por muitos cães, e o Truque do cão fica entre eles, a guardar 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 relação de pesquisa e mestre-detalhe.

O Salesforce usa o termo de forma mais estreita. Quando o Salesforce diz objeto de junção, quer dizer um objeto personalizado com duas relações mestre-detalhe (Create a Many-to-Many Object Relationship (opens in a new tab), em inglês). Vou chamar-lhe objeto de junção do Salesforce (Salesforce Junction Object). Todo o objeto de junção do Salesforce é um objeto de junção lógico, mas nem todo o objeto de junção lógico se torna um objeto de junção do Salesforce: construa um com uma mestre-detalhe e uma relação de pesquisa, ou com duas relações de pesquisa, e continua a ser 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 «objetos de junção» a alguns objetos padrão construídos com relações de pesquisa. No exame, assuma a definição estreita.)

Conhecimento para o exame. Um objeto de junção do Salesforce é um objeto personalizado com duas relações mestre-detalhe, e é isso que o Salesforce quer dizer quando fala em «objeto de junção». O objeto de junção lógico é a ideia de modelação mais ampla: qualquer objeto que une dois outros num muitos-para-muitos e tem atributos próprios, seja qual for a forma como é construído.

A segunda dimensão é a largura. Um filho pode ter dois pais mestre-detalhe? Sim. Três? Não. Cada objeto personalizado pode ter até duas relações mestre-detalhe (Considerations for Object Relationships (opens in a new tab), em inglês). Dois pais mestre-detalhe é a forma de construir um objeto de junção do Salesforce para um muitos-para-muitos. A Equipa e o Camião encontram-se numa Atribuição de equipa, e, como vimos no capítulo 2, isso não é canalização: tem uma data, uma rota, talvez um estado. A junção é onde a relação se torna um conceito de negócio. As dicas da Salesforce para construir um: dê-lhe um nome que diga o que é, faça com que o nome do registo seja uma numeração automática, e mude o nome da lista relacionada de cada mestre para o nome do outro mestre, para que a página da Equipa mostre «Camiões» e a página do Camião mostre «Equipas» (Create a Many-to-Many Object Relationship (opens in a new tab), em inglês).

Eis a subtileza. Um dos dois pais é o principal, e é aquele cujo campo mestre-detalhe criou primeiro. Não há nenhuma indicação visual de qual é, por isso é uma pergunta clássica de exame, e uma surpresa clássica.

O que é 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 registos de junção herdam o proprietário do registo mestre principal. Nunca o vê, porque um detalhe não tem campo Proprietário; só importa se mais tarde remover as duas relações mestre-detalhe.
• Divisão, se a sua org usa divisões, da mesma forma.

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

• É o próximo da fila para passar a principal. Elimine o campo mestre-detalhe principal ou converta-o em relação de pesquisa, e o secundário passa a ser o principal.
• Define o âmbito dos relatórios. O Salesforce dá-lhe 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 que registos o relatório pode mostrar.
• Conta tanto quanto o outro para o acesso. É assim que eu o digo: a propriedade vem do principal, o acesso vem dos dois, e o mais restritivo ganha. Uma junção, como qualquer detalhe, não tem tabela de partilha própria. O Salesforce verifica o acesso do utilizador aos dois registos mestres, através da Sharing Setting de cada campo mestre-detalhe. Se ambas estiverem como Read/Write, o utilizador precisa de Read/Write na equipa e no camião para editar a Atribuição de equipa (Considerations for Object Relationships (opens in a new tab), em inglês).
• Elimina tanto quanto o outro. Elimine qualquer um dos mestres, a equipa ou o camião, e os registos de junção dele vão para a Reciclagem. Elimine os dois e desaparecem 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 chegar a campos dos dois. Mas uma junção não pode ser mestre de mais nada, por isso 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 próprio precisa de outro design. E se um pai tem mais de 200 registos de junção e a junção totaliza para o outro pai, o Salesforce não o deixa eliminar esse pai até ter removido registos suficientes.

Então: que pai deveria ser o principal? Crie primeiro aquele que é dono do significado. Numa Atribuição de equipa, quem faz o trabalho é a equipa, por isso eu criaria a Equipa primeiro. E depois registe isso por escrito, porque nada no ecrã o vai dizer à próxima pessoa.

Dito tudo isto, não acabo com muitos objetos de junção do Salesforce. Normalmente um objeto tem um pai mestre-detalhe, e é do mesmo tipo de dados: 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, normalmente um objeto de referência, essa relação é uma relação de pesquisa. Um Item de entrega pertence à sua Entrega: mestre-detalhe, os dois transacionais. Aponta para o Produto que transporta com uma relação de pesquisa, porque um produto é um dado de referência com vida própria, e ninguém quer que eliminar um produto leve consigo anos de histórico de entregas. O Item de entrega continua a ser um objeto de junção lógico entre uma entrega e os produtos que leva; só não é um objeto de junção do Salesforce.

Autorrelações: quando a linha volta

Um objeto pode relacionar-se consigo próprio: uma conta principal, um gestor, um centro de distribuição que responde a um hub regional. O Salesforce já traz duas que vai encontrar em quase todas as orgs: Conta para Conta, o campo Conta principal que monta a hierarquia de contas, e Caso para Caso, o Caso principal do módulo 2, que agrupa casos relacionados. Uma autorrelação tem de ser uma relação de pesquisa, e um registo não pode apontar para si próprio, embora dois registos possam apontar um para o outro (Considerations for Object Relationships (opens in a new tab), em inglês). No objeto Utilizador é um tipo especial próprio, a relação hierárquica, usada para coisas como o gestor de um utilizador. A mecânica é fácil; o nome é o que importa. Uma relação de pesquisa de Centro de distribuição para Centro de distribuição chamada Distribution_Center__c não ajuda ninguém. Principal? Reserva? Excedente? Dê à relação o nome do papel, não do objeto para o qual aponta.

Click to enlarge

Hierárquica: a relação própria do objeto Utilizador

Esta é pequena, e é exatamente o tipo de facto pouco conhecido e único que eu esperaria ver num exame. A hierárquica é uma relação de pesquisa especial que só existe no objeto Utilizador (User). Liga um utilizador a outro utilizador, e o Salesforce não deixa a corrente dar a volta: um utilizador não pode apontar para si próprio, direta ou indiretamente (Object Relationships Overview (opens in a new tab), em inglês). Se o gestor da Maria é o Dev, o gestor do Dev não pode ser a Maria, nem ninguém que responda, subindo a cadeia, à Maria.

É essa a diferença em relação às autorrelações acima. Na Conta ou num objeto personalizado, dois registos podem apontar um para o outro. No Utilizador, a hierarquia tem de continuar a ser uma hierarquia. E é a única forma de relacionar Utilizador com Utilizador: uma relação de pesquisa comum de Utilizador para ele próprio não é oferecida.

Já tem uma. O campo padrão Manager (Gestor) do Utilizador é uma relação hierárquica, e as aprovações podem usá-lo: enviar este pedido ao gestor de quem o submeteu. Também pode criar as suas, digamos um Contacto de escalamento ou um Aprovador substituto, e uma aprovação pode seguir por ela da mesma forma (ApprovalProcess, Metadata API (opens in a new tab), em inglês). Não a confunda com a hierarquia de funções, que determina o acesso aos registos. Um campo hierárquico é só uma relação entre utilizadores; não partilha nenhum registo.

Conhecimento para o exame. A relação hierárquica só existe no objeto Utilizador, como o campo padrão Manager, e um utilizador não pode apontar para si próprio, direta ou indiretamente. Não é a hierarquia de funções.

As relações também têm limites

Cada objeto pode ter no máximo duas relações mestre-detalhe. Campos de relação de pesquisa e mestre-detalhe, juntos, contam como campos de relação: 40 por objeto por defeito, no máximo 50 mediante pedido. Campos de resumo de totalização: 25 por objeto por defeito, 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 destes limites pode afetar o desempenho.

Não precisa de projetar com estes números em mente; precisa de perceber quando está perto deles. Um objeto com relação atrás de relação pendurada nele está a dizer-lhe algo. Talvez 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 a mais. A própria orientação da Salesforce é não passar de cerca de 10 mil registos filhos para um único pai mestre-detalhe (Considerations for Object Relationships (opens in a new tab), em inglês), e o seu guia sobre acesso a registos à escala diz o mesmo para relações pai-filho em geral (Parent-Child Data Skew (opens in a new tab), em inglês). O registo 10.001 não estraga a org. Mas a partir daí, gravar um filho pode bloquear o pai, e as mudanças de partilha no pai propagam-se por todos os filhos.

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

Não projete a linha pela funcionalidade

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 partilha herdada». Isso são pistas de implementação. Comece pelo negócio: o filho tem vida própria, quem é dono dele, pode existir sozinho, pode mover-se, o que acontece quando o pai desaparece, a relação carrega dados, e quão grande pode ficar cada lado? Depois escolha a relação que implementa as respostas.

Click to enlarge

Além do exame: o que a IA muda. A IA consegue propor relações em segundos. Não lhe consegue dizer se o negócio alguma vez vai eliminar o pai. Diagramar mais depressa não torna uma relação errada mais barata de reverter depois de milhões de registos e dezenas de automações dependerem dela.

O que um arquiteto decide aqui

• Se o filho tem ciclo de vida próprio ou pertence realmente 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 à eliminação do pai.
• O que cada relação de pesquisa faz quando o pai é eliminado: limpar, bloquear ou eliminar em cascata.
• Se um muitos-para-muitos é canalização ou um conceito de negócio, se o objeto de junção lógico se torna um objeto de junção do Salesforce, que pai é o principal, e o que os dois pais significam para o acesso.
• Se o modelo encaixa na forma da plataforma: três níveis de detalhe personalizados de profundidade, dois pais mestre-detalhe de largura, os limites de relações 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.

Uma relação é 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.