संबंधों के नतीजे होते हैं

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 7 (कुल 10 में से) — अध्याय Salesforce डेटा आर्किटेक्चर, Data Architect कोर्स का अध्याय 3। हर मॉड्यूल अपने आप में पूरा है। पिछला: फ़ील्ड भी आर्किटेक्चर हैं · अगला: स्वामित्व और जीवनचक्र

यह मॉड्यूल किस सवाल का जवाब देता है: जब मैं दो Salesforce ऑब्जेक्ट को जोड़ता हूँ, तो असल में मैं क्या चुन रहा होता हूँ?

संबंध बनाना आसान है। अध्याय 2 में हमने लकीरें खींचीं और उन्हें नाम दिए: एक रिटेल पार्टनर कई मैनिफ़ेस्ट भेजता है, एक डिलीवरी में कई आइटम होते हैं, क्रू और ट्रक एक क्रू असाइनमेंट (Crew Assignment) में मिलते हैं। हमने cardinality, optionality और इतिहास की बात की। अब हम उन लकीरों को Salesforce पर लागू करते हैं, और डायग्राम पर एक लकीर कहीं ज़्यादा वज़न उठाने लगती है।

जब मैं Salesforce पर कोई संबंध टाइप चुनता हूँ, तो मैं सिर्फ़ यह नहीं कह रहा होता कि ये दो रिकॉर्ड जुड़े हुए हैं। हो सकता है मैं यह भी तय कर रहा हूँ कि child का मालिक कौन है, क्या वह parent के बिना रह सकता है, उसे कौन देख सकता है, parent डिलीट होने पर क्या होता है, क्या वह किसी दूसरे parent के पास जा सकता है, क्या मैं उसका सारांश parent पर निकाल सकता हूँ, और जब लाखों children हों तब क्या होता है। संबंध सिर्फ़ एक लकीर नहीं है। वह व्यवहार साथ लाता है।

बिज़नेस के रिश्ते से शुरू करें

lookup या master-detail से पहले, बिज़नेस पर वापस जाएँ। एक डिलीवरी और उसके डिलीवरी आइटम लें, फ़्रिज, इंस्टॉलेशन, पुराना सामान उठाना। क्या कोई आइटम अपनी डिलीवरी के बिना रह सकता है? नहीं। अगर डिलीवरी डिलीट हो जाए, तो क्या उसके आइटम भी जाने चाहिए? हाँ। क्या आइटम को अपना मालिक या अपनी सिक्योरिटी चाहिए? असल में नहीं। क्या कोई एक आइटम को एक डिलीवरी से दूसरी में ले जाए? उम्मीद है, गलती से तो नहीं।

अब एक डिलीवरी और वह रूट लें जिस पर वह है। डिलीवरी रूट बनने से पहले मौजूद होती है, योजना बदलने पर उसे दूसरे रूट पर ले जाया जा सकता है, और किसी रूट को डिलीट करने से उस पर की डिलीवरी कभी डिलीट नहीं होनी चाहिए। दो one-to-many लकीरें जो डायग्राम पर एक जैसी दिखती हैं, बिल्कुल अलग व्यवहार के साथ। ध्यान दें, हमने अब तक “lookup” या “master-detail” नहीं कहा है। पहले व्यवहार बताएँ। कॉन्फ़िगरेशन उसे लागू करता है।

संबंधों के टाइप

New Field स्क्रीन खोलें और Salesforce आपको कुछ संबंध टाइप देता है (Object Relationships Overview (opens in a new tab)):

• Lookup: दो ऑब्जेक्ट को जोड़ता है। Salesforce संबंधों की दाल-रोटी।
• Master-detail: parent-child का ऐसा बंधन जिसमें parent, child को नियंत्रित करता है।
• Many-to-many: अपने आप में कोई फ़ील्ड टाइप नहीं, बल्कि एक pattern: एक Salesforce Junction Object, दो master-details वाला एक कस्टम ऑब्जेक्ट।
• Self-relationship: किसी ऑब्जेक्ट से खुद तक का lookup।
• Hierarchical: एक खास lookup जो सिर्फ़ User ऑब्जेक्ट पर होता है, जैसे किसी यूज़र का मैनेजर।
• External lookup और indirect lookup: एक्सटर्नल ऑब्जेक्ट तक और उनसे आने वाले संबंध, यानी मॉड्यूल 4 वाले __x ऑब्जेक्ट। external lookup किसी parent एक्सटर्नल ऑब्जेक्ट की ओर इशारा करता है; indirect lookup किसी एक्सटर्नल ऑब्जेक्ट से किसी स्टैंडर्ड या कस्टम ऑब्जेक्ट की ओर इशारा करता है, एक यूनिक External ID पर मिलान करके।

आपके डिज़ाइन का ज़्यादातर समय पहले तीन पर जाता है। चलिए एक-एक करके लेते हैं।

Lookup: ये रिकॉर्ड जुड़े हुए हैं

lookup कहता है: यह रिकॉर्ड उस रिकॉर्ड से जुड़ा है। child अपना अलग अस्तित्व, अपना मालिक और अपना जीवन रखता है। एक डिलीवरी अपने रूट की ओर इशारा करती है। अगर रूट रद्द हो जाए, तो डिलीवरी गायब नहीं होतीं; वे फिर से रूट होने के लिए वापस चली जाती हैं।

