Page Layouts vs Dynamic Forms : que choisir ?

Pendant des années, les Page Layouts ont été le seul moyen d'organiser les champs sur une page d'enregistrement Salesforce. Les Dynamic Forms, disponibles nativement sur les objets standards et personnalisés, offrent une approche bien plus flexible pilotée par des conditions de visibilité au niveau du champ. Voici comment trancher.

Page Layouts : le modèle historique

Un Page Layout (Configuration > Générateur d'objets > [Objet] > Présentations de page) définit statiquement quels champs, listes associées et boutons apparaissent sur une page, assignés par combinaison profil/type d'enregistrement. Ses limites structurelles :

• Toute la section de champs s'affiche ou se masque en bloc ; impossible de masquer un champ individuel selon une condition sans passer par la sécurité au niveau champ (FLS) ou du code.
• Un changement de layout nécessite souvent de dupliquer et maintenir plusieurs présentations quasi identiques pour chaque combinaison profil/type d'enregistrement.
• Le rendu n'est pas responsive de façon fine : la disposition en colonnes reste rigide.

Dynamic Forms : la flexibilité au niveau champ

Les Dynamic Forms déplacent les champs du Page Layout vers le Lightning App Builder, où chaque champ (ou section de champs) devient un composant indépendant que l'on peut positionner librement et surtout conditionner :

• Visibility Rules : afficher ou masquer un champ (ou une section entière) selon la valeur d'un autre champ, sans une seule ligne de code — par exemple, n'afficher le champ « Motif de refus » que si le champ « Statut » vaut « Refusé ».
• Une seule page Lightning peut remplacer plusieurs Page Layouts si la logique conditionnelle absorbe les variations auparavant gérées par des présentations séparées.
• Compatible avec la disposition en colonnes flexibles du Lightning App Builder pour un rendu plus soigné et responsive.

Comment activer les Dynamic Forms

1. Ouvrez la page Lightning de l'objet concerné dans le Lightning App Builder (ou créez-en une nouvelle si l'objet utilise encore la page de détail standard).
2. Sélectionnez le composant « Détails d'enregistrement » et cliquez sur « Migrer vers Dynamic Forms » : Salesforce importe automatiquement les champs et sections de votre Page Layout actuel dans le canevas.
3. Ajustez ensuite la disposition librement et ajoutez des règles de visibilité sur les champs qui en ont besoin, via le panneau des propriétés de chaque champ.
4. Activez la page comme page par défaut pour l'application concernée (Configuration > Gestionnaire d'application Lightning).

Ce que les Dynamic Forms ne remplacent pas (encore)

Il reste des cas où le Page Layout classique garde un rôle, même une fois les Dynamic Forms activées :

• Les listes associées, boutons personnalisés hérités, et certains composants historiques restent définis au niveau du Page Layout ou nécessitent leur propre composant Lightning sur la page.
• Les objets utilisés en mode Salesforce Classic ou dans certains contextes mobiles hors ligne peuvent avoir un support partiel selon la version de l'application mobile.
• Les pages de saisie rapide (Quick Actions, Publisher) suivent encore parfois leur propre mini-layout distinct.

Piège fréquent lors de la migration : les règles de validation et la sécurité au niveau champ (FLS) continuent de s'appliquer indépendamment des Dynamic Forms. Masquer un champ via une règle de visibilité Dynamic Forms n'exempte pas l'utilisateur de la règle de validation qui l'exige — pensez à aligner les deux logiques pour éviter des blocages incompréhensibles.

Faut-il migrer systématiquement ?

Pour les nouveaux objets et applications, les Dynamic Forms sont clairement l'approche à privilégier dès le départ. Pour les objets existants avec de nombreux Page Layouts déjà en place :

• Migrez en priorité les objets à forte volumétrie de présentations dupliquées (souvent Compte, Opportunité, objets personnalisés avec plusieurs types d'enregistrement), où le gain de simplification est le plus net.
• Testez la migration en sandbox avec chaque profil concerné : les règles de visibilité Dynamic Forms doivent être revalidées manuellement, elles ne sont pas déduites automatiquement des anciennes règles d'affichage conditionnelles de type Process Builder.
• Communiquez le changement aux utilisateurs si la disposition visuelle change sensiblement, même si les données restent identiques.

Les Dynamic Forms représentent une vraie simplification de la maintenance à moyen terme, au prix d'un effort de migration initial qu'il vaut mieux planifier objet par objet plutôt qu'en un seul big-bang.