Concevoir le modèle physique Salesforce

🌐 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 10 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 : Garder les données cohérentes · Suivant : le guide d’étude du chapitre, puis le chapitre suivant, Comprendre les données de l’entreprise

La question à laquelle répond ce module : comment transformer notre modèle logique en architecture Salesforce ?

Ce chapitre a été un long plaidoyer pour l’idée que la plateforme a une forme : objets standard et personnalisés, endroits où les données peuvent vivre, types de champ, relations, propriété, licences, règles de cohérence, stockage et volume. Chacun peut changer la façon dont le modèle logique du chapitre 2 est construit. Assemblons maintenant tout cela sur une tranche de Steve Trucking.

Une tranche, pas toute l’entreprise. Une erreur que je vois chez les architectes est d’essayer de résoudre toute l’entreprise dans un seul schéma. Je veux quelque chose sur quoi raisonner : un partenaire distributeur envoie un manifeste, Steve Trucking livre ce qu’il contient, et nous gardons ce dont nous avons besoin sur chaque livraison. Puis nous prenons les décisions physiques une par une. La conception complète est le point de contrôle de la partie 1.

Partez de ce que nous savons déjà

Le chapitre 2 a fait le travail conceptuel : partenaire distributeur, destinataire, manifeste, livraison, article de livraison, type d’arrêt, équipe, camion, centre de distribution, photos. Nous avons nommé les relations et demandé ce qu’elles signifient. Je ne vais pas le répéter. La question est maintenant comment ces concepts vivent sur Salesforce. Un fait du dossier compte tout de suite : Steve Trucking utilise déjà Field Service pour les rendez-vous, les équipes et l’application mobile.

Partenaire distributeur : n’inventez pas un compte

Un partenaire distributeur est une entreprise pour laquelle Steve Trucking travaille. Salesforce a déjà un objet conçu pour les entreprises : le compte. Adéquation nette. Donc pas de Retail_Partner__c juste parce que le métier dit « partenaire ». C’est un compte, avec un type d’enregistrement Retail Partner pour le distinguer des autres organisations, et avec lui viennent les contrats, les requêtes, des contacts pour les responsables de centre, et l’accès au portail pour ces contacts. Décision facile. Elles ne le sont pas toutes.

Le numéro de commande du partenaire n’est pas notre identité

Chaque partenaire distributeur envoie ses propres références. La commande d’un partenaire ressemble à 8843119, celle d’un autre à A-984732. Ces numéros comptent, mais à qui sont-ils ? Au partenaire. Salesforce a son propre ID d’enregistrement, et le partenaire a la référence qu’il utilise quand il nous parle. Les deux peuvent coexister ; c’est le « une chose, plusieurs identifiants » du chapitre 2.

La référence du partenaire devient donc un ID externe que l’intégration utilise pour faire correspondre les mises à jour. Et comme deux partenaires pourraient utiliser le même numéro, l’identité est le partenaire plus la référence, pas la référence seule. Ne faites pas du numéro d’un partenaire l’identité universelle de la livraison parce qu’il est arrivé en premier, et ne forcez pas une intégration à chercher dans un champ texte chaque fois qu’elle doit trouver un enregistrement.

Livraison : regardez le vaisseau mère

C’est ici qu’il est tentant de créer Delivery__c. Le métier a dit « livraison », donc il nous faut un objet Livraison. C’est exactement ce que je ne veux pas que vous fassiez en premier. Regardez le vaisseau mère, comme nous l’avons fait au module 2. Qu’a déjà Salesforce pour un travail effectué à un endroit, avec un cycle de vie, des articles, une planification et une équipe sur le terrain ? L’ordre d’exécution (Work Order) de Field Service : Salesforce le décrit comme un travail de service sur le terrain à effectuer pour un client (WorkOrder (opens in a new tab), en anglais). La visite planifiée et son créneau, c’est le rendez-vous de service (Service Appointment), et c’est ce que la répartition planifie et ce que l’application de l’équipe affiche.

Donc Livraison → ordre d’exécution. Pas parce que les mots correspondent ; ils ne correspondent pas. Parce que le comportement correspond à la capacité de la plateforme que nous payons déjà et que nous comptons utiliser. Un objet standard n’a pas besoin de partager le vocabulaire du métier. Il doit représenter correctement le concept.

Click to enlarge

Étape 1 sur 4 : le vaisseau mère. Chaque carte est le concept métier, avec son objet Salesforce en dessous.

Mais les objets standard viennent avec des bagages