मज़ेदार बात है: lookup फ़ील्ड child पर जाता है, लेकिन parent को भी कुछ मिलता है, उसके children की एक related list। इसलिए जब आप एक बनाएँ, तो दोनों सिरों को नाम दें। Related List Label वह है जो लोग parent पर देखते हैं, और Child Relationship Name वह है जिसे डेवलपर और इंटीग्रेशन parent से children तक जाने के लिए इस्तेमाल करते हैं। डिफ़ॉल्ट को यूँ ही न मान लें।

lookup अनिवार्य या वैकल्पिक हो सकता है। जब यह वैकल्पिक हो, तो आप तय करते हैं कि जिस रिकॉर्ड की ओर यह इशारा करता है, उसके डिलीट होने पर क्या होगा, और तीन विकल्प हैं (Considerations for Object Relationships (opens in a new tab)):

• Clear the value of this field (इस फ़ील्ड का मान खाली करें), डिफ़ॉल्ट। child बना रहता है, खाली lookup के साथ।
• Don’t allow deletion (डिलीट न होने दें), lookup वाले रिकॉर्ड को। रूट डिलीट करने की कोशिश करें, और Salesforce मना कर देता है: यह एक संबंध का हिस्सा है।
• Delete this record also (इस रिकॉर्ड को भी डिलीट करें), एक कैस्केड डिलीट, master-detail की तरह। यह सिर्फ़ कस्टम ऑब्जेक्ट पर कस्टम lookup के लिए मिलता है, यह डिफ़ॉल्ट रूप से बंद है, और Salesforce को इसे आपके org के लिए चालू करना पड़ता है, क्योंकि कैस्केड डिलीट सिक्योरिटी और शेयरिंग को दरकिनार कर देता है: यूज़र ऐसे रिकॉर्ड डिलीट कर सकते हैं जिन्हें वे देख तक नहीं सकते थे।

यह एक setup स्क्रीन में छिपा जीवनचक्र का निर्णय है।

Lookup filters सीमित करते हैं कि यूज़र क्या चुन सकता है। मान लीजिए Delivery पर Contact की ओर एक Installer lookup है, और installer कई तरह के contacts में से एक रिकॉर्ड टाइप हैं। एक lookup filter सिर्फ़ installers दिखाता है, और यह मौजूदा रिकॉर्ड पर, जिस रिकॉर्ड को देखा जा रहा है उस पर, और यूज़र पर फ़िल्टर कर सकता है: उसकी प्रोफ़ाइल, रोल या permissions (Lookup Filters (opens in a new tab))। lookup को ईमानदार रखने का यह एक सस्ता तरीका है।

Master-Detail: यह child उस parent का है

Master-detail कहीं ज़्यादा मज़बूत बयान देता है। क्लास में मैं इसे बहुत कसा हुआ बंधन कहता हूँ। आप master के बिना detail नहीं रख सकते; master फ़ील्ड अनिवार्य है। detail अपना Owner फ़ील्ड खो देता है और अपने parent का मालिक विरासत में पाता है। detail के लिए अलग share table नहीं होती, इसलिए आप किसी child को अकेले शेयर नहीं कर सकते; वह अपने parent की शेयरिंग विरासत में पाता है। इसीलिए किसी detail ऑब्जेक्ट पर शेयरिंग रूल, manual sharing या queues नहीं हो सकते: इन सबको एक Owner फ़ील्ड चाहिए (Object Relationships Overview (opens in a new tab))। Setup में इसकी शेयरिंग सेटिंग Controlled by Parent दिखती है। और master-detail फ़ील्ड पर ही आप एक Sharing Setting चुनते हैं: किसी यूज़र को उसके details बनाने, एडिट करने या डिलीट करने के लिए master पर Read Only access चाहिए या Read/Write। master को डिलीट करने से उसके details डिलीट हो जाते हैं। और master को roll-up summary फ़ील्ड मिलते हैं।

तो अगर डिलीवरी आइटम, डिलीवरी का detail है, तो मैं कह रहा हूँ: यह आइटम अपने पूरे जीवन इस डिलीवरी का है। यही वह सवाल है जिसका जवाब मैं चाहता हूँ, इससे पहले कि कोई Setup में Master-Detail Relationship चुने।

डिलीट का सवाल

यह पता लगाने का मेरा पसंदीदा तरीका कि हमने पूरी बात सोची है या नहीं: अगर कोई parent को डिलीट कर दे, तो children का क्या होना चाहिए? हर कोई असहज हो जाता है। अच्छा है। अब हम आर्किटेक्चर कर रहे हैं।

