Salesforce में Organization-Wide Defaults (OWD): एक व्याख्या

Org-wide defaults वह जगह है जहाँ से Salesforce का हर sharing निर्णय शुरू होता है। इन्हें सही कर लें तो बाकी model — role hierarchy, sharing rules, shares — को बनने के लिए एक साफ़ नींव मिल जाती है। इन्हें गलत कर दें (आमतौर पर बहुत खुला) तो कितने भी चतुर sharing rules इसे ठीक नहीं कर पाएँगे। यह गाइड समझाती है कि ये क्या हैं और इन्हें अच्छी तरह कैसे सेट करें।

org-wide defaults क्या हैं

Organization-Wide Defaults (OWD) प्रति object यह परिभाषित करते हैं कि users को उन records तक access का baseline स्तर क्या होगा जिनके वे owner नहीं हैं। ये सबसे प्रतिबंधात्मक सेटिंग हैं; बाकी सब कुछ इस फर्श से ऊपर access खोलने के लिए मौजूद है।

Org-wide defaults फर्श हैं। Role hierarchy और sharing rules वे तरीके हैं जिनसे आप कुछ विशिष्ट लोगों को इसके ऊपर उठाते हैं। कोई भी standard तरीका आपको इसके नीचे जाने नहीं देता।

यही वजह है कि OWD record access model की पहली परत है।

access levels

हर object का OWD इनमें से किसी एक पर सेट होता है:

स्तर	कौन क्या देख / कर सकता है
Private	केवल owner (और role hierarchy में उनसे ऊपर के users) देख सकते हैं
Public Read Only	object access वाला हर कोई देख सकता है; केवल owner संपादित कर सकता है
Public Read/Write	object access वाला हर कोई देख और संपादित कर सकता है
Controlled by Parent	access संबंधित master/parent record का अनुसरण करता है

कुछ objects अतिरिक्त variants देते हैं (जैसे leads और cases के लिए Read/Write/Transfer)।

internal बनाम external defaults

कई objects आपको अलग-अलग internal और external org-wide defaults सेट करने देते हैं। external default Experience Cloud (community) और portal users को नियंत्रित करता है और यह internal वाले से अधिक प्रतिबंधात्मक हो सकता है — और आमतौर पर होना भी चाहिए — ताकि external दर्शक उस व्यापक access को विरासत में न लें जो आपके स्टाफ़ के पास है।

सर्वोत्तम अभ्यास: प्रतिबंधात्मक शुरू करें, सोच-समझकर खोलें

स्वर्णिम नियम:

OWD को सबसे प्रतिबंधात्मक स्तर पर सेट करें जिसे व्यवसाय सहन कर सके — आमतौर पर Private — फिर role hierarchy और sharing rules से access खोलें।

इसका कारण sharing model की दिशा है। Access additive है: आप Private baseline के ऊपर हमेशा access जोड़ सकते हैं, लेकिन एक अत्यधिक खुले OWD द्वारा पहले ही सबको दिए गए access को sharing rules से घटा नहीं सकते। Private से शुरू करना model को इरादतन, auditable और समझने में आसान बनाए रखता है।

चुनने का एक त्वरित तरीका

हर object के लिए पूछें: क्या कोई ऐसा कर्मचारी जो इस record का owner नहीं है, इसे default रूप से देख पाना चाहिए?

• नहीं, कभी नहीं → Private।
• वे पढ़ सकते हैं पर बदल नहीं सकते → Public Read Only।
• कोई भी इसे स्वतंत्र रूप से संपादित कर सकता है → Public Read/Write (संवेदनशील data के लिए दुर्लभ)।

live होने के बाद OWD बदलना

• OWD को खोलना (जैसे Private → Public Read Only) कम-जोखिम वाला है — यह केवल अधिक access देता है।
• OWD को कसना (Public → Private) वह बदलाव है जिसकी योजना बनानी चाहिए। यह एक sharing recalculation शुरू करता है और उस access को हटा सकता है जिस पर users वर्तमान में निर्भर हैं। sandbox में परीक्षण करें, और ship करने से पहले सूचना दें।

OWD पहली चीज़ क्यों है जिसका audit होना चाहिए

क्योंकि हर दूसरा तंत्र इसी पर बनता है, एक अत्यधिक खुला OWD चुपचाप बढ़ा देता है कि हर कोई क्या देख सकता है — और यह तब तक अदृश्य रहता है जब तक कोई न पूछे “रुकिए, ये सब कौन देख सकता है?” जब आप access की समीक्षा करते हैं, तो OWD वही baseline है जो सबसे बड़े आश्चर्यों की व्याख्या करता है।

AgentForceAccess उस baseline को सुपाठ्य बनाता है: पूछिए कि कोई user किसी record को क्यों देख सकता है और यह बताता है कि कब इसका उत्तर बस इतना है कि “org-wide default Public है” — बनाम कोई विशिष्ट rule या share — ताकि आप सही परत पर कारण ठीक करें।

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

हर OWD access level का क्या अर्थ है?

Private — केवल owner और role hierarchy में उनसे ऊपर के users record देख सकते हैं। Public Read Only — object access वाला हर कोई देख सकता है, केवल owner संपादित कर सकता है। Public Read/Write — हर कोई देख और संपादित कर सकता है। Controlled by Parent — access संबंधित master record का अनुसरण करता है।

मुझे Private से क्यों शुरू करना चाहिए?

क्योंकि sharing additive है: आप role hierarchy और sharing rules से access हमेशा खोल सकते हैं, लेकिन एक अत्यधिक खुले OWD द्वारा पहले से दिए गए access को इनसे वापस नहीं ले सकते। Private से शुरू करना और सोच-समझकर इसे चौड़ा करना model को इरादतन और auditable बनाए रखता है।

internal बनाम external org-wide defaults क्या हैं?

कई objects आपको external users — Experience Cloud / community और portal users — के लिए एक अलग default सेट करने देते हैं जो internal default से अधिक प्रतिबंधात्मक हो सकता है। यह external दर्शकों को आपके internal users के पास मौजूद access को विरासत में लेने से रोकता है।

क्या मैं live होने के बाद किसी एक object के लिए access कम कर सकता हूँ?

हाँ, लेकिन OWD को कसने से एक sharing recalculation शुरू होती है और यह उस access को हटा सकती है जिस पर लोग वर्तमान में निर्भर हैं, इसलिए sandbox में परीक्षण करें और बदलाव की सूचना दें। OWD खोलना कम-जोखिम वाला है; उसे प्रतिबंधित करना वह बदलाव है जिसकी सावधानी से योजना बनानी चाहिए।