Les relations ont des conséquences

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · 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)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 7 sur 10 du chapitre L’architecture de données Salesforce, chapitre 3 du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Les champs aussi, c’est de l’architecture · Suivant : Propriété et cycle de vie

La question à laquelle répond ce module : que suis-je vraiment en train de choisir quand je relie deux objets Salesforce ?

Dessiner une relation est facile. Au chapitre 2, nous avons tracé des traits et les avons nommés : un partenaire distributeur envoie plusieurs manifestes, une livraison contient plusieurs articles, équipes et camions se rencontrent dans une affectation d’équipe. Nous avons parlé de cardinalité, de caractère facultatif et d’historique. Maintenant, nous mettons ces traits en œuvre sur Salesforce, et un trait sur un schéma commence à peser beaucoup plus lourd.

Quand je choisis un type de relation sur Salesforce, je ne dis pas seulement ces deux enregistrements sont liés. Je décide peut-être aussi à qui appartient l’enfant, s’il peut exister sans le parent, qui peut le voir, ce qui se passe quand le parent est supprimé, s’il peut passer à un autre parent, si je peux le cumuler sur le parent, et ce qui se passe quand il y a des centaines de milliers d’enfants. Une relation n’est pas seulement un trait. Elle porte un comportement.

Commencez par la relation métier

Avant référence ou principal-détails, revenez au métier. Prenez une livraison et ses articles de livraison, le réfrigérateur, l’installation, l’enlèvement. Un article peut-il exister sans sa livraison ? Non. Si la livraison est supprimée, ses articles doivent-ils partir aussi ? Oui. Les articles ont-ils besoin de leur propre propriétaire ou de leur propre sécurité ? Pas vraiment. Quelqu’un devrait-il déplacer un article d’une livraison à une autre ? Pas par accident, espérons-le.

Prenez maintenant une livraison et la tournée dans laquelle elle se trouve. La livraison existe avant d’être planifiée, elle peut passer dans une autre tournée quand le plan change, et supprimer une tournée ne devrait jamais supprimer les livraisons qu’elle contient. Deux traits un-à-plusieurs qui se ressemblent sur un schéma, avec des comportements complètement différents. Remarquez que nous n’avons toujours pas dit « référence » ni « principal-détails ». Décrivez d’abord le comportement. La configuration le met en œuvre.

Les types de relations

Ouvrez l’écran Nouveau champ, et Salesforce vous propose une poignée de types de relations (Object Relationships Overview (opens in a new tab), en anglais) :

• Référence : relie deux objets. Le pain quotidien des relations Salesforce.
• Principal-détails : un lien parent-enfant où le parent contrôle l’enfant.
• Plusieurs-à-plusieurs : pas un type de champ à part entière, mais un modèle : un objet de jonction Salesforce (Salesforce Junction Object), un objet personnalisé avec deux relations principal-détails.
• Auto-relation : une référence d’un objet vers lui-même.
• Hiérarchique : une référence spéciale qui n’existe que sur l’objet Utilisateur, comme le responsable d’un utilisateur.
• Référence externe et référence indirecte : les relations vers et depuis les objets externes, les objets __x du module 4. Une référence externe pointe vers un objet externe parent ; une référence indirecte pointe d’un objet externe vers un objet standard ou personnalisé, en faisant la correspondance sur un ID externe unique.

L’essentiel de votre temps de conception va aux trois premiers. Prenons-les un par un.

Référence : ces enregistrements sont liés

Une relation de référence dit : cet enregistrement est associé à cet autre enregistrement. L’enfant garde sa propre identité, son propre propriétaire et sa propre vie. Une livraison pointe vers sa tournée. Si la tournée est annulée, les livraisons ne disparaissent pas ; elles retournent à la planification.

C’est drôle : le champ de référence se trouve sur l’enfant, mais le parent reçoit lui aussi quelque chose, une liste associée de ses enfants. Alors quand vous en créez une, nommez les deux bouts. L’Étiquette de la liste associée (Related List Label) est ce que les gens voient sur le parent, et le Nom de la relation enfant (Child Relationship Name) est ce que les développeurs et les intégrations utilisent pour aller du parent aux enfants. N’acceptez pas les valeurs par défaut.