एक रिटेल पार्टनर की लाखों पुरानी डिलीवरी हैं। कोई पार्टनर को डिलीट कर देता है। क्या डिलीवरी गायब हो जानी चाहिए? लगभग पक्का नहीं: क्लेम, बिलिंग और इतिहास सब उन पर निर्भर हैं। शायद पार्टनर को डिलीट करने की इजाज़त ही नहीं होनी चाहिए, और पार्टनर को इसके बजाय निष्क्रिय (deactivate) किया जाना चाहिए। master-detail के साथ, master को डिलीट करना details और उनके details तक कैस्केड होता है; master को undelete करने से वे वापस आ जाते हैं (Considerations for Object Relationships (opens in a new tab))। इसलिए जब कोई कहता है “master-detail से हमें roll-ups मिलते हैं,” तो मेरा जवाब है: बढ़िया। और आप किस-किस बात पर अभी-अभी राज़ी हो गए?

स्वामित्व भी साथ चला आता है

lookup के साथ, child का अपना मालिक हो सकता है। master-detail के साथ, नहीं हो सकता; access master के पीछे चलता है। अगर detail सच में parent का हिस्सा है, तो यह बिल्कुल सही है। लेकिन अगर child को अपना मालिक, अपनी शेयरिंग या अपना जीवनचक्र चाहिए, तो मॉडल आपसे कह रहा है कि master-detail गलत चुनाव है। अगला मॉड्यूल स्वामित्व में और गहराई तक जाता है, और Sharing and Visibility कोर्स उससे भी आगे। अभी के लिए: संबंधों का डिज़ाइन और सिक्योरिटी का डिज़ाइन अलग-अलग बातचीत नहीं हैं। किसी के शेयरिंग रूल लिखने से पहले ही डेटा मॉडल सिक्योरिटी मॉडल को आकार दे देता है।

Parent अनिवार्य, या वैकल्पिक?

क्या child अपने parent के पता चलने से पहले मौजूद हो सकता है? यह जितना लगता है, उससे ज़्यादा मायने रखता है। अगर डिलीवरी एक रात पहले मैनिफ़ेस्ट पर आती हैं और रूट बाद में बनते हैं, तो Delivery पर अनिवार्य Route का मतलब होगा कि रिकॉर्ड बन भी सके, उससे पहले रूटिंग हो जानी चाहिए। भौतिक संबंध को असली जीवनचक्र का साथ देना होगा। इसलिए मैं संबंध सिर्फ़ एक स्थिर डायग्राम से डिज़ाइन नहीं करता। मैं जानना चाहता हूँ: वे पैदा कैसे होते हैं, क्या वे अकेले रह सकते हैं, क्या वे जगह बदल सकते हैं, और वे खत्म कैसे होते हैं?

क्या child अपना parent बदल सकता है?

डिफ़ॉल्ट रूप से, master-detail के child को दूसरे parent के पास नहीं ले जाया जा सकता। आप इसकी इजाज़त दे सकते हैं, संबंध पर Allow reparenting चुनकर (Considerations for Object Relationships (opens in a new tab))। मेरी सहज प्रवृत्ति रूढ़िवादी है: अगर बिज़नेस कहता है कि child जीवन भर एक ही parent का है, तो मैं उसे हटाना आसान नहीं बनाता। किसी आइटम का एक डिलीवरी से दूसरी में जाना एक सोची-समझी बिज़नेस घटना होनी चाहिए, किसी फ़ील्ड का एडिट नहीं। फिर से, सेटिंग आर्किटेक्चर नहीं है। जीवनचक्र का नियम आर्किटेक्चर है, और सेटिंग उसे लागू करती है।

दो और बातें जो टीमों को बाद में पकड़ती हैं। आप ऐसे ऑब्जेक्ट पर master-detail संबंध नहीं बना सकते जिसमें पहले से डेटा हो; आप एक lookup बनाते हैं, हर रिकॉर्ड पर उसे भरते हैं, फिर उसे convert करते हैं। और आप वापस lookup में तभी convert कर सकते हैं जब master पर कोई roll-up summary फ़ील्ड न हो। यह भी देखें कि convert करने से सिक्योरिटी पर क्या असर होता है: lookup को master-detail में बदलने से child की शेयरिंग Controlled by Parent हो जाती है, और master-detail को वापस lookup में बदलने से child का organization-wide default Public Read/Write हो जाता है (Considerations for Object Relationships (opens in a new tab))। जो रिकॉर्ड कल private थे, वे आज खुले हैं, जब तक किसी का ध्यान न जाए। जल्दी चुनें।

Roll-ups उपयोगी हैं, लेकिन मुफ़्त नहीं

मुझे roll-ups पसंद हैं। किसी डिलीवरी के आइटम गिनें, किसी इनवॉइस की लाइनों की रकम जोड़ें, सबसे ताज़ा तारीख ढूँढें: बिल्ट-इन, बिना कोड के। master-detail फ़ील्ड child पर जाता है, लेकिन roll-up parent पर जाता है। फिर भी, इनके साथ बारीक शर्तें आती हैं (Roll-Up Summary Field (opens in a new tab)):

