Salesforce में रिकॉर्ड कौन देख सकता है? एक्सेस कैसे तय होता है

अगर आप किसी Salesforce org को काफी समय तक एडमिनिस्टर करते हैं, तो आखिरकार कोई न कोई पूछेगा: “यह व्यक्ति वह रिकॉर्ड कैसे देख पा रहा है?” ईमानदार जवाब यह है कि Salesforce रिकॉर्ड की दृश्यता कभी एक ही जगह तय नहीं करता। यह कई तंत्रों को एक-दूसरे के ऊपर परत-दर-परत रखता है और उन सबका संघ (union) प्रदान करता है।

यह गाइड हर परत को उसी क्रम में समझाती है जिसमें Salesforce उसका मूल्यांकन करता है, ताकि आप “कौन क्या देख सकता है” वाले किसी भी सवाल को मूल सिद्धांतों से समझ सकें।

वह एक नियम जो सब कुछ समझा देता है

Salesforce sharing additive है और सबसे उदार वाला जीतता है। org-wide defaults द्वारा तय की गई आधार रेखा से शुरू करें, फिर बाकी हर तंत्र केवल उसके ऊपर एक्सेस जोड़ सकता है। मानक sharing model में कुछ भी एक्सेस छीनता नहीं है।

इसलिए जब आप यह पता लगा रहे हों कि कोई उपयोगकर्ता किसी रिकॉर्ड को क्यों देख पाता है, तो आप कभी भी उस नियम और उस नियम की तलाश नहीं कर रहे होते जो इसे अनुमति देता है बनाम जो इसे रोकता है। आप किसी एक भी ग्रांट की तलाश कर रहे होते हैं — क्योंकि एक ही काफी है।

अगर एक भी तंत्र एक्सेस देता है, तो उपयोगकर्ता के पास एक्सेस है। बस।

परत 1 — Object permissions यह तय करती हैं कि क्या, यह नहीं कि कौन-सा

Sharing पर विचार करने से पहले, उपयोगकर्ता को अपने profile या permission sets के ज़रिए object-level एक्सेस चाहिए:

• object पर Read / Create / Edit / Delete।
• object पर View All या Modify All, जो उस object के लिए sharing को पूरी तरह नज़रअंदाज़ कर देती हैं।

अगर किसी उपयोगकर्ता के पास Opportunities पर Read permission नहीं है, तो दुनिया का कोई भी sharing rule उसे कोई opportunity नहीं दिखाएगा। Object permissions एक द्वार हैं; sharing model वह है जो आपके उसमें से गुज़र जाने के बाद होता है।

परत 2 — Org-wide defaults न्यूनतम स्तर तय करते हैं

Org-wide defaults (OWD) हर object के लिए सबसे प्रतिबंधात्मक आधार रेखा परिभाषित करते हैं:

• Private — केवल रिकॉर्ड का स्वामी (और role hierarchy में उससे ऊपर के लोग) इसे देख सकते हैं।
• Public Read Only — हर कोई देख सकता है, केवल स्वामी संपादित कर सकता है।
• Public Read/Write — हर कोई देख और संपादित कर सकता है।

इसके बाद आने वाली हर चीज़ का उद्देश्य विशिष्ट लोगों के लिए इस न्यूनतम स्तर से ऊपर एक्सेस बढ़ाना है।

परत 3 — Role hierarchy एक्सेस को ऊपर की ओर बढ़ाती है

अगर object के लिए Grant Access Using Hierarchies सक्षम है, तो role hierarchy में रिकॉर्ड के स्वामी से ऊपर का कोई भी व्यक्ति स्वामी का एक्सेस विरासत में पा लेता है। यही कारण है कि एक sales manager बिना किसी स्पष्ट नियम के अपने reps के deals देख लेता है — और यह अप्रत्याशित एक्सेस का सबसे आम एकल कारण है।

परत 4 — Sharing rules एक्सेस को बग़ल में खोलती हैं

Sharing rules एक्सेस को hierarchy के आर-पार, साथियों और अन्य शाखाओं तक बढ़ाती हैं:

• Ownership-based — उपयोगकर्ताओं के एक समूह के स्वामित्व वाले रिकॉर्ड्स को दूसरे समूह के साथ शेयर करना।
• Criteria-based — फ़ील्ड मानों से मेल खाने वाले रिकॉर्ड्स (जैसे Region = EMEA) को किसी group, role, या territory के साथ शेयर करना।