L’autre moitié : l’ordre d’exécution n’est pas gratuit. Il apporte les licences Field Service, ses propres relations, son comportement de sécurité, ses champs obligatoires, son automatisation et son cycle de vie, et d’autres parties de la plateforme s’attendent à ce qu’il se comporte d’une certaine façon. Nous le choisissons parce que l’adéquation est nette et que nous utilisons ce qui est construit autour. Si Steve Trucking ne voulait rien de Field Service et que le modèle combattait le processus à chaque étape, je reconsidérerais. L’architecture, c’est l’adéquation, pas l’étiquette.

Articles de livraison : suivez le modèle

Une fois que la livraison est un ordre d’exécution, regardez le reste de ce modèle avant d’inventer quoi que ce soit. Un élément d’ordre d’exécution (Work Order Line Item) est une sous-tâche d’un ordre d’exécution (WorkOrderLineItem (opens in a new tab), en anglais) : le réfrigérateur, l’installation, l’enlèvement. Donc Article de livraison → élément d’ordre d’exécution. Remarquez que la première décision a façonné la seconde. Nous ne choisissons pas un objet pour chaque entité isolément. Adoptez un modèle, et comprenez-en le reste avant de construire des structures personnalisées autour.

De quel type d’arrêt s’agit-il ?

Chez Steve Trucking, un arrêt est une livraison seule, une livraison avec installation ou une livraison avec enlèvement, et chaque type a sa propre durée, ses compétences d’équipe et sa liste de contrôle d’installation. Au chapitre 2, nous avons décidé que c’est une entité, pas une étiquette. Field Service en a déjà une : le type de travail (Work Type), un modèle pour un type de travail qui peut s’appliquer aux ordres d’exécution et à leurs éléments (WorkType (opens in a new tab), en anglais). Donc Type d’arrêt → type de travail. Encore une fois, pas parce que quelque chose s’appelle Type de travail, mais parce que le concept et le comportement concordent.

Click to enlarge

Étape 2 sur 4 : suivez le modèle. Les éléments et le type de travail viennent avec l’ordre d’exécution.

Manifeste : là, je veux un objet personnalisé

Existe-t-il un objet standard pour « la liste du partenaire pour mardi au centre de Phoenix » ? Pas vraiment, et je ne vais pas le forcer dans un objet sans rapport juste pour dire que nous sommes restés standard. Manifeste → Manifest__c. C’est l’unité de réception : d’où il vient (un fichier, un lot API), quand, son statut et ses totaux, et, quand un partenaire le renvoie le jour même, ce qui est comparé. Chaque ligne du manifeste devient un ordre d’exécution qui y est relié.

Le personnalisé n’est pas un échec. C’est ce que la plateforme nous donne quand un concept n’a pas d’équivalent standard net. L’erreur n’est pas de créer un objet personnalisé ; c’est d’en créer un sans vérifier si la plateforme a déjà le concept.

Click to enlarge

Étape 3 sur 4 : le seul objet personnalisé, là où aucun objet standard ne convient.

Photos : ce n’est pas parce que Salesforce peut les stocker qu’il doit le faire

« Il nous faut les photos de livraison dans Salesforce. » Que veut dire « dans Salesforce » ? Les utilisateurs ont besoin de les voir depuis Salesforce, oui. Est-ce que cela veut dire que les fichiers image doivent vivre dans le stockage du cœur ? Pas forcément. Comptez les zéros : environ quatre photos par livraison, davantage avec les installations, à un million de livraisons par an, cela fait quatre à cinq millions de photos par an, et les livraisons augmentent de 30 % par an.

Ma position de départ est donc : ne transformez pas l’organisation principale en gigantesque photothèque parce que les utilisateurs ont besoin d’accéder aux photos. Les fichiers ont leur place dans un stockage conçu pour ce volume, hors du cœur, Salesforce gardant ce dont il a besoin pour les trouver et les afficher : une référence, un nombre, ou un petit enregistrement d’index par photo, et un indicateur signalant que les photos d’installation obligatoires sont complètes. L’accès aux données et l’endroit où elles vivent physiquement sont deux questions différentes. C’est le module 4 qui revient.

Champs : rendez le sens visible

L’ordre d’exécution a besoin de champs : la référence du partenaire, le créneau de livraison, l’heure réelle de livraison, le statut, des notes comme « code du portail » ou « chien dans le jardin ». Je ne vais pas en faire un catalogue de champs ; le module 6 s’en est chargé. Posez les questions pour chacun : ce qu’il signifie, à qui il appartient, s’il change, s’il s’agit d’un identifiant, d’un vocabulaire contrôlé, s’il est stocké ou dérivé, s’il est sensible. La référence du partenaire est l’ID externe, donc son unicité fait partie du contrat d’intégration, pas seulement d’une case à cocher. L’heure réelle de livraison est un instant, donc Date/Heure. Le statut pilote le comportement, donc une liste contrôlée, jamais du texte libre. Et les notes de livraison sur le domicile d’une personne sont des données personnelles, donc elles sont classifiées. Chaque champ remonte à un sens.