• कुछ बदलावों के बाद (एक नया roll-up फ़ील्ड, उसका आधार बना कोई formula बदल जाना, ज़बरदस्ती दोबारा कैलकुलेशन) roll-up मान कैलकुलेट होने में 30 मिनट तक लग सकते हैं, इस पर निर्भर करते हुए कि कितने रिकॉर्ड प्रभावित हैं। मैंने लोगों को हैरान होते देखा है कि parent पर नंबर अभी तक क्यों नहीं बदला।
• ये हर चीज़ का सारांश नहीं निकाल सकते। auto number वह फ़ील्ड नहीं हो सकता जिसे आप aggregate करें। और roll-up किसी formula फ़ील्ड का सारांश तभी निकाल सकता है जब वह formula किसी दूसरे ऑब्जेक्ट तक न पहुँचता हो और ऐसा function इस्तेमाल न करता हो जो अपने-आप बदलता है, जैसे NOW() या TODAY()। TODAY() पर बना “कितने दिन देरी” वाला formula हर रात बदल जाता है, बिना किसी के रिकॉर्ड सेव किए, इसलिए roll-up के पास दोबारा कैलकुलेट करने का कोई आधार नहीं होता। ऐसे नंबर के लिए एक scheduled flow, या एक रिपोर्ट चाहिए।
• फ़िल्टर की भी सीमाएँ हैं: long text area, multi-select पिकलिस्ट, Description, Last Activity जैसे सिस्टम फ़ील्ड, cross-object formulas या lookup फ़ील्ड नहीं।
• Roll-ups एडिट पेज पर नहीं होते, इसलिए कोई वैलिडेशन रूल उन्हें इस्तेमाल तो कर सकता है, लेकिन अपनी error वहाँ नहीं दिखा सकता।

और निर्णय को उलटा न करें। यह न कहें, “हमें roll-up चाहिए, इसलिए यह master-detail होना चाहिए।” यह कहें, “यह child सच में इस parent का है, स्वामित्व और जीवनचक्र फ़िट बैठते हैं, और इसके फ़ायदों में से एक है बिल्ट-इन roll-ups।” अगर अर्थ फ़िट नहीं बैठता, तो कैलकुलेशन किसी और तरीके से हल करें। किसी फ़ीचर को पाने के लिए डेटा मॉडल को तोड़-मरोड़ न करें।

तो दूसरा तरीका क्या है? आप roll-up खुद बनाते हैं: parent पर एक फ़ील्ड जो कैलकुलेट किया गया मान रखता है, और ऑटोमेशन जो उसे ताज़ा रखता है। मान लीजिए रिटेल पार्टनर, Delivery से एक lookup है, जैसा होना चाहिए, और बिज़नेस को पार्टनर पर Open Deliveries चाहिए। पार्टनर पर Open Deliveries नाम का एक number फ़ील्ड जोड़ें। फिर एक record-triggered flow, या जब मात्रा या लॉजिक कोड माँगे तो एक Apex trigger, किसी डिलीवरी के बदलने पर हर बार उसे दोबारा कैलकुलेट करता है। यह lookup पर काम करता है, किसी भी चीज़ पर फ़िल्टर कर सकता है, और ऐसी तारीखें और formulas इस्तेमाल कर सकता है जो बिल्ट-इन roll-up नहीं कर सकता।

लेकिन अब इसे सही रखना आपकी ज़िम्मेदारी है, और यहीं ये गड़बड़ाते हैं। ऑटोमेशन को हर उस बदलाव पर चलना होगा जो मायने रखता है: नया child, एडिट हुआ child, डिलीट हुआ child, undelete हुआ child, और दूसरे parent के पास ले जाया गया child, जिसका मतलब है पुराने और नए दोनों parent को दोबारा कैलकुलेट करना। इसे एक बार में 200 रिकॉर्ड का डेटा लोड बिना सीमाओं से टकराए संभालना होगा। जोड़-घटाव के बजाय दोबारा गिनें, ताकि एक छूटी घटना नंबर को हमेशा के लिए गलत न छोड़ दे। सब कुछ दोबारा कैलकुलेट करने का एक तरीका सोचकर रखें, पहले लोड के लिए और उस दिन के लिए जब नंबर भटक जाए। और याद रखें कि अब हर child का सेव parent को अपडेट करता है, इसलिए हज़ारों children वाला parent वही locking वापस ले आता है जो हम थोड़ी देर में देखेंगे। बिल्ट-इन roll-up आपके लिए यह सब करता है; कस्टम roll-up सॉफ़्टवेयर का एक छोटा टुकड़ा है जिसके मालिक आप हैं।

तीन स्तर गहरे: master-details की परतें

प्लेटफ़ॉर्म का एक आकार होता है, और master-detail में उसके दो आयाम हैं। पहला है गहराई।

आप master-details को तीन कस्टम detail स्तर गहराई तक एक के नीचे एक रख सकते हैं, और वही तल है (Considerations for Object Relationships (opens in a new tab))। क्लास में मैं इसे ऐसे बनाता हूँ: एक account और उसका एक order (एक), order और उसके आइटम (दो), और आइटम और उनके details (तीन), और फिर मैं चौथा जोड़ने की कोशिश करता हूँ और Salesforce मुझे नहीं जोड़ने देता। Steve Trucking पर यह कुछ ऐसा दिख सकता है: एक Delivery master है; उसके Delivery Items पहला स्तर हैं; किसी आइटम के Install Tasks दूसरा; और हर task के Task Steps तीसरा। चौथा स्तर, मान लीजिए Step Note, एक lookup ही होना चाहिए।

Click to enlarge

इन परतों के साथ कुछ नियम आते हैं:

• स्टैंडर्ड ऑब्जेक्ट किसी कस्टम ऑब्जेक्ट के detail हिस्से पर नहीं हो सकते। एक कस्टम ऑब्जेक्ट, Account का detail हो सकता है; Account आपके ऑब्जेक्ट का detail नहीं हो सकता।
• एक ऑब्जेक्ट बहु-स्तरीय परतों में सिर्फ़ एक बार आ सकता है। Salesforce नहीं चाहता कि आप घूमकर खुद पर वापस आएँ: कोई subdetail अपने ही master का master नहीं हो सकता।
• Master सबसे निचले स्तर का roll-up सीधे नहीं कर सकता। अगर Delivery को Task Steps की संख्या चाहिए, तो Install Task अपने steps को roll up करता है, Delivery Item उन roll-ups को roll up करता है, और Delivery आइटम को roll up करता है: एक बार में एक स्तर।
• स्वामित्व और शेयरिंग ऊपर से आते हैं। हर स्तर master का मालिक और access विरासत में पाता है।
• Master को डिलीट करने से उसके नीचे की हर चीज़ डिलीट हो जाती है, और उसे undelete करने से सब कुछ वापस आ जाता है।

तीन स्तर आमतौर पर काफ़ी होते हैं। अगर आपका डिज़ाइन बार-बार चौथा माँगता है, तो पूछें कि क्या हर स्तर सच में जीवन भर अपने ऊपर वाले का है। और याद रखें कि कौन-सी कड़ी chain तोड़ेगी, यह आप चुनते हैं। चौथे स्तर का lookup होना ज़रूरी नहीं: शायद एक Install Task सच में अपने Delivery Item का नहीं है, वह अलग से शेड्यूल और असाइन होता है, तो वह कड़ी lookup बन जाती है, और अब Install Task एक नई chain शुरू करता है, जिसके नीचे Task Step और Step Note हैं। वह कड़ी चुनें जहाँ child का सच में अपना जीवन है, और उसी को lookup बनाएँ।

Click to enlarge

अब Install Task का अपना मालिक और अपनी शेयरिंग है, किसी डिलीवरी को उसके install tasks साथ ले जाए बिना डिलीट किया जा सकता है, और Install Task के नीचे दो और स्तर हो सकते हैं। यही सौदा है: chain छोटी है, और install task का जीवन उसका अपना है।

दो parent चौड़ा: Salesforce Junction Object

पहले, शब्दों के बारे में एक बात, क्योंकि “junction object” के दो मतलब हैं, और मैं दोनों पढ़ाता हूँ।

अध्याय 2 में हमने तार्किक जंक्शन ऑब्जेक्ट पाया था: दो मुख्य विचारों का जंक्शन जो अपने आप में एक चीज़ बन जाता है, अपने एट्रिब्यूट के साथ। एक कुत्ता कई करतब जानता है, एक करतब कई कुत्ते जानते हैं, और कुत्ते का करतब उनके बीच बैठकर कौशल-स्तर और तारीख रखता है। यह एक तार्किक जंक्शन ऑब्जेक्ट है, लॉजिकल मॉडल में, किसी के lookup या master-detail तय करने से बहुत पहले।

Salesforce यह शब्द ज़्यादा संकरे अर्थ में इस्तेमाल करता है। जब Salesforce junction object कहता है, तो उसका मतलब होता है दो master-detail संबंधों वाला एक कस्टम ऑब्जेक्ट (Create a Many-to-Many Object Relationship (opens in a new tab))। मैं उसे Salesforce Junction Object कहूँगा। हर Salesforce Junction Object एक तार्किक जंक्शन ऑब्जेक्ट है, लेकिन हर तार्किक जंक्शन ऑब्जेक्ट Salesforce Junction Object नहीं बनता: उसे एक master-detail और एक lookup से बनाइए, या दो lookups से, और वह अब भी एक तार्किक जंक्शन ऑब्जेक्ट है, बस Salesforce वाला नहीं। (Salesforce खुद भी पूरी तरह एकरूप नहीं है: उसका अपना object reference lookups पर बने कुछ स्टैंडर्ड ऑब्जेक्ट को “junction objects” कहता है। परीक्षा में संकरी परिभाषा मानें।)

परीक्षा-ज्ञान। एक Salesforce Junction Object दो master-detail संबंधों वाला एक कस्टम ऑब्जेक्ट है, और जब Salesforce “junction object” कहता है, तो उसका यही मतलब होता है। तार्किक जंक्शन ऑब्जेक्ट मॉडलिंग का व्यापक विचार है: कोई भी ऑब्जेक्ट जो many-to-many में दो दूसरों को जोड़ता है और अपने एट्रिब्यूट रखता है, चाहे वह कैसे भी बना हो।