Une référence peut être obligatoire ou facultative. Quand elle est facultative, vous décidez de ce qui se passe si l’enregistrement pointé est supprimé, et il y a trois choix (Considerations for Object Relationships (opens in a new tab), en anglais) :

• Effacer la valeur de ce champ, l’option par défaut. L’enfant reste, avec une référence vide.
• Ne pas autoriser la suppression de l’enregistrement de référence. Essayez de supprimer la tournée, et Salesforce refuse : elle fait partie d’une relation.
• Supprimer également cet enregistrement, une suppression en cascade, comme avec principal-détails. Elle n’est proposée que pour une référence personnalisée sur un objet personnalisé, elle est désactivée par défaut, et Salesforce doit l’activer pour votre organisation, parce qu’une suppression en cascade contourne la sécurité et le partage : des utilisateurs peuvent supprimer des enregistrements qu’ils ne pouvaient même pas voir.

C’est une décision de cycle de vie cachée dans un écran de configuration.

Les filtres de recherche (lookup filters) restreignent ce qu’un utilisateur peut choisir. Disons que la livraison a une référence Installateur vers Contact, et que les installateurs sont un type d’enregistrement de contact parmi beaucoup d’autres. Un filtre de recherche n’affiche que les installateurs, et il peut filtrer sur l’enregistrement en cours, sur l’enregistrement recherché et sur l’utilisateur : son profil, son rôle ou ses autorisations (Lookup Filters (opens in a new tab), en anglais). C’est un moyen peu coûteux de garder une référence honnête.

Principal-détails : cet enfant appartient à ce parent

Principal-détails fait une affirmation bien plus forte. En cours, je parle d’un lien très étroit. Vous ne pouvez pas avoir de détail sans son principal ; le champ principal est obligatoire. Le détail perd son propre champ Propriétaire et hérite du propriétaire de son parent. Il n’y a pas de table de partage séparée pour le détail, donc vous ne pouvez pas partager un enfant à part ; il hérite du partage de son parent. C’est pourquoi un objet détail ne peut pas avoir de règles de partage, de partage manuel ni de files d’attente : tous ont besoin d’un champ Propriétaire (Object Relationships Overview (opens in a new tab), en anglais). Dans la Configuration, son paramètre de partage indique Contrôlé par le parent. Et sur le champ principal-détails lui-même, vous choisissez un Paramètre de partage : si un utilisateur a besoin d’un accès en Lecture seule ou en Lecture/Écriture au principal pour créer, modifier ou supprimer ses détails. Supprimer le principal supprime ses détails. Et le principal reçoit des champs de récapitulatif de cumul.

Si l’article de livraison est un détail de la livraison, je dis donc : cet article appartient à cette livraison pour toute sa vie. C’est la question à laquelle je veux une réponse avant que quiconque choisisse Relation principal-détails dans la Configuration.

La question de la suppression

Voici ma façon préférée de vérifier si nous y avons bien réfléchi : que doit-il arriver aux enfants si quelqu’un supprime le parent ? Tout le monde devient mal à l’aise. Tant mieux. Nous faisons maintenant de l’architecture.

Un partenaire distributeur a des centaines de milliers de livraisons historiques. Quelqu’un supprime le partenaire. Les livraisons doivent-elles disparaître ? Presque certainement pas : les réclamations, la facturation et l’historique en dépendent tous. Peut-être que supprimer un partenaire ne devrait pas être permis du tout, et qu’il devrait plutôt être désactivé. Avec principal-détails, supprimer le principal se propage en cascade aux détails et à leurs détails ; restaurer le principal les ramène (Considerations for Object Relationships (opens in a new tab), en anglais). Alors quand quelqu’un dit « principal-détails nous donne des cumuls », ma réponse est : parfait. À quoi d’autre venez-vous de consentir ?

