Restriction rules बनाम scoping rules बनाम sharing rules
Sharing rules एक्सेस खोलते हैं, restriction rules उसे घटाते हैं, scoping rules सिर्फ डिफ़ॉल्ट व्यू तय करते हैं। तीनों में अंतर और किसका कब उपयोग करें।
Salesforce के sharing model का अधिकांश हिस्सा सिर्फ एक्सेस खोलना जानता है। Restriction rules और scoping rules नए टूल हैं जो इसे बदलते हैं — लेकिन ये बहुत अलग-अलग काम करते हैं, और इन्हें आपस में गड़बड़ा देना आसान है। यहाँ बताया गया है कि तीनों आपस में कैसे जुड़ते हैं।
एक-पंक्ति का नक्शा
- Sharing rules — एक्सेस खोलते हैं। उन यूज़र को रिकॉर्ड देते हैं जो अन्यथा उन्हें नहीं देख पाते।
- Restriction rules — एक्सेस घटाते हैं। उन रिकॉर्ड को फ़िल्टर कर देते हैं जिन्हें यूज़र अन्यथा देखने की अनुमति रखता।
- Scoping rules — व्यू को फ़ोकस करते हैं। एक्सेस बदले बिना यह बदलते हैं कि डिफ़ॉल्ट रूप से कौन से रिकॉर्ड दिखें।
इनमें से दो सुरक्षा को प्रभावित करते हैं; एक नहीं करता। यही वह भेद है जिसे साफ़ रखना है।
Sharing rules: एक्सेस को खोलना
Sharing rules org-wide default के ऊपर बैठते हैं और ownership या criteria के आधार पर अतिरिक्त एक्सेस देते हैं। वे एक्सेस को केवल चौड़ा कर सकते हैं — कभी संकरा नहीं। ये hierarchy की तुलना में कैसे हैं, इसका दोहराव चाहिए तो देखें sharing rules बनाम role hierarchy।
यही जोड़ने वाला, सबसे-अधिक-अनुमति-जीतती-है व्यवहार है जो record access model के केंद्र में है।
Restriction rules: एक्सेस को नीचे घटाना
Restriction rules इस नियम का अपवाद हैं कि “Salesforce sharing सिर्फ एक्सेस खोलता है।” एक restriction rule यह परिभाषित करता है कि किसी यूज़र को कौन से रिकॉर्ड देखने की अनुमति है, और इसे sharing model द्वारा दी गई हर चीज़ के ऊपर लागू किया जाता है — प्रभावी रूप से परिणाम को फ़िल्टर करते हुए।
यदि org-wide default, role hierarchy और sharing rules मिलकर किसी यूज़र को 10,000 रिकॉर्ड दिखाते, तो एक restriction rule उसे संकरा करके केवल उन रिकॉर्ड तक सीमित कर सकता है जो उसके criteria से मेल खाते हैं।
उदाहरण. Support agents के पास एक sharing rule के ज़रिए Cases तक व्यापक एक्सेस है, लेकिन उनमें से contractors को केवल गैर-गोपनीय cases ही दिखने चाहिए। Case पर एक restriction rule — contractor permission set के लिए Confidential = false — गोपनीय cases को उनकी दृष्टि से हटा देता है, भले ही तकनीकी रूप से sharing ने उन्हें वह एक्सेस दे दिया हो।
जब सवाल यह हो कि “एक्सेस को कैसे छीनूँ”, तब यही वह टूल है जिसकी ओर हाथ बढ़ाना चाहिए।
Scoping rules: फ़ोकस, सुरक्षा नहीं
Scoping rules नियंत्रित करते हैं कि list views, searches और reports में डिफ़ॉल्ट रूप से कौन से रिकॉर्ड दिखें — owner, role या region जैसी शर्तों के आधार पर। सबसे अहम बात:
Scoping rules एक्सेस को सीमित नहीं करते। यूज़र scope को “वे सभी रिकॉर्ड जिन तक मेरी पहुँच है” पर स्विच कर सकता है और sharing द्वारा दी गई हर चीज़ देख सकता है।
ये एक प्रोडक्टिविटी फ़ीचर हैं: किसी व्यस्त rep को पहले उसका अपना region दिखाएँ, बिना उस पर ज़ोर डाले। यदि किसी यूज़र को रिकॉर्ड देखने से रोकना ही है, तो scoping rules गलत टूल हैं — restriction rules का उपयोग करें।
आमने-सामने
| Sharing rules | Restriction rules | Scoping rules | |
|---|---|---|---|
| एक्सेस पर असर | खोलता है | घटाता है | कोई नहीं |
| सुरक्षा नियंत्रण? | हाँ | हाँ | नहीं (सिर्फ फ़ोकस) |
| क्या यूज़र ओवरराइड कर सकता है? | नहीं | नहीं | हाँ (scope स्विच करके) |
| दिशा | एक्सेस जोड़ना | एक्सेस हटाना | डिफ़ॉल्ट व्यू फ़िल्टर करना |
| आम सीमा | अनेक | ~2 सक्रिय/object | ~2 सक्रिय/object |
इन्हें साथ मिलाकर उपयोग करना
एक वास्तविक object तीनों का उपयोग कर सकता है: एक Private OWD, टीमों को ज़रूरी एक्सेस देने के लिए sharing rules, contractors से एक संवेदनशील उपसमूह अलग निकालने के लिए एक restriction rule, और एक scoping rule ताकि हर यूज़र डिफ़ॉल्ट रूप से अपने ही region पर पहुँचे। हर एक एक ही काम करता है; मिलकर वे यह दोनों गढ़ते हैं कि यूज़र क्या देख सकते हैं और क्या पहले देखते हैं।
पेच: प्रभावी एक्सेस इन सबका योग है
खोलने-वाले, घटाने-वाले और फ़ोकस-करने-वाले टूल को परत-दर-परत लगाने से “यह यूज़र असल में क्या देख सकता है?” का जवाब केवल निरीक्षण से देना सचमुच कठिन हो जाता है — sharing द्वारा दिए गए एक्सेस में से restriction फ़िल्टर घटाएँ, scoping को नज़रअंदाज़ करते हुए। यही वह गणना है जो AgentForceAccess आपके लिए चलाता है: पूछिए कि कोई यूज़र वास्तव में क्या एक्सेस कर सकता है, और यह उस sharing का भी हिसाब रखता है जो एक्सेस देती है और उन restriction rules का भी जो उसे काटकर कम करते हैं — सब सरल भाषा में।
अक्सर पूछे जाने वाले सवाल
एक पंक्ति में क्या अंतर है?
Sharing rules यूज़र को वह एक्सेस देते हैं जो उसके पास नहीं था, restriction rules यूज़र से वह एक्सेस छीनते हैं जो उसके पास था, और scoping rules सिर्फ list views और searches को पहले से फ़िल्टर करते हैं, एक्सेस पर बिलकुल असर डाले बिना।
क्या restriction rule किसी sharing rule या role hierarchy को ओवरराइड कर सकता है?
हाँ। Restriction rules sharing model के ऊपर लागू होते हैं और यूज़र को दिखने वाले रिकॉर्ड फ़िल्टर करते हैं — वे रिकॉर्ड भी जिन्हें org-wide default, role hierarchy या sharing rules अन्यथा उजागर कर देते। Salesforce में एक्सेस को सचमुच घटाने का यही तरीका है।
क्या scoping rules सुरक्षा के लिए रिकॉर्ड छिपाते हैं?
नहीं। Scoping rules सिर्फ यह बदलते हैं कि list views, searches और reports में डिफ़ॉल्ट रूप से कौन से रिकॉर्ड दिखें। यूज़र scope को "वे सभी रिकॉर्ड जिन तक मेरी पहुँच है" पर स्विच कर सकता है, इसलिए ये फ़ोकस और प्रोडक्टिविटी के बारे में हैं, सुरक्षा के नहीं। जब एक्सेस को सचमुच सीमित करना ज़रूरी हो तो restriction rules का उपयोग करें।
क्या इन नियमों पर कोई सीमाएँ हैं?
हाँ। Restriction rules और scoping rules दोनों पर आमतौर पर प्रति object अधिकतम 2 सक्रिय नियमों की सीमा होती है, और ये custom objects के साथ-साथ Account, Case, Contact, Event, Lead, Opportunity और Task जैसे चुनिंदा standard objects के लिए उपलब्ध हैं। अपने edition की मौजूदा सीमाएँ ज़रूर जाँचें।
इसे अपने org पर देखें
AgentForceAccess सीधी भाषा में समझाता है कि कोई भी user किसी भी record या file को क्यों देख सकता है — हर Salesforce sharing तंत्र में।
जल्द access का अनुरोध करें