Sharing rulesRole hierarchySalesforce admin

Salesforce में sharing rules बनाम role hierarchy: मुख्य अंतर

Role hierarchy org chart में ऊपर की ओर अपने-आप एक्सेस देती है; sharing rules criteria या ownership से एक्सेस को बग़ल में फैलाती हैं। उदाहरण सहित।

AgentForceAccess 3 मिनट पढ़ें
एक खड़ा role-hierarchy पिरामिड, उसके बग़ल में peer-to-peer sharing दर्शाते क्षैतिज तीर

Role hierarchy और sharing rules वे दो तंत्र हैं जिनका सहारा admins सबसे ज़्यादा लेते हैं — और जिन्हें सबसे ज़्यादा गड़बड़ाया भी जाता है। दोनों ही रिकॉर्ड एक्सेस को चौड़ा करते हैं, लेकिन अलग-अलग दिशाओं में और अलग-अलग कारणों से। इस अंतर को सही समझ लेना ही एक साफ़-सुथरे sharing model और आपस में उलझे नियमों के जाल के बीच का फ़र्क़ है।

एक-पंक्ति का अंतर

  • Role hierarchy — एक्सेस अपने-आप और ऊर्ध्वाधर रूप से देती है: org chart में रिकॉर्ड owner के ऊपर मौजूद हर व्यक्ति को owner का एक्सेस विरासत में मिल जाता है।
  • Sharing rules — एक्सेस सोच-समझकर और क्षैतिज रूप से देती हैं: peers, दूसरी टीमों या ऐसे groups को जिन्हें hierarchy कभी नहीं जोड़ती, ownership या field criteria के आधार पर।

दोनों ही org-wide default के ऊपर बैठती हैं और एक्सेस को सिर्फ़ खोल सकती हैं, कभी सीमित नहीं कर सकतीं। (पूरी परत-दर-परत संरचना किसी रिकॉर्ड को कौन देख सकता है में देखें।)

Role hierarchy: एक्सेस ऊपर की ओर चढ़ता है

जब किसी object के लिए Grant Access Using Hierarchies चालू होता है, तो मैनेजर को अपने नीचे के यूज़र्स के owned — या उनके साथ शेयर किए गए — रिकॉर्ड्स का एक्सेस अपने-आप विरासत में मिल जाता है। न कोई नियम, न प्रति-रिकॉर्ड कोई कॉन्फ़िगरेशन।

उदाहरण। Opportunities पर Private org-wide default है। एक rep के पास एक deal है। उनका मैनेजर, और मैनेजर का VP, उसे अपने-आप देख सकते हैं क्योंकि वे hierarchy में rep के ऊपर बैठते हैं। यही role hierarchy अपना काम कर रही है।

यह मैनेजर-अपनी-टीम-देखे वाली दृश्यता के लिए एकदम सही है, और साथ ही “इन्हें यह दिख कैसे रहा है?” वाले आश्चर्यों का सबसे आम स्रोत भी — क्योंकि किसी ने इसे प्रति-रिकॉर्ड कॉन्फ़िगर नहीं किया।

Sharing rules: एक्सेस बग़ल में खुलता है

Sharing rules एक्सेस को hierarchy के आर-पार फैलाती हैं, उन यूज़र्स तक जिन्हें org chart अलग रखता है। दो प्रकार हैं:

  • Ownership-based — एक group (role, public group, territory) के owned रिकॉर्ड्स को दूसरे group के साथ शेयर करें।
  • Criteria-based — ऐसे रिकॉर्ड्स जो field values से मेल खाते हों (जैसे Region = EMEA) किसी group, role या territory के साथ शेयर करें।

उदाहरण। EMEA और APAC sales, hierarchy की अलग-अलग शाखाएँ हैं, इसलिए कोई भी दूसरे की deals नहीं देखता। एक criteria-based नियम — Region = EMEA → Read एक्सेस APAC Leadership group के साथ शेयर करें — hierarchy को छुए बिना ठीक वही cross-branch एक्सेस खोल देता है।

कब किसका इस्तेमाल करें

