Salesforce: métadonnées personnalisées v. objets personnalisés
18 Oct 2018
Une collègue, peu familière avec Salesforce, m’a demandée quelle était la différence entre « métadonnées personnalisées » et « objets personnalisés » pour stocker des données de configuration et de validation dans une organisation Salesforce.
J’ai répondu:
Selon Salesforce, s’il est possible, utilisez des métadonnées personnalisées.
(Elles survivent l’actualisation d’un environnement sandbox.)Stockez vos informations aux tables de bases de données (objets personnalisés) s’il faut créer des relations aux autres objets de votre organisation.
(Par exemple, s’il y a des utilisateurs qui vont générer des rapports sur ces données.)
Mon approche
Lorsque j’ai écrit un trigger Apex pour attribuer les enregistrements de notre objet « demande d’admission » aux utilisateurs corrects, j’ai fini par utiliser les deux approches:
Métadonnées personnalisées
J’ai choisi une type de métadonnées personnalisées pour stocker des données simples concernant « qui gère chaque spécialisation ? »
- clé: le code qui indique un diplôme d’études supérieures que l’université offre
- valeur: un nom d’utilisateur chargé de recruter des étudiants au diplôme
Objets personnalisés
J’ai choisi un objet personalisé pour stocker une liste d’états américains (abréviation et nom), avec quelques champs de référence indiquant les utilisateurs qui y gèrent divers aspects du recrutement d’étudiants en license.
- Nos utilisateurs ont besoin de générer des rapports, regroupés par utilisateur, avec les états qu’ils gèrent et les lycées qui y sont situés. Donc il fallait pouvoir créer une relation de l’objet « lycée » à l’objet « état ».
- On peut créer des relations entre métadonnées personnalisées, mais pas entre les types de métadonnées personnalisées et les objets personalisés.
- Donc j’ai choisi un modèle « objet personnalisé » pour stocker les informations à propos des états, même si ces informations servent aussi comme données de configuration pour un trigger Apex.
Considérations au sujet de l’interface utilisateur et au contrôle d’accès
Je vais vous révéler un secret : ce n’est pas qu‘à propos des besoins relationnels que j’ai choisi le modèle « objet personnalisé » pour les informations à propos de la gestion du recrutement en licence.
Le service admission en license changent les règles de « qui gère quoi » plusieurs fois par an. Et les données de configuration sont, en réalité, beaucoup plus complexes qu’une seule liste d’états.
Actuellement, les interfaces utilisateur de Salesforce pour voir et enregistrer des données aux objets personnalisés sont supérieures à celles pour les métadonnées personnalisées – surtout si l’on est utilisateur ordinaire. Le contrôle d’accès, aussi, est plus facile à gérer pour les administrateurs. Je voulais m’assurer que ça soit des utilisateurs ordinaires qui font plusieurs fois par an cette saisie de données, et non pas les administrateurs !
On m’a fait honte de cette position à Dreamforce. Ben, je maintiens ma choix d’objet personnalisé pour raisons de relations entre objets. Mais … on a beaucoup répété qu’il est de bonne pratique de construire ses propres interfaces utilisateur pour autoriser des utilisateurs ordinaires à modifier les métadonnées personnalisées en toute sécurité. Je vous aurai prévenus !
