फ़ाइलेंContentDocumentSalesforce एडमिन

रिकॉर्ड पर फ़ाइल शेयरिंग कैसे काम करती है (ContentDocumentLink)

Salesforce Files के पीछे का डेटा मॉडल: ContentDocument, ContentVersion और ContentDocumentLink — और ShareType व Visibility कैसे तय करते हैं कि फ़ाइल किसे दिखे।

AgentForceAccess 4 मिनट पढ़ें
एक केंद्रीय फ़ाइल नोड का स्कीमा आरेख जो रिकॉर्ड, यूज़र और ग्रुप एंटिटीज़ से जुड़ा है

अगर आपने कभी सोचा है कि कोई फ़ाइल Salesforce में जहाँ दिखती है, वहाँ क्यों दिखती है — या आपको Apex में या किसी रिपोर्ट में फ़ाइलों की क्वेरी करनी पड़ी हो — तो आपको इसके नीचे का डेटा मॉडल जानना ज़रूरी है। आधुनिक Salesforce Files तीन परस्पर संबंधित ऑब्जेक्ट हैं, और कड़ी पर मौजूद दो फ़ील्ड तय करती हैं कि कौन क्या देखता है। यह Salesforce में कोई फ़ाइल कौन देख सकता है का एडमिन/डेवलपर साथी लेख है।

तीन ऑब्जेक्ट

ऑब्जेक्टयह क्या हैकितने
ContentDocumentस्वयं फ़ाइलप्रति फ़ाइल एक
ContentVersionफ़ाइल की सामग्री का एक विशिष्ट संस्करणप्रति अपलोड/संशोधन एक
ContentDocumentLinkफ़ाइल को किसी रिकॉर्ड, यूज़र या ग्रुप से जोड़ने वाली कड़ीप्रति फ़ाइल कई

जब आप कोई फ़ाइल अपलोड करते हैं तो आप एक ContentVersion बनाते हैं, जिसे Salesforce एक ContentDocument में लपेट देता है। जब आप उस फ़ाइल को किसी रिकॉर्ड से जोड़ते हैं या किसी के साथ शेयर करते हैं, तो आप एक ContentDocumentLink बनाते हैं।

फ़ाइल ही ContentDocument है। वह कहाँ रहती है और उसे कौन देख सकता है — यह पूरी तरह उसके ContentDocumentLinks में निहित है।

एक ContentDocumentLink पंक्ति कहती है कि “यह फ़ाइल उस चीज़ से जुड़ी है, इस एक्सेस स्तर पर, इस वर्ग के लिए।” इसकी मुख्य फ़ील्ड:

LinkedEntityId — फ़ाइल किससे जुड़ी है

जिस चीज़ से फ़ाइल जुड़ी है उसकी ID:

  • एक रिकॉर्ड (Account, Opportunity, Case, कस्टम ऑब्जेक्ट…) → फ़ाइल उस रिकॉर्ड से “जुड़ी” है।
  • एक User या Group → फ़ाइल उस व्यक्ति या ग्रुप के साथ सीधे शेयर की गई है।

एक ही फ़ाइल के एक साथ कई लिंक हो सकते हैं — एक साथ दो रिकॉर्ड से जुड़ी हो और एक यूज़र के साथ शेयर हो। प्रत्येक लिंक फ़ाइल को देखने का एक स्वतंत्र रास्ता है।

ShareType — एक्सेस का स्तर

मानस्तरक्या कर सकते हैं
VViewerखोलना और डाउनलोड करना
CCollaboratorदेखना, संपादित करना, नए संस्करण अपलोड करना, शेयरिंग बदलना
IInferredजुड़े रिकॉर्ड तक एक्सेस से विरासत में मिला एक्सेस स्तर

Inferred (I) रिकॉर्ड से जुड़ी फ़ाइलों के लिए सबसे महत्वपूर्ण है: किसी फ़ाइल तक यूज़र की एक्सेस उस रिकॉर्ड तक उसकी एक्सेस से व्युत्पन्न होती है जिससे वह जुड़ी है। यही वह तंत्र है जिसके पीछे “जो भी रिकॉर्ड देख सकता है वह उसकी फ़ाइलें देख सकता है” का सिद्धांत है।

Visibility — कौन सा वर्ग

मानवर्ग
AllUsersआंतरिक और बाहरी (community) यूज़र
InternalUsersकेवल आंतरिक यूज़र
SharedUsersकेवल वे यूज़र जिनके साथ फ़ाइल स्पष्ट रूप से शेयर की गई है

यही वह फ़ील्ड है जो चुपचाप Experience Cloud एक्सेस को तोड़ देती है: Visibility = InternalUsers वाली, किसी रिकॉर्ड से जुड़ी फ़ाइल community यूज़रों को नहीं दिखेगी, भले ही वे रिकॉर्ड देख सकते हों। (इस पर और जानकारी फ़ाइलें और guest / Experience Cloud यूज़र में है।)