दोनों एक साथ उपयोगकर्ताओं के एक समूह को एक्सेस देती हैं, जिससे कोई बहुत व्यापक criteria-based नियम अक्सर तब अपराधी बन जाता है जब “बहुत अधिक” लोग कुछ देख पाते हैं।

परत 5 — Manual और implicit shares

• Manual sharing — रिकॉर्ड पर मौजूद Share बटन, जो किसी एक विशिष्ट उपयोगकर्ता या समूह को उस एक रिकॉर्ड का एक्सेस देता है।
• Implicit sharing — अंतर्निहित व्यवहार, जैसे किसी parent account का एक्सेस उसके child cases और contacts तक सीमित एक्सेस का संकेत देना।
• Apex managed sharing — कस्टम कोड द्वारा बनाए गए प्रोग्रामेटिक shares, जिन्हें पहचानना अक्सर सबसे कठिन होता है।

परत 6 — Teams और territories

• Account, Opportunity और Case teams सूचीबद्ध team members को उस रिकॉर्ड का एक्सेस देती हैं।
• Enterprise Territory Management उन territories के आधार पर एक्सेस देती है जिनसे कोई उपयोगकर्ता और कोई रिकॉर्ड संबंधित होते हैं।

सब कुछ जोड़ना: किसी भी एक्सेस का पता कैसे लगाएं

“यह उपयोगकर्ता यह रिकॉर्ड क्यों देख सकता है” का जवाब देने के लिए, हर परत की तब तक जाँच करें जब तक आपको कोई ग्रांट न मिल जाए:

1. क्या उपयोगकर्ता के पास profile/permission set के ज़रिए object Read (या View All) है?
2. क्या इस object के लिए OWD पहले से ही public है?
3. क्या वे role hierarchy में स्वामी से ऊपर हैं?
4. क्या कोई sharing rule उन्हें शामिल करता है?
5. क्या कोई manual, implicit, या Apex share मौजूद है?
6. क्या वे किसी team में हैं, या किसी मेल खाते territory में?

पहला “हाँ” ही आपका जवाब है — और याद रखें कि एक से अधिक भी हो सकते हैं। इस ट्रेस के चरण-दर-चरण संस्करण के लिए, देखें कोई उपयोगकर्ता ऐसा रिकॉर्ड देख पाता है जो उसे नहीं देखना चाहिए; वही मॉडल कौन कोई फ़ाइल देख सकता है को भी नियंत्रित करता है, क्योंकि फ़ाइलें रिकॉर्ड एक्सेस विरासत में पाती हैं।

यही वह काम है जिसे AgentForceAccess स्वचालित करता है: सीधे-सादे शब्दों में पूछें कि कोई उपयोगकर्ता किसी रिकॉर्ड को क्यों देख सकता है, और यह ऊपर की हर परत का पता लगाता है और उस सटीक ग्रांट का हवाला देता है जो इसकी अनुमति देता है।

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

क्या System Administrator sharing model को बायपास कर देता है?

हाँ। "View All Data" और "Modify All Data" permissions — जो डिफ़ॉल्ट रूप से System Administrator profile को मिलती हैं — org-wide defaults, sharing rules और role hierarchy को पूरी तरह बायपास कर देती हैं। Object-level "View All" / "Modify All" किसी एक object के लिए वही करती हैं।

अगर एक ही रिकॉर्ड पर दो sharing rules लागू होती हैं, तो कौन-सी जीतती है?

सबसे उदार वाली। Salesforce एक्सेस additive है: यह हर लागू नियम का संघ (union) देता है। कोई नया नियम जोड़ने से एक्सेस कभी घट नहीं सकता — केवल बढ़ सकता है।

कोई मैनेजर ऐसे रिकॉर्ड क्यों देख पाता है जो उसे कभी स्पष्ट रूप से दिए ही नहीं गए?

Role hierarchy मैनेजरों को उन रिकॉर्ड्स तक एक्सेस देती है जो उनके नीचे के उपयोगकर्ताओं के स्वामित्व में हैं (या उनके साथ शेयर हैं), बशर्ते उस object के लिए "Grant Access Using Hierarchies" सक्षम हो।

क्या object permissions और sharing settings एक ही काम करती हैं?

नहीं। Object permissions (profiles और permission sets पर) यह तय करती हैं कि उपयोगकर्ता किसी object को बिल्कुल भी एक्सेस कर सकता है या नहीं और उसके साथ क्या कर सकता है। Sharing model यह तय करता है कि उस object के कौन-से विशिष्ट रिकॉर्ड वह देख सकता है।