La propriété suit le mouvement

Avec une référence, l’enfant peut avoir son propre propriétaire. Avec principal-détails, il ne le peut pas ; l’accès suit le principal. C’est exactement juste si le détail fait réellement partie du parent. Mais si l’enfant a besoin de son propre propriétaire, de son propre partage ou de son propre cycle de vie, le modèle vous dit que principal-détails est le mauvais choix. Le module suivant approfondit la propriété, et le cours Sharing and Visibility va encore plus loin. Pour l’instant : la conception des relations et la conception de la sécurité ne sont pas des conversations séparées. Le modèle de données façonne le modèle de sécurité avant que quiconque écrive une règle de partage.

Parent obligatoire ou facultatif ?

L’enfant peut-il exister avant que nous connaissions son parent ? C’est plus important qu’il n’y paraît. Si les livraisons arrivent dans le manifeste la veille au soir et que les tournées sont construites ensuite, une tournée obligatoire sur la livraison voudrait dire qu’il faut planifier avant même de pouvoir créer l’enregistrement. La relation physique doit soutenir le cycle de vie réel. Je ne conçois donc pas les relations à partir d’un seul schéma statique. Je veux savoir : comment naissent-ils, peuvent-ils exister seuls, peuvent-ils bouger, et comment meurent-ils ?

L’enfant peut-il changer de parent ?

Par défaut, un enfant principal-détails ne peut pas être déplacé vers un autre parent. Vous pouvez l’autoriser en cochant Autoriser le changement de parent sur la relation (Considerations for Object Relationships (opens in a new tab), en anglais). Mon instinct est prudent : si le métier dit que l’enfant appartient à un seul parent pour la vie, je ne facilite pas son déplacement. Un article qui passe d’une livraison à une autre devrait être un événement métier délibéré, pas une modification de champ. Encore une fois, le paramètre n’est pas l’architecture. La règle de cycle de vie l’est, et le paramètre la met en œuvre.

Deux autres choses qui surprennent les équipes plus tard. Vous ne pouvez pas créer une relation principal-détails sur un objet qui contient déjà des données ; vous créez une référence, vous la remplissez sur chaque enregistrement, puis vous la convertissez. Et vous ne pouvez revenir à une référence que s’il n’y a pas de champ de récapitulatif de cumul sur le principal. Surveillez aussi ce que la conversion fait à la sécurité : transformer une référence en principal-détails règle le partage de l’enfant sur Contrôlé par le parent, et retransformer un principal-détails en référence règle le paramètre par défaut de l’organisation de l’enfant sur Public en lecture/écriture (Considerations for Object Relationships (opens in a new tab), en anglais). Des enregistrements privés hier sont ouverts aujourd’hui, jusqu’à ce que quelqu’un s’en aperçoive. Choisissez tôt.

Les cumuls sont utiles, mais ils ne sont pas gratuits

J’aime les cumuls. Compter les articles d’une livraison, additionner les montants des lignes d’une facture, trouver la date la plus récente : natif, sans code. Le champ principal-détails se trouve sur l’enfant, mais le cumul se trouve sur le parent. Ils viennent cependant avec des petits caractères (Roll-Up Summary Field (opens in a new tab), en anglais) :

• Le calcul des valeurs de cumul après certains changements (un nouveau champ de cumul, une formule dont il dépend modifiée, un recalcul forcé) peut prendre jusqu’à 30 minutes, selon le nombre d’enregistrements concernés. J’ai vu des gens se demander pourquoi le chiffre sur le parent n’avait pas encore changé.
• Ils ne peuvent pas tout récapituler. Une numérotation automatique ne peut pas être le champ que vous agrégez. Et un cumul ne peut récapituler un champ de formule que si cette formule ne va pas chercher un autre objet et n’utilise pas une fonction qui change d’elle-même, comme NOW() ou TODAY(). Une formule « jours de retard » construite sur TODAY() change chaque nuit sans que personne n’enregistre quoi que ce soit, donc le cumul n’a rien à partir de quoi recalculer. Ce genre de chiffre demande un flux planifié, ou un rapport.
• Le filtre a lui aussi des limites : pas de zone de texte longue, de liste de sélection multiple, de Description, de champs système comme Dernière activité, de formules inter-objets ni de champs de référence.
• Les cumuls ne figurent pas sur les pages de modification, donc une règle de validation peut en utiliser un, mais ne peut pas y afficher son erreur.