एक्सेस वास्तव में कैसे तय होती है

सब कुछ मिलाकर, कोई यूज़र किसी फ़ाइल को तब देख सकता है जब उसके ContentDocumentLinks में से कोई एक उसे यह प्रदान करे:

  1. किसी ऐसे रिकॉर्ड का लिंक जिसे वे एक्सेस कर सकते हैं (ShareType I) — रिकॉर्ड की शेयरिंग से विरासत में मिली एक्सेस।
  2. सीधे उन्हें या उनके ग्रुप का लिंक (ShareType V/C)।
  3. किसी लाइब्रेरी की सदस्यता, या कोई सार्वजनिक लिंक (अलग तंत्र)।

…और लिंक की Visibility में उनका वर्ग शामिल होना चाहिए। ज़्यादातर “फ़ाइल नहीं दिख रही” टिकटें किसी अनुपस्थित लिंक या बहुत संकीर्ण Visibility पर आकर ठहरती हैं।

इसकी क्वेरी करना

चूँकि यह सब डेटा है, आप इसका सीधे निरीक्षण कर सकते हैं — उदाहरण के लिए, हर वह जगह ढूँढना जहाँ कोई फ़ाइल शेयर की गई है:

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

प्रत्येक पंक्ति एक ऐसा वर्ग है जो फ़ाइल तक पहुँच सकता है। लोगों की गणना करने के लिए, आप फिर प्रत्येक LinkedEntityId रिकॉर्ड के पूरे शेयरिंग वर्ग का विस्तार करते हैं — और यहीं यह तेज़ी से बहुत बड़ा हो जाता है।

पंक्तियों से सीधे-सादे जवाब तक

कई रिकॉर्ड से जुड़ी एक फ़ाइल प्रत्येक रिकॉर्ड के पूरे वर्ग को विरासत में पाती है — role hierarchy, sharing rules, teams सब कुछ — और यह हर ContentDocumentLink पर गुणित होता जाता है। कच्ची पंक्तियों से इसे हाथ से पुनर्निर्मित करना ठीक वही काम है जिसमें आकस्मिक एक्सपोज़र छिप जाता है। AgentForceAccess ContentDocumentLinks और उनमें से प्रत्येक के पीछे की रिकॉर्ड शेयरिंग का विश्लेषण करता है, और सीधे-सादे शब्दों में जवाब देता है कि “इस फ़ाइल को कौन देख सकता है, और क्यों”।

अक्सर पूछे जाने वाले सवाल

ContentDocument, ContentVersion और ContentDocumentLink में क्या अंतर है?

ContentDocument स्वयं फ़ाइल होती है (प्रति फ़ाइल एक)। ContentVersion उस फ़ाइल का एक विशिष्ट संस्करण होता है (प्रति अपलोड/संशोधन एक)। ContentDocumentLink किसी ContentDocument को किसी और चीज़ से जोड़ती है — एक रिकॉर्ड, यूज़र या ग्रुप — और उस कड़ी के लिए एक्सेस स्तर तथा visibility रखती है।

LinkedEntityId किसकी ओर इशारा करता है?

यह उस चीज़ की ID है जिससे फ़ाइल जुड़ी है। किसी रिकॉर्ड से जुड़ी फ़ाइल के लिए यह रिकॉर्ड ID होती है (Account, Opportunity, Case आदि); किसी व्यक्ति या ग्रुप के साथ सीधे शेयर की गई फ़ाइल के लिए यह User या Group ID होती है। एक ही फ़ाइल के एक साथ कई ContentDocumentLinks हो सकते हैं।

ShareType के मान V, C और I क्या हैं?

V = Viewer (खोलना और डाउनलोड करना), C = Collaborator (देखना, संपादित करना, संस्करण अपलोड करना, शेयरिंग बदलना), I = Inferred (वह एक्सेस स्तर जो किसी यूज़र को जुड़े रिकॉर्ड तक एक्सेस से अप्रत्यक्ष रूप से मिलता है)। Inferred ही वह तरीका है जिससे रिकॉर्ड एक्सेस किसी फ़ाइल तक पहुँचता है।

Visibility फ़ील्ड क्या करती है?

Visibility तय करती है कि कड़ी किसके सामने उजागर है: AllUsers (आंतरिक और बाहरी/community यूज़र), InternalUsers (केवल आंतरिक), या SharedUsers (केवल वे यूज़र जिनके साथ फ़ाइल स्पष्ट रूप से शेयर की गई है)। किसी रिकॉर्ड से जुड़ी फ़ाइल देखने के लिए Community/Experience Cloud यूज़रों को आमतौर पर AllUsers की ज़रूरत होती है।

इसे अपने org पर देखें

AgentForceAccess सीधी भाषा में समझाता है कि कोई भी user किसी भी record या file को क्यों देख सकता है — हर Salesforce sharing तंत्र में।

जल्द access का अनुरोध करें