ज़रूरतइस्तेमाल करें
मैनेजर अपनी टीम के रिकॉर्ड्स देखेंRole hierarchy
एक्सेस अपने-आप reporting lines का अनुसरण करेRole hierarchy
दो peer टीमों को एक-दूसरे के रिकॉर्ड्स देखने होंSharing rule (ownership-based)
field criteria (region, type, stage) से मेल खाते रिकॉर्ड्स शेयर करेंSharing rule (criteria-based)
किसी public group या territory के साथ शेयर करेंSharing rule
किसी एक रिकॉर्ड का एक-बार का एक्सेसManual share (इनमें से कोई नहीं)

ये जमा होती हैं — और यही पेच है

चूँकि एक्सेस additive है और सबसे उदार नियम जीतता है, role hierarchy और sharing rules आपस में मिल जाती हैं। एक यूज़र को एक ही रिकॉर्ड का एक्सेस hierarchy के ज़रिए और एक साथ दो sharing rules के ज़रिए भी मिल सकता है। इनमें से कोई दूसरों को रद्द नहीं करता; कोई एक भी अकेले काफ़ी है।

इसीलिए हद से ज़्यादा खुला sharing चुपके से घुस आता है: हर नियम अकेले में सही लगता है, पर hierarchy + नियमों + manual shares का जो योग है, वही असल में किसी यूज़र को दिखता है — और वह पूरी तस्वीर किसी के दिमाग़ में पूरी नहीं रहती।

कोई भी सीमित नहीं करती — सोच-समझकर बनाई गई

अगर आपको एक्सेस घटाना है, तो sharing rules और role hierarchy मदद नहीं कर सकतीं। org-wide default कसें, या restriction rules इस्तेमाल करें। एक और sharing rule जोड़ने से तो एक्सेस और ज़्यादा ही खुलेगा।

संयुक्त असर को देखना

मुश्किल हिस्सा इनमें से कोई एक तंत्र नहीं है — बल्कि उनका योग है। यह जानने के लिए कि कोई यूज़र किसी रिकॉर्ड को क्यों देखता है, आपको hierarchy और हर लागू sharing rule और manual shares — सबको एक साथ आँकना पड़ता है।

AgentForceAccess यह योग आपके लिए निकाल देता है: पूछिए कि कोई यूज़र किसी रिकॉर्ड को क्यों देख सकता है, और यह आपको बता देगा कि वजह role hierarchy है, कोई ख़ास sharing rule, या दोनों — साफ़ भाषा में, उस तंत्र का हवाला देते हुए।

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

एक वाक्य में मूल अंतर क्या है?

Role hierarchy reporting lines के साथ ऊपर की ओर और अपने-आप एक्सेस खोलती है, जबकि sharing rules बग़ल में और जान-बूझकर एक्सेस खोलती हैं — उन यूज़र्स तक जिन्हें कोई hierarchy कभी जोड़ती ही नहीं।

अगर दोनों एक ही रिकॉर्ड का एक्सेस दे सकें, तो कौन जीतता है?

इससे कोई फ़र्क़ नहीं पड़ता — Salesforce में एक्सेस additive है और सबसे उदार नियम जीतता है। चाहे role hierarchy एक्सेस दे या sharing rule, यूज़र को एक्सेस मिल जाता है। दोनों के "सहमत" होने की कभी ज़रूरत नहीं।

क्या कोई sharing rule एक्सेस छीन सकती है?

नहीं। Sharing rules और role hierarchy सिर्फ़ org-wide default से ऊपर एक्सेस बढ़ा सकती हैं। एक्सेस घटाने के लिए आप org-wide default बदलते हैं, या restriction rules इस्तेमाल करते हैं — sharing rules नहीं।

अगर मेरी role hierarchy अच्छी तरह बनी है, तो क्या मुझे फिर भी sharing rules चाहिए?

आम तौर पर हाँ। एक hierarchy सिर्फ़ ऊर्ध्वाधर, मैनेजर-के-ऊपर-रिपोर्ट वाला एक्सेस व्यक्त करती है। जैसे ही दो peer टीमों को, या किसी दूसरी शाखा की role को, एक-दूसरे के रिकॉर्ड्स देखने हों, उसे सिर्फ़ कोई sharing rule ही व्यक्त कर सकती है।

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

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

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