Et n’inversez pas la décision. Ne dites pas : « Il nous faut un cumul, donc ce doit être principal-détails. » Dites : « Cet enfant appartient vraiment à ce parent, la propriété et le cycle de vie correspondent, et l’un des avantages est d’avoir des cumuls natifs. » Si le sens ne correspond pas, résolvez le calcul autrement. Ne déformez pas le modèle de données pour obtenir une fonctionnalité.

Alors, quelle est l’autre façon ? Vous construisez le cumul vous-même : un champ sur le parent qui contient la valeur calculée, et une automatisation qui la tient à jour. Disons que le partenaire distributeur est une référence depuis la livraison, comme il se doit, et que le métier veut un nombre de livraisons ouvertes sur le partenaire. Ajoutez un champ numérique, Livraisons ouvertes (Open Deliveries), au partenaire. Puis un flux déclenché par un enregistrement, ou un déclencheur Apex quand le volume ou la logique demande du code, le recalcule chaque fois qu’une livraison change. Cela fonctionne sur une référence, cela peut filtrer sur n’importe quoi, et cela peut utiliser des dates et des formules qu’un cumul natif ne peut pas utiliser.

Mais maintenant, c’est à vous de bien le faire, et c’est là que ces solutions déraillent. L’automatisation doit se déclencher à chaque changement qui compte : un nouvel enfant, un enfant modifié, un enfant supprimé, un enfant restauré, et un enfant déplacé vers un autre parent, ce qui veut dire recalculer à la fois l’ancien parent et le nouveau. Elle doit supporter un chargement de données de 200 enregistrements à la fois sans atteindre les limites. Recomptez plutôt que d’ajouter et de soustraire, pour qu’un seul événement manqué ne laisse pas le chiffre faux pour toujours. Prévoyez un moyen de tout recalculer, pour le premier chargement et pour le jour où le chiffre dérive. Et rappelez-vous que chaque enregistrement d’enfant met maintenant à jour le parent, donc un parent avec des milliers d’enfants ramène le verrouillage que nous verrons dans un instant. Un cumul natif fait tout cela pour vous ; un cumul personnalisé est un petit logiciel dont vous êtes propriétaire.

Trois niveaux de profondeur : empiler les principal-détails

La plateforme a une forme, et principal-détails en a deux dimensions. La première est la profondeur.

Vous pouvez empiler des principal-détails sur trois niveaux de détail personnalisés, et c’est le fond (Considerations for Object Relationships (opens in a new tab), en anglais). En cours, je le dessine comme un compte avec une commande (un), la commande avec ses articles (deux), et les articles avec leurs détails (trois), puis j’essaie d’en ajouter un quatrième et Salesforce ne me laisse pas faire. Chez Steve Trucking, cela pourrait ressembler à ceci : une livraison (Delivery) est le principal ; ses articles de livraison (Delivery Items) sont le premier niveau ; les tâches d’installation (Install Tasks) d’un article sont le deuxième ; et les étapes de tâche (Task Steps) de chaque tâche sont le troisième. Un quatrième niveau, disons une note d’étape (Step Note), doit être une référence.

Click to enlarge

Quelques règles accompagnent l’empilement :