दूसरा आयाम है चौड़ाई। क्या किसी child के दो master-detail parent हो सकते हैं? हाँ। तीन? नहीं। हर कस्टम ऑब्जेक्ट के ज़्यादा से ज़्यादा दो master-detail संबंध हो सकते हैं (Considerations for Object Relationships (opens in a new tab))। दो master-detail parent से ही आप many-to-many के लिए एक Salesforce Junction Object बनाते हैं। क्रू और ट्रक एक क्रू असाइनमेंट में मिलते हैं, और जैसा हमने अध्याय 2 में पाया, यह सिर्फ़ पाइपलाइन नहीं है: इसकी एक तारीख है, एक रूट है, शायद एक status। जंक्शन वह जगह है जहाँ संबंध एक बिज़नेस अवधारणा बन जाता है। इसे बनाने के लिए Salesforce के सुझाव: इसे ऐसा नाम दें जो बताए कि यह क्या है, इसके रिकॉर्ड नाम को auto number बनाएँ, और हर master की related list का नाम दूसरे master पर रखें, ताकि Crew पेज पर “Trucks” दिखे और Truck पेज पर “Crews” (Create a Many-to-Many Object Relationship (opens in a new tab))।

अब बारीकी। दोनों parent में से एक primary होता है, और वह वही है जिसका master-detail फ़ील्ड आपने पहले बनाया। कोई दृश्य संकेत नहीं है कि वह कौन-सा है, इसलिए यह परीक्षा का एक क्लासिक सवाल है, और एक क्लासिक हैरानी भी।

primary क्या तय करता है? तीन बातें (Create a Many-to-Many Object Relationship (opens in a new tab)):

• रूप-रंग। जंक्शन के पेज primary master का रंग और icon इस्तेमाल करते हैं।
• मालिक। जंक्शन रिकॉर्ड primary master रिकॉर्ड का मालिक विरासत में पाते हैं। आप इसे कभी नहीं देखते, क्योंकि detail का कोई Owner फ़ील्ड नहीं होता; यह तभी मायने रखता है जब आप बाद में दोनों master-detail संबंध हटा दें।
• Division, अगर आपका org divisions इस्तेमाल करता है, उसी तरह।

और दूसरा secondary है। उसका क्या मतलब है?

• वह primary बनने की कतार में है। primary master-detail फ़ील्ड डिलीट करें या उसे lookup में convert करें, और secondary, primary बन जाता है।
• वह रिपोर्ट का दायरा तय करता है। Salesforce आपको दो report types देता है: “Primary master with junction object and secondary master” और “Secondary master with junction object and primary master”। जो master पहले लिखा है, वह तय करता है कि रिपोर्ट कौन-से रिकॉर्ड दिखा सकती है।
• Access के लिए वह उतना ही मायने रखता है। मैं इसे ऐसे कहता हूँ: स्वामित्व primary से, access दोनों से, और सबसे सख्त जीतता है। किसी भी detail की तरह, जंक्शन की अपनी कोई share table नहीं होती। Salesforce हर master-detail फ़ील्ड की Sharing Setting के ज़रिए दोनों master रिकॉर्ड पर यूज़र का access जाँचता है। अगर दोनों Read/Write पर सेट हैं, तो Crew Assignment एडिट करने के लिए यूज़र को क्रू और ट्रक दोनों पर Read/Write चाहिए (Considerations for Object Relationships (opens in a new tab))।
• डिलीट पर भी वह उतना ही असर डालता है। किसी भी master को डिलीट करें, क्रू को या ट्रक को, और उसके जंक्शन रिकॉर्ड Recycle Bin में चले जाते हैं। दोनों को डिलीट करें और वे हमेशा के लिए चले जाते हैं।

Click to enlarge

कुछ और नियम: दोनों master के पास जंक्शन से roll-up summaries हो सकते हैं, और जंक्शन के formulas और वैलिडेशन रूल दोनों के फ़ील्ड तक पहुँच सकते हैं। लेकिन जंक्शन किसी और चीज़ का master नहीं हो सकता, इसलिए वह परतों के बीच में नहीं बैठ सकता, और दोनों master एक ही ऑब्जेक्ट नहीं हो सकते; किसी ऑब्जेक्ट से खुद तक के many-to-many के लिए अलग डिज़ाइन चाहिए। और अगर किसी parent के 200 से ज़्यादा जंक्शन रिकॉर्ड हैं और जंक्शन दूसरे parent तक roll up होता है, तो Salesforce आपको वह parent तब तक डिलीट नहीं करने देगा जब तक आप उनमें से काफ़ी रिकॉर्ड हटा न दें।

तो: कौन-सा parent primary होना चाहिए? जो अर्थ का मालिक है, उसे पहले बनाएँ। Crew Assignment के लिए, काम क्रू कर रहा है, इसलिए मैं Crew पहले बनाऊँगा। और फिर इसे लिख लें, क्योंकि स्क्रीन पर कुछ भी अगले व्यक्ति को यह नहीं बताएगा।