Relations : ne vous contentez pas de relier les boîtes

Compte vers ordre d’exécution, ordre d’exécution vers ses éléments, manifeste vers ordre d’exécution, type de travail décrivant l’arrêt. Puis les questions du module 7 pour chaque trait : l’enfant peut-il exister seul, à qui appartient-il, l’accès est-il hérité, peut-il bouger, que se passe-t-il à la suppression, combien d’enfants peuvent s’accumuler ? Tous les ordres d’exécution sous une poignée de comptes de partenaires distributeurs, cela fait des centaines de milliers d’enfants par parent : une question de déséquilibre à laquelle nous répondrons dans la partie 2. Et pour les relations standard de Field Service, vérifiez comment Salesforce les a déjà construites plutôt que de supposer qu’elles correspondent à ce que nous aurions conçu. Quand vous adoptez un modèle standard, vous adoptez les décisions que Salesforce y a prises. Comprenez-les avant de construire par-dessus.

La propriété et le destinataire : ne laissez pas le défaut décider

Deux décisions qu’un défaut prendrait volontiers à notre place.

À qui appartient une livraison ? Nous y avons répondu au module 8, et la réponse s’applique directement à l’ordre d’exécution : ici, la propriété ne détermine l’accès de personne, donc l’utilisateur d’intégration est propriétaire des ordres d’exécution qu’il crée. Les répartiteurs voient ceux de leur centre de distribution, les équipes ceux de leurs tournées, et chaque partenaire distributeur voit les siens via le portail, tout cela par le partage, pas par la propriété. L’utilisateur d’intégration n’a pas de rôle et reste en dehors des groupes publics qu’utilisent nos règles de partage, parce qu’à 3 300 par jour il dépasse 10 000 enregistrements en trois jours. Et nous écrivons ce qui se passe si cet utilisateur est un jour remplacé.

Qu’est-ce que le destinataire ? Un contact ? Un compte personnel ? Quelque chose gardé uniquement sur la livraison ? Cela dépend de la question de savoir si Steve Trucking a la moindre relation avec ces personnes (ce sont les clients des partenaires distributeurs), si un partenaire peut un jour voir ceux d’un autre, combien de temps leurs données personnelles peuvent être conservées, et du volume : environ un million de nouveaux destinataires par an. Nous n’avons pas encore tout cela, et ce n’est pas grave. Parfois, la bonne réponse est nous n’en savons pas encore assez. Notez la question et allez chercher l’information ; n’enterrez pas l’incertitude dans un objet personnalisé. Nous y répondons au point de contrôle de la partie 1, une fois que les chapitres 4 à 6 nous auront donné la vue de l’entreprise et des données maîtres.

Cohérence : protégez le modèle à la bonne couche

L’échelle du module 9 s’applique : la référence du partenaire est un ID externe, unique, donc un manifeste renvoyé fait un upsert au lieu de créer un doublon ; le statut est une liste restreinte ; l’heure réelle de livraison n’est obligatoire qu’une fois le statut Livrée ; un arrêt avec installation ne peut pas être clôturé sans sa liste de contrôle et ses photos. Pas un flow géant. Chaque règle sur son propre barreau.

Où vit chaque élément

Un dernier passage sur la tranche, avec la question du module 4 : où vit chaque élément de données ? Dans mon support de cours, c’est une seule diapositive, le logique face au physique : les entités logiques du chapitre 2, et l’endroit où chacune atterrit physiquement : sur le cœur, comme sObject (__c s’il est personnalisé) ou big object (__b), ou hors du cœur, comme objet externe (__x) ou comme données qui n’entrent jamais du tout dans Salesforce.

• Sur le cœur, utilisé tous les jours : le compte, les ordres d’exécution et leurs éléments, les rendez-vous de service, les types de travail, Manifest__c.
• Sur le cœur, archivé : les livraisons de plus de trois ans passent dans l’historique des livraisons (Delivery History), un big object, toujours là pour les réclamations, dans l’abri au fond du jardin.
• Référencé : les détails de commande propres au partenaire distributeur restent dans le système du partenaire ; nous gardons la référence du partenaire comme ID externe, et accédons au reste via un objet externe ou l’intégration quand quelqu’un en a besoin.
• Hors du cœur : les photos, dans un stockage conçu pour des millions d’images, avec un lien depuis l’ordre d’exécution.

Voilà le modèle physique : pas seulement quel objet, mais quel lieu de vie.

Regardez maintenant toute la tranche