• Les objets standard ne peuvent pas être du côté détail d’un objet personnalisé. Un objet personnalisé peut être un détail de Compte ; Compte ne peut pas être un détail du vôtre.
• Un objet ne peut apparaître qu’une fois dans un empilement à plusieurs niveaux. Salesforce ne veut pas que vous reveniez en boucle sur vous-même : un sous-détail ne peut pas être aussi le principal de son propre principal.
• Le principal ne peut pas cumuler directement le niveau le plus bas. Si la livraison veut le nombre d’étapes de tâche, la tâche d’installation cumule ses étapes, l’article de livraison cumule ces cumuls, et la livraison cumule les articles : un niveau à la fois.
• La propriété et le partage viennent du haut. Chaque niveau hérite du propriétaire et de l’accès du principal.
• Supprimer le principal supprime tout ce qui se trouve en dessous, et le restaurer ramène tout.

Trois niveaux suffisent généralement largement. Si votre conception réclame sans cesse un quatrième, demandez-vous si chaque niveau appartient vraiment à celui du dessus pour toute sa vie. Et rappelez-vous que c’est vous qui choisissez quel lien casse la chaîne. Le quatrième niveau n’a pas à être la référence : peut-être qu’une tâche d’installation n’appartient pas vraiment à son article de livraison, elle est planifiée et affectée de son côté, donc ce lien devient une référence, et la tâche d’installation commence maintenant une nouvelle chaîne avec l’étape de tâche et la note d’étape en dessous. Choisissez le lien où l’enfant a vraiment sa propre vie, et faites de celui-là la référence.

Click to enlarge

Maintenant, la tâche d’installation a son propre propriétaire et son propre partage, une livraison peut être supprimée sans emporter ses tâches d’installation, et la tâche d’installation peut avoir deux niveaux de plus en dessous. Voilà le compromis : la chaîne est plus courte, et la vie de la tâche d’installation lui appartient.

Deux parents de large : l’objet de jonction Salesforce

D’abord, un mot sur les mots, parce que « objet de jonction » veut dire deux choses, et j’enseigne les deux.

Au chapitre 2, nous avons trouvé l’objet de jonction logique : la jonction de deux idées clés qui devient une chose à part entière, avec ses propres attributs. Un chien connaît plusieurs tours, un tour est connu de plusieurs chiens, et Tour du chien (Dog Trick) se place entre eux, avec le niveau de maîtrise et la date. C’est un objet de jonction logique, dans le modèle logique, bien avant que quiconque décide entre référence et principal-détails.

Salesforce utilise le terme de façon plus étroite. Quand Salesforce dit objet de jonction, il veut dire un objet personnalisé avec deux relations principal-détails (Create a Many-to-Many Object Relationship (opens in a new tab), en anglais). Je l’appellerai un objet de jonction Salesforce (Salesforce Junction Object). Tout objet de jonction Salesforce est un objet de jonction logique, mais tout objet de jonction logique ne devient pas un objet de jonction Salesforce : construisez-en un avec une relation principal-détails et une référence, ou avec deux références, et c’est toujours un objet de jonction logique, simplement pas du type Salesforce. (Salesforce n’est pas parfaitement cohérent lui-même : sa propre référence des objets appelle « objets de jonction » certains objets standard construits sur des références. À l’examen, retenez la définition étroite.)

À savoir pour l’examen. Un objet de jonction Salesforce est un objet personnalisé avec deux relations principal-détails, et c’est ce que Salesforce veut dire quand il dit « objet de jonction ». L’objet de jonction logique est l’idée de modélisation plus large : tout objet qui relie deux autres objets dans un plusieurs-à-plusieurs et porte ses propres attributs, quelle que soit la façon dont il est construit.

La deuxième dimension est la largeur. Un enfant peut-il avoir deux parents principal-détails ? Oui. Trois ? Non. Chaque objet personnalisé peut avoir au plus deux relations principal-détails (Considerations for Object Relationships (opens in a new tab), en anglais). Deux parents principal-détails, c’est ainsi que vous construisez un objet de jonction Salesforce pour un plusieurs-à-plusieurs. L’équipe et le camion se rencontrent dans une affectation d’équipe (Crew Assignment), et comme nous l’avons vu au chapitre 2, ce n’est pas de la tuyauterie : elle a une date, une tournée, peut-être un statut. La jonction est l’endroit où la relation devient un concept métier. Les conseils de Salesforce pour en construire une : donnez-lui un nom qui dit ce qu’elle est, faites de son nom d’enregistrement une numérotation automatique, et renommez la liste associée de chaque principal d’après l’autre principal, pour que la page de l’équipe affiche « Camions » et la page du camion « Équipes » (Create a Many-to-Many Object Relationship (opens in a new tab), en anglais).

