Comment documenter une org Salesforce

Partir d’un besoin précis

Documenter une org Salesforce, c’est décrire votre configuration : modèle de données, automatisations, règles de validation, accès et intégrations. La documentation de Salesforce explique la plateforme. La vôtre explique ce qui a été construit dans votre org.

Fixez d’abord l’objectif : reprise d’une org, audit ou revue d’une livraison. Commencez par un processus important et son équipe responsable. Notez l’org, l’environnement, la date d’extraction, la révision du dépôt et les types de composants inclus.

Inventorier les objets et leurs responsables

Pour chaque objet du périmètre, notez le nom API, les champs utiles, les relations et le responsable. Gardez le nom API à côté du libellé métier. Le relecteur retrouve ainsi le composant source.

Séparez la description lue dans les métadonnées du sens confirmé par le métier. Un champ sans référence détectée n’est pas forcément inutilisé : un système externe peut le lire.

Décrire chaque automatisation par ses conditions et ses effets

Pour chaque Flow, règle de validation ou point d’entrée Apex, notez le déclencheur, les conditions, les champs lus et écrits, les appels et les exceptions. Ajoutez la version et l’état d’activation. Suivez les sous-flows et le code appelé.

Décrivez chaque branche à part. Pour une règle de validation, écrivez la condition qui bloque l’enregistrement. Donnez un exemple accepté et un exemple refusé. La raison métier ne se lit pas dans la formule : demandez-la au responsable.

Cartographier les dépendances

Reliez les composants à partir des références de métadonnées et de l’analyse du code. Gardez une preuve pour chaque lien. Listez à part les consommateurs externes : une intégration se configure souvent hors de Salesforce.

Certains liens échappent à l’analyse : noms de champs construits dynamiquement, packages gérés illisibles, métadonnées inaccessibles. Notez-les comme inconnus.

Documenter les accès

Listez les profils, ensembles d’autorisations et règles de partage du périmètre. Les droits d’un utilisateur combinent plusieurs sources : ne les déduisez pas d’un seul profil. Notez les scénarios que vous avez réellement testés.

Faire relire, publier, mettre à jour

Un relecteur technique vérifie les sources. Le responsable métier vérifie les explications. Publiez les questions ouvertes à côté de la section concernée. Donnez à chaque section une date de revue et un responsable.

Après chaque livraison, actualisez la base, comparez les changements et relisez les explications touchées. La documentation décrit l’org au moment de la dernière extraction.

Où intervient aprity

aprity construit un portail de documentation depuis les métadonnées Salesforce. Il calcule les dépendances et utilise l’IA pour expliquer les résultats. Vous gagnez du temps sur l’inventaire, l’exploration et la mise à jour. Votre équipe valide l’intention métier et les dépendances externes. Le modèle et l’exemple ci-dessous vous aident à fixer vos attentes avant d’évaluer un outil.