• Partenaire distributeur → compte, avec un type d’enregistrement Retail Partner ; les responsables de centre comme contacts.
• Livraison → ordre d’exécution Field Service, planifié par un rendez-vous de service.
• Article de livraison → élément d’ordre d’exécution.
• Type d’arrêt → type de travail.
• Manifeste → Manifest__c personnalisé.
• Référence du partenaire → ID externe sur l’ordre d’exécution, unique par partenaire.
• Photos → stockées hors du cœur ; Salesforce garde la référence et l’indicateur de complétude.
• Historique des livraisons → archivé dans un big object après trois ans.
• Propriété → l’utilisateur d’intégration, avec l’accès par le partage (module 8).
• Destinataire → ouvert, pour le point de contrôle de la partie 1.

Click to enlarge

Étape 4 sur 4 : toute la tranche, sur le cœur, archivée et hors du cœur. Chaque trait est une relation de référence : Salesforce a construit Field Service sur des relations de référence, et nous adoptons ses décisions avec.

Le schéma n’est pas l’architecture

Je peux vous remettre ce schéma, et ce n’est pas suffisant. L’architecture, c’est le raisonnement derrière. Pourquoi un compte ? Une entreprise en adéquation nette. Pourquoi un ordre d’exécution et pas Delivery__c ? La livraison se comporte comme du travail sur le terrain, et Field Service est déjà en place. Pourquoi un manifeste personnalisé ? Pas d’équivalent standard net. Pourquoi les photos ne sont-elles pas de simples fichiers ? Le volume et l’économie du stockage. Pourquoi un ID externe ? Un autre système a besoin d’une identité stable de part et d’autre de la frontière. Pourquoi l’utilisateur d’intégration est-il propriétaire des ordres d’exécution ? La propriété ne détermine pas l’accès ici, et cela garde la piste d’audit honnête. Pourquoi le destinataire reste-t-il ouvert ? Nous n’avons pas encore répondu à assez de questions. Les traits sont le résultat ; ce sont les décisions qui les ont produits.

Voici donc l’habitude avec laquelle je veux que vous quittiez le chapitre 3. Montrez n’importe quoi dans un modèle physique et demandez pourquoi ? Pourquoi cet objet, ce type, cette relation, ce propriétaire, cet endroit, cette règle ? Vous devriez pouvoir faire remonter la réponse : de la configuration au modèle physique, au modèle logique, jusqu’à l’exigence métier. Si vous ne le pouvez pas, quelqu’un a conçu depuis la Configuration.

Et vous aurez remarqué les chiffres que nous n’avons pas complètement travaillés : livraisons par partenaire, éléments, photos, conservation, archivage. Tant mieux. Demandez le nombre de zéros avant de figer une conception : un modèle qui fonctionne parfaitement à cinquante mille enregistrements peut se comporter très différemment à cinq cents millions. C’est la partie 2.

Au-delà de l’examen : ce que l’IA change. Donnez le dossier de Steve Trucking à une IA et elle produira un schéma en quelques secondes : compte, ordre d’exécution, objets personnalisés, champs, et même les métadonnées de déploiement. C’est un accélérateur fantastique, et ce n’est pas la revue. Le travail de l’architecte se déplace vers la vérification des correspondances et de leurs conséquences : adéquation, licences, propriété, cycle de vie, volume, identité, sécurité et ce qui reste hors plateforme. L’IA est le propulseur de fusée ; elle ne vous dit pas si vous êtes orienté dans la bonne direction.

Ce que l’architecte décide ici

• Comment chaque concept métier correspond à Salesforce : un objet standard, un objet personnalisé, ou quelque chose hors du cœur.
• Quels identifiants, champs et relations mettent en œuvre le sens métier sans le modifier en douce.
• Quel comportement de la plateforme et quelles licences viennent avec un modèle standard que vous adoptez.
• Quelles décisions de propriété, de cycle de vie, de cohérence, de stockage et de volume doivent être prises avant que la conception soit complète.
• Quelles questions restent explicitement ouvertes, plutôt que cachées derrière un choix de mise en œuvre arbitraire.

Au début de ce chapitre, nous avons demandé comment le modèle devait vivre sur Salesforce. C’est cela, l’architecture de données Salesforce : ni créer des objets, ni apprendre la Configuration par cœur, ni dessiner de plus jolies boîtes, mais adapter délibérément le modèle métier à la forme de la plateforme. Chaque structure est un engagement. Prenez ceux que vous pouvez expliquer.

Pour aller plus loin

• Salesforce Developers, Object Reference : WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) et WorkType (opens in a new tab) (en anglais), consulté le 2026-10-02.
• Le dossier de Steve Trucking (en anglais).