Voici la subtilité. L’un des deux parents est le primaire, et c’est celui dont vous avez créé en premier le champ principal-détails. Rien n’indique visuellement lequel c’est, donc c’est une question d’examen classique, et une surprise classique.

Que décide le primaire ? Trois choses (Create a Many-to-Many Object Relationship (opens in a new tab), en anglais) :

• L’apparence. Les pages de la jonction utilisent la couleur et l’icône du principal primaire.
• Le propriétaire. Les enregistrements de jonction héritent du propriétaire de l’enregistrement principal primaire. Vous ne le voyez jamais, parce qu’un détail n’a pas de champ Propriétaire ; cela ne compte que si vous supprimez plus tard les deux relations principal-détails.
• La division, si votre organisation utilise les divisions, de la même façon.

Et l’autre est le secondaire. Qu’est-ce que cela veut dire ?

• Il attend son tour pour devenir primaire. Supprimez le champ principal-détails primaire ou convertissez-le en référence, et le secondaire devient le primaire.
• Il fixe le périmètre des rapports. Salesforce vous donne deux types de rapport : « Principal primaire avec objet de jonction et principal secondaire » et « Principal secondaire avec objet de jonction et principal primaire ». Le principal cité en premier décide des enregistrements que le rapport peut afficher.
• Il compte tout autant pour l’accès. Voici comment je le formule : la propriété vient du primaire, l’accès vient des deux, et le plus restrictif l’emporte. Une jonction, comme tout détail, n’a pas de table de partage propre. Salesforce vérifie l’accès de l’utilisateur aux deux enregistrements principaux, via le Paramètre de partage de chaque champ principal-détails. Si les deux sont réglés sur Lecture/Écriture, l’utilisateur a besoin de Lecture/Écriture sur l’équipe et sur le camion pour modifier l’affectation d’équipe (Considerations for Object Relationships (opens in a new tab), en anglais).
• Il supprime tout autant. Supprimez l’un ou l’autre principal, l’équipe ou le camion, et ses enregistrements de jonction partent dans la Corbeille. Supprimez les deux et ils disparaissent pour de bon.

Click to enlarge

Quelques règles de plus : les deux principaux peuvent avoir des cumuls à partir de la jonction, et les formules et règles de validation de la jonction peuvent atteindre les champs des deux. Mais une jonction ne peut pas être le principal de quoi que ce soit d’autre, donc elle ne peut pas se placer au milieu d’un empilement, et les deux principaux ne peuvent pas être le même objet ; un plusieurs-à-plusieurs d’un objet vers lui-même demande une autre conception. Et si un parent a plus de 200 enregistrements de jonction et que la jonction se cumule sur l’autre parent, Salesforce ne vous laissera pas supprimer ce parent tant que vous n’en aurez pas retiré suffisamment.

Alors : quel parent doit être le primaire ? Créez en premier celui qui porte le sens. Pour une affectation d’équipe, c’est l’équipe qui fait le travail, donc je créerais Équipe en premier. Et ensuite, écrivez-le, parce que rien à l’écran ne le dira à la personne suivante.

Cela dit, je ne me retrouve pas avec beaucoup d’objets de jonction Salesforce. En général, un objet a un seul parent principal-détails, et c’est le même type de données : des données client sous des données client, du transactionnel sous du transactionnel (rappelez-vous les types de données du chapitre 2 : client, transactionnel, de référence). Quand son autre parent est d’un type différent, généralement un objet de référence, cette relation est une référence. Un article de livraison appartient à sa livraison : principal-détails, les deux transactionnels. Il pointe vers le produit qu’il transporte avec une référence, parce qu’un produit est une donnée de référence avec sa propre vie, et personne ne veut qu’en supprimant un produit on emporte des années d’historique de livraisons. L’article de livraison reste un objet de jonction logique entre une livraison et les produits qu’elle contient ; ce n’est simplement pas un objet de jonction Salesforce.

