FichiersContentDocumentAdministrateur Salesforce

Le partage de fichiers sur les enregistrements (ContentDocumentLink)

Le modèle de données des fichiers Salesforce : ContentDocument, ContentVersion et ContentDocumentLink, où ShareType et Visibility décident qui voit un fichier.

AgentForceAccess 3 min de lecture
Un schéma représentant un nœud de fichier central relié à des entités enregistrement, utilisateur et groupe

Si vous vous êtes déjà demandé pourquoi un fichier apparaît là où il apparaît dans Salesforce, ou si vous avez eu à interroger des fichiers en Apex ou dans un rapport, il vous faut comprendre le modèle de données sous-jacent. Les fichiers Salesforce modernes reposent sur trois objets liés, et deux champs sur le lien décident qui voit quoi. C’est le pendant technique, destiné aux admins et développeurs, de qui peut voir un fichier dans Salesforce.

Les trois objets

ObjetCe que c’estCombien
ContentDocumentLe fichier lui-mêmeUn par fichier
ContentVersionUne version précise du contenu du fichierUne par chargement/révision
ContentDocumentLinkUn lien rattachant le fichier à un enregistrement, un utilisateur ou un groupePlusieurs par fichier

Lorsque vous chargez un fichier, vous créez une ContentVersion, que Salesforce encapsule dans un ContentDocument. Lorsque vous rattachez ce fichier à un enregistrement ou le partagez avec quelqu’un, vous créez un ContentDocumentLink.

Le fichier est le ContentDocument. Où il se trouve et qui peut le voir dépend entièrement de ses ContentDocumentLinks.

Une ligne ContentDocumentLink dit « ce fichier est lié à telle chose, à ce niveau d’accès, pour cette audience ». Ses champs clés :

LinkedEntityId — ce à quoi le fichier est rattaché

L’ID de ce à quoi le fichier est lié :

  • Un enregistrement (Account, Opportunity, Case, objet personnalisé…) → le fichier est « rattaché à » cet enregistrement.
  • Un User ou Group → le fichier est partagé directement avec cette personne ou ce groupe.

Un même fichier peut avoir plusieurs liens à la fois : rattaché à deux enregistrements et partagé avec un utilisateur simultanément. Chaque lien est un chemin indépendant pour voir le fichier.

ShareType — le niveau d’accès

ValeurNiveauPermet de
VViewerOuvrir et télécharger
CCollaboratorConsulter, modifier, charger de nouvelles versions, changer le partage
IInferredNiveau d’accès hérité de l’accès à l’enregistrement lié

Inferred (I) est le cas important pour les fichiers rattachés à un enregistrement : l’accès d’un utilisateur au fichier est dérivé de son accès à l’enregistrement auquel il est lié. C’est le mécanisme derrière « toute personne qui voit l’enregistrement voit ses fichiers ».

Visibility — quelle audience

ValeurAudience
AllUsersUtilisateurs internes et externes (communauté)
InternalUsersUtilisateurs internes uniquement
SharedUsersUniquement les utilisateurs avec qui le fichier est explicitement partagé

C’est ce champ qui casse discrètement l’accès Experience Cloud : un fichier rattaché à un enregistrement avec Visibility = InternalUsers n’apparaîtra pas aux utilisateurs de la communauté, même s’ils peuvent voir l’enregistrement. (Plus de détails dans fichiers et utilisateurs invités / Experience Cloud.)

Comment l’accès se résout réellement

En réunissant le tout, un utilisateur peut voir un fichier si l’un de ses ContentDocumentLinks le lui accorde :

  1. Un lien vers un enregistrement auquel il a accès (ShareType I) — accès hérité du partage de l’enregistrement.
  2. Un lien directement vers lui ou son groupe (ShareType V/C).
  3. Une appartenance à une bibliothèque, ou un lien public (mécanismes distincts).

…et la Visibility du lien doit inclure son audience. La plupart des tickets « fichier non visible » se ramènent à un lien manquant ou à une Visibility trop restrictive.

L’interroger

Comme tout cela n’est que de la donnée, vous pouvez l’inspecter directement — par exemple, trouver tous les endroits où un fichier est partagé :

SELECT ContentDocumentId, LinkedEntityId, ShareType, Visibility
FROM ContentDocumentLink
WHERE ContentDocumentId = '069...'

Chaque ligne représente une audience qui peut atteindre le fichier. Pour énumérer les personnes, vous devez ensuite déployer l’audience de partage complète de chaque enregistrement LinkedEntityId — et c’est là que cela devient vite volumineux.

Des lignes à une réponse en langage clair

Un fichier rattaché à plusieurs enregistrements hérite de l’audience entière de chaque enregistrement — hiérarchie des rôles, règles de partage, équipes et tout le reste — multipliée sur l’ensemble des ContentDocumentLinks. Reconstituer cela à la main à partir de lignes brutes, c’est exactement le travail qui dissimule les expositions accidentelles. AgentForceAccess parcourt les ContentDocumentLinks et le partage des enregistrements derrière chacun d’eux, et répond à la question « qui peut voir ce fichier, et pourquoi » en langage clair.

Questions fréquentes

Quelle est la différence entre ContentDocument, ContentVersion et ContentDocumentLink ?

ContentDocument est le fichier lui-même (un par fichier). ContentVersion est une version précise de ce fichier (une par chargement/révision). ContentDocumentLink relie un ContentDocument à autre chose (un enregistrement, un utilisateur ou un groupe) et porte le niveau d'accès et la visibilité de ce lien.

Vers quoi pointe LinkedEntityId ?

C'est l'ID de ce à quoi le fichier est lié. Pour un fichier rattaché à un enregistrement, c'est l'ID de l'enregistrement (Account, Opportunity, Case, etc.) ; pour un fichier partagé directement avec une personne ou un groupe, c'est un ID User ou Group. Un même fichier peut avoir plusieurs ContentDocumentLinks à la fois.

Que signifient les valeurs V, C et I de ShareType ?

V = Viewer (ouverture et téléchargement), C = Collaborator (consultation, modification, chargement de versions, changement du partage), I = Inferred (le niveau d'accès obtenu indirectement via l'accès à l'enregistrement lié). Inferred est le mécanisme par lequel l'accès à l'enregistrement se propage au fichier.

À quoi sert le champ Visibility ?

Visibility définit à qui le lien est exposé : AllUsers (utilisateurs internes et externes/communauté), InternalUsers (internes uniquement) ou SharedUsers (uniquement les utilisateurs avec qui le fichier est explicitement partagé). Les utilisateurs Community/Experience Cloud ont généralement besoin de AllUsers pour voir un fichier rattaché à un enregistrement.

Voyez-le sur votre propre org

AgentForceAccess explique, en langage clair, pourquoi n'importe quel utilisateur peut voir n'importe quel enregistrement ou fichier — à travers chaque mécanisme de partage Salesforce.

Demander un accès anticipé