यह सब कहने के बाद भी, मेरे पास बहुत ज़्यादा Salesforce Junction Objects नहीं होते। आमतौर पर किसी ऑब्जेक्ट का एक master-detail parent होता है, और वह उसी तरह का डेटा होता है: ग्राहक डेटा के नीचे ग्राहक डेटा, ट्रांज़ैक्शनल के नीचे ट्रांज़ैक्शनल (अध्याय 2 के डेटा के प्रकार याद करें: ग्राहक, ट्रांज़ैक्शनल, रेफ़रेंस)। जब उसका दूसरा parent अलग तरह का होता है, आमतौर पर एक रेफ़रेंस ऑब्जेक्ट, तो वह संबंध एक lookup होता है। डिलीवरी आइटम अपनी डिलीवरी का है: master-detail, दोनों ट्रांज़ैक्शनल। वह जिस Product को ले जाता है, उसकी ओर lookup से इशारा करता है, क्योंकि प्रोडक्ट रेफ़रेंस डेटा है जिसका अपना जीवन है, और कोई नहीं चाहता कि एक प्रोडक्ट डिलीट करने से सालों का डिलीवरी इतिहास साथ चला जाए। डिलीवरी आइटम अब भी एक डिलीवरी और उस पर के प्रोडक्ट के बीच एक तार्किक जंक्शन ऑब्जेक्ट है; बस वह Salesforce Junction Object नहीं है।

Self-relationships: जब लकीर लौट आती है

कोई ऑब्जेक्ट खुद से जुड़ सकता है: एक parent account, एक मैनेजर, एक डिस्ट्रिब्यूशन सेंटर जो किसी regional hub को रिपोर्ट करता है। Salesforce में दो बने-बनाए हैं जिनसे आप लगभग हर org में मिलेंगे: Account से Account, Parent Account फ़ील्ड जो account हायरार्की बनाता है, और Case से Case, मॉड्यूल 2 वाला Parent Case जो जुड़े हुए cases को समूह में रखता है। self-relationship एक lookup ही होना चाहिए, और कोई रिकॉर्ड खुद की ओर इशारा नहीं कर सकता, हालाँकि दो रिकॉर्ड एक-दूसरे की ओर इशारा कर सकते हैं (Considerations for Object Relationships (opens in a new tab))। User ऑब्जेक्ट पर यह अपने आप में एक खास टाइप है, hierarchical संबंध, जो किसी यूज़र के मैनेजर जैसी चीज़ों के लिए इस्तेमाल होता है। तरीका आसान है; नामकरण मायने रखता है। Distribution Center से Distribution Center तक का Distribution_Center__c नाम का lookup किसी की मदद नहीं करता। Parent? Backup? Overflow? संबंध का नाम उसकी भूमिका पर रखें, उस ऑब्जेक्ट पर नहीं जिसकी ओर वह इशारा करता है।

Click to enlarge

Hierarchical: User ऑब्जेक्ट का अपना संबंध

यह छोटा है, और ठीक उसी तरह का कम-जाना, अपनी तरह का अकेला तथ्य है जिस पर मैं उम्मीद करूँगा कि परीक्षा सवाल बनाए। Hierarchical एक खास lookup है जो सिर्फ़ User ऑब्जेक्ट पर होता है। यह एक यूज़र को दूसरे यूज़र से जोड़ता है, और Salesforce chain को घूमकर वापस नहीं आने देता: कोई यूज़र खुद की ओर इशारा नहीं कर सकता, सीधे या घुमाकर (Object Relationships Overview (opens in a new tab))। अगर Maria के मैनेजर Dev हैं, तो Dev की मैनेजर Maria नहीं हो सकती, न ही कोई ऐसा जो ऊपर Maria को रिपोर्ट करता हो।

ऊपर वाले self-relationships से यही फ़र्क है। Account या किसी कस्टम ऑब्जेक्ट पर, दो रिकॉर्ड एक-दूसरे की ओर इशारा कर सकते हैं। User पर, हायरार्की को हायरार्की ही रहना होगा। और User को User से जोड़ने का यही एक तरीका है: User से खुद तक का सामान्य lookup विकल्प में मिलता ही नहीं।

आपके पास एक पहले से है। User पर स्टैंडर्ड Manager फ़ील्ड एक hierarchical संबंध है, और approvals इसे इस्तेमाल कर सकते हैं: यह अनुरोध भेजने वाले के मैनेजर को भेजें। आप अपना भी बना सकते हैं, मान लीजिए Escalation Contact या Backup Approver, और कोई approval उसी तरह उसके रास्ते जा सकता है (ApprovalProcess, Metadata API (opens in a new tab))। इसे रोल हायरार्की से न मिलाएँ, जो रिकॉर्ड access चलाती है। hierarchical फ़ील्ड बस यूज़र के बीच एक संबंध है; यह एक भी रिकॉर्ड शेयर नहीं करता।

परीक्षा-ज्ञान। hierarchical संबंध सिर्फ़ User ऑब्जेक्ट पर होता है, जैसे स्टैंडर्ड Manager फ़ील्ड, और कोई यूज़र खुद की ओर इशारा नहीं कर सकता, सीधे या घुमाकर। यह रोल हायरार्की नहीं है।

संबंधों की भी सीमाएँ हैं

हर ऑब्जेक्ट के ज़्यादा से ज़्यादा दो master-detail संबंध हो सकते हैं। lookup और master-detail फ़ील्ड मिलकर संबंध फ़ील्ड गिने जाते हैं: डिफ़ॉल्ट रूप से हर ऑब्जेक्ट पर 40, अनुरोध पर ज़्यादा से ज़्यादा 50। Roll-up summary फ़ील्ड: डिफ़ॉल्ट रूप से हर ऑब्जेक्ट पर 25, ज़्यादा से ज़्यादा 40 (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab))। Salesforce यह भी कहता है कि किसी भी सीमा को बढ़ाने से परफ़ॉर्मेंस पर असर पड़ सकता है।