Les auto-relations : quand le trait revient sur lui-même

Un objet peut être lié à lui-même : un compte parent, un responsable, un centre de distribution rattaché à une plateforme régionale. Salesforce en intègre deux que vous rencontrerez dans presque toutes les organisations : Compte vers Compte, le champ Compte parent qui construit la hiérarchie des comptes, et Requête vers Requête, la requête parente du module 2 qui regroupe des requêtes liées. Une auto-relation doit être une référence, et un enregistrement ne peut pas pointer vers lui-même, même si deux enregistrements peuvent pointer l’un vers l’autre (Considerations for Object Relationships (opens in a new tab), en anglais). Sur l’objet Utilisateur, c’est un type spécial à part entière, la relation hiérarchique, utilisée par exemple pour le responsable d’un utilisateur. La mécanique est facile ; le nommage compte. Une référence de Centre de distribution vers Centre de distribution appelée Distribution_Center__c n’aide personne. Parent ? Secours ? Débordement ? Nommez la relation selon le rôle, pas selon l’objet vers lequel elle pointe.

Click to enlarge

Hiérarchique : la relation propre à l’objet Utilisateur

Celle-ci est petite, et c’est exactement le genre de fait peu connu et unique en son genre sur lequel je m’attendrais à ce qu’un examen s’appuie. La relation hiérarchique est une référence spéciale qui n’existe que sur l’objet Utilisateur. Elle relie un utilisateur à un autre utilisateur, et Salesforce ne laisse pas la chaîne revenir en boucle : un utilisateur ne peut pas pointer vers lui-même, directement ou indirectement (Object Relationships Overview (opens in a new tab), en anglais). Si le responsable de Maria est Dev, le responsable de Dev ne peut pas être Maria, ni personne qui dépend de Maria.

C’est la différence avec les auto-relations ci-dessus. Sur Compte ou sur un objet personnalisé, deux enregistrements peuvent pointer l’un vers l’autre. Sur Utilisateur, la hiérarchie doit rester une hiérarchie. Et c’est la seule façon de relier Utilisateur à Utilisateur : une référence ordinaire d’Utilisateur vers lui-même n’est pas proposée.

Vous en avez déjà une. Le champ standard Responsable (Manager) de l’utilisateur est une relation hiérarchique, et les approbations peuvent l’utiliser : envoyer cette demande au responsable de la personne qui la soumet. Vous pouvez aussi créer les vôtres, disons un Contact d’escalade ou un Approbateur suppléant, et une approbation peut suivre ce chemin de la même façon (ApprovalProcess, Metadata API (opens in a new tab), en anglais). Ne la confondez pas avec la hiérarchie des rôles, qui pilote l’accès aux enregistrements. Un champ hiérarchique n’est qu’une relation entre utilisateurs ; il ne partage pas un seul enregistrement.

À savoir pour l’examen. La relation hiérarchique n’existe que sur l’objet Utilisateur, comme le champ standard Responsable, et un utilisateur ne peut pas pointer vers lui-même, directement ou indirectement. Ce n’est pas la hiérarchie des rôles.

Les relations ont aussi des limites

Chaque objet peut avoir deux relations principal-détails au maximum. Les champs de référence et principal-détails comptent ensemble comme champs de relation : 40 par objet par défaut, 50 au maximum sur demande. Les champs de récapitulatif de cumul : 25 par objet par défaut, 40 au maximum (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), en anglais). Salesforce ajoute que relever l’une ou l’autre limite peut affecter les performances.

Vous n’avez pas besoin de concevoir en fonction de ces chiffres ; vous devez remarquer quand vous vous en approchez. Un objet auquel se rattachent relation après relation vous dit quelque chose. Peut-être est-il vraiment aussi central. Ou peut-être le modèle est-il faux. (Et la règle de marge du chapitre 18 s’applique : restez bien en dessous d’une limite, mesurée à la troisième année.)