आपको इन नंबरों के हिसाब से डिज़ाइन करने की ज़रूरत नहीं है; आपको यह ध्यान देना है कि आप कब उनके करीब हैं। जिस ऑब्जेक्ट से एक के बाद एक संबंध लटक रहे हों, वह आपसे कुछ कह रहा है। हो सकता है वह सच में इतना केंद्रीय हो। या हो सकता है मॉडल गलत हो। (और अध्याय 18 का headroom नियम लागू होता है: किसी सीमा से काफ़ी नीचे रहें, तीसरे साल के हिसाब से नापकर।)

10,000 children का सवाल

फिर आता है बहुत ज़्यादा children वाला parent। Salesforce की अपनी सलाह है कि एक master-detail parent के लगभग 10,000 child रिकॉर्ड से ज़्यादा न हों (Considerations for Object Relationships (opens in a new tab)), और बड़े पैमाने पर रिकॉर्ड access पर उसकी गाइड आम तौर पर parent-child संबंधों के लिए यही कहती है (Parent-Child Data Skew (opens in a new tab))। रिकॉर्ड 10,001 org को नहीं तोड़ता। लेकिन उस बिंदु के बाद, किसी child को सेव करने से parent लॉक हो सकता है, और parent पर शेयरिंग के बदलाव हर child तक लहर की तरह जाते हैं।

इसलिए जब मैं एक parent, बहुत बड़ी संख्या में children देखता हूँ, तो मैं पूछता हूँ: वे सब एक ही parent के नीचे क्यों हैं, उनका मालिक कौन है, उन पर query कैसे होती है, और कौन-सा ऑटोमेशन parent को छूता है? एक ही “Steve Trucking” account के नीचे हर डिलीवरी कुछ ही दिनों में 10,000 पार कर जाएगी। एक मासूम one-to-many एक skew समस्या बन जाता है। अगला मॉड्यूल skew की झलक देता है, और भाग 2 गहराई में जाता है।

फ़ीचर के हिसाब से लकीर डिज़ाइन न करें

यही आदत मैं इस मॉड्यूल से चाहता हूँ। “मुझे roll-up चाहिए,” “मुझे इसे अनिवार्य करना है,” “मुझे विरासत वाली शेयरिंग चाहिए” से शुरू न करें। ये इम्प्लीमेंटेशन के सुराग हैं। बिज़नेस से शुरू करें: क्या child का अपना जीवन है, उसका मालिक कौन है, क्या वह अकेले रह सकता है, क्या वह जगह बदल सकता है, parent के जाने पर क्या होता है, क्या संबंध डेटा साथ रखता है, और हर तरफ़ कितना बड़ा हो सकता है? फिर वह संबंध चुनें जो इन जवाबों को लागू करे।

Click to enlarge

परीक्षा से आगे: AI क्या बदलता है। AI सेकंडों में संबंध सुझा सकता है। वह आपको यह नहीं बता सकता कि बिज़नेस कभी parent को डिलीट करेगा या नहीं। तेज़ी से डायग्राम बनाने से, लाखों रिकॉर्ड और दर्जनों ऑटोमेशन के उस पर निर्भर होने के बाद, गलत संबंध को पलटना सस्ता नहीं हो जाता।

आर्किटेक्ट यहाँ क्या तय करता है

• child का अपना जीवनचक्र है या वह सच में parent का है, और स्वामित्व और access उसके अपने होने चाहिए या विरासत में मिले।
• child parent के बिना रह सकता है, parent बदल सकता है, या parent के डिलीट होने के बाद बचा रह सकता है।
• parent डिलीट होने पर हर lookup क्या करता है: खाली करना, रोकना, या कैस्केड।
• कोई many-to-many सिर्फ़ पाइपलाइन है या एक बिज़नेस अवधारणा, तार्किक जंक्शन ऑब्जेक्ट Salesforce Junction Object बनता है या नहीं, कौन-सा parent primary है, और access के लिए दोनों parent का क्या मतलब है।
• मॉडल प्लेटफ़ॉर्म के आकार में फ़िट बैठता है या नहीं: तीन कस्टम detail स्तर गहरा, दो master-detail parent चौड़ा, संबंधों और roll-ups की सीमाएँ।
• children की अपेक्षित संख्या और बँटवारा कोई skew जोखिम पैदा करता है या नहीं, जिससे डिज़ाइन बदलना चाहिए।

संबंध इस बारे में वादों का एक सेट है कि डेटा के दो टुकड़े साथ में कैसे व्यवहार करते हैं। इन्हें सोच-समझकर करें।

और जानें

• Salesforce Help, Considerations for Object Relationships (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया)।
• Salesforce Help, Object Relationships Overview (opens in a new tab) और Create a Many-to-Many Object Relationship (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया)।
• Salesforce Help, Roll-Up Summary Field (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया)।
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया)।
• Salesforce Help, Lookup Filters (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया)।
• Salesforce Help, Increase the Maximum Relationships Allowed per Object (opens in a new tab) और Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।