La question des 10 000 enfants

Ensuite, il y a le parent qui a trop d’enfants. La recommandation de Salesforce elle-même est de ne pas dépasser environ 10 000 enregistrements enfants pour un même parent principal-détails (Considerations for Object Relationships (opens in a new tab), en anglais), et son guide sur l’accès aux enregistrements à grande échelle dit la même chose pour les relations parent-enfant en général (Parent-Child Data Skew (opens in a new tab), en anglais). L’enregistrement 10 001 ne casse pas l’organisation. Mais au-delà, enregistrer un enfant peut verrouiller le parent, et les changements de partage sur le parent se répercutent sur chaque enfant.

Alors quand je vois un parent, un nombre énorme d’enfants, je demande : pourquoi sont-ils tous sous le même parent, à qui appartiennent-ils, comment sont-ils interrogés, et quelle automatisation touche le parent ? Toutes les livraisons sous un seul compte « Steve Trucking » dépasseraient 10 000 en quelques jours. Un innocent un-à-plusieurs devient un problème de déséquilibre (skew). Le module suivant en donne un aperçu, et la partie 2 approfondit.

Ne concevez pas le trait d’après une fonctionnalité

C’est l’habitude que je veux voir sortir de ce module. Ne partez pas de « il me faut un cumul », « je le veux obligatoire », « je veux un partage hérité ». Ce sont des indices de mise en œuvre. Partez du métier : l’enfant a-t-il sa propre vie, à qui appartient-il, peut-il exister seul, peut-il bouger, que se passe-t-il quand le parent disparaît, la relation porte-t-elle des données, et quelle taille peut atteindre chaque côté ? Puis choisissez la relation qui met en œuvre les réponses.

Click to enlarge

Au-delà de l’examen : ce que l’IA change. L’IA peut proposer des relations en quelques secondes. Elle ne peut pas vous dire si le métier supprimera un jour le parent. Dessiner plus vite ne rend pas une mauvaise relation moins coûteuse à défaire une fois que des millions d’enregistrements et des dizaines d’automatisations en dépendent.

Ce que l’architecte décide ici

• Si l’enfant a son propre cycle de vie ou appartient vraiment au parent, et si la propriété et l’accès doivent être les siens ou hérités.
• Si l’enfant peut exister sans parent, passer d’un parent à l’autre, ou survivre à la suppression du parent.
• Ce que fait chaque référence quand son parent est supprimé : effacer, bloquer ou supprimer en cascade.
• Si un plusieurs-à-plusieurs est de la tuyauterie ou un concept métier, si l’objet de jonction logique devient un objet de jonction Salesforce, quel parent est le primaire, et ce que les deux parents signifient pour l’accès.
• Si le modèle respecte la forme de la plateforme : trois niveaux de détail personnalisés de profondeur, deux parents principal-détails de large, les limites de relations et de cumuls.
• Si le nombre et la répartition attendus des enfants créent un risque de déséquilibre qui devrait changer la conception.

Une relation est un ensemble de promesses sur la façon dont deux données se comportent ensemble. Faites-les délibérément.

Pour aller plus loin

• Aide Salesforce, Considerations for Object Relationships (opens in a new tab) (en anglais), consulté le 2026-10-13.
• Aide Salesforce, Object Relationships Overview (opens in a new tab) et Create a Many-to-Many Object Relationship (opens in a new tab) (en anglais), consulté le 2026-10-13.
• Aide Salesforce, Roll-Up Summary Field (opens in a new tab) (en anglais), consulté le 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (en anglais), consulté le 2026-10-13.
• Aide Salesforce, Lookup Filters (opens in a new tab) (en anglais), consulté le 2026-10-13.
• Aide Salesforce, Increase the Maximum Relationships Allowed per Object (opens in a new tab) et Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (en anglais), consulté le 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (en anglais), consulté le 2026-10-02.