स्वामित्व और जीवनचक्र

🌐 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 द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

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

यह मॉड्यूल किस सवाल का जवाब देता है: रिकॉर्ड का मालिक कौन है, और उसके पूरे जीवन में उसके साथ क्या होता है?

जब मैं किसी डेटा मॉडल को देखता हूँ, तो मैं सिर्फ़ यह नहीं जानना चाहता कि ऑब्जेक्ट कौन-से हैं और वे कैसे जुड़ते हैं। मैं जानना चाहता हूँ कि समय के साथ रिकॉर्ड का क्या होता है। उन्हें कौन बनाता है? उनका मालिक कौन है? उन्हें दोबारा असाइन कौन कर सकता है? जब बिज़नेस का रिश्ता बदलता है, जब वे सक्रिय नहीं रहते, तब क्या होता है? क्या उन्हें कभी डिलीट करना चाहिए, और हम उन्हें कितने समय तक रखते हैं? इनमें से कुछ भी ERD पर नहीं दिखता, यानी entity relationship diagram पर: अध्याय 2 के डेटा मॉडल के बॉक्स और लकीरें। यह सब डेटा आर्किटेक्चर है। और Salesforce पर, स्वामित्व वह जगह है जहाँ डेटा मॉडल और सिक्योरिटी मॉडल आपस में टकराते हैं।

स्वामित्व किसी फ़ील्ड में लिखे नाम से ज़्यादा है

एडमिन किसी रिकॉर्ड पर Owner देखते हैं और उसे एक लेबल की तरह पढ़ते हैं: यह account Bart का है, वह case Lisa का। इसका यह मतलब हो सकता है। लेकिन Salesforce पर, स्वामित्व प्लेटफ़ॉर्म का एक तंत्र भी है। जिन ऑब्जेक्ट का एक मालिक होता है, उन पर मालिक तय करता है कि रोल हायरार्की, शेयरिंग रूल, queues और दोबारा असाइनमेंट के ज़रिए रिकॉर्ड कौन देख सकता है। इसलिए जब मैं पूछता हूँ “इस रिकॉर्ड का मालिक कौन है?” तो मैं यह नहीं पूछ रहा कि पेज पर किसका नाम जाएगा। मैं पूछ रहा हूँ कि हम इससे सिक्योरिटी और जीवनचक्र का कौन-सा व्यवहार जोड़ रहे हैं। मालिक एक यूज़र हो सकता है, या कुछ ऑब्जेक्ट के लिए, जिनमें कस्टम ऑब्जेक्ट, cases और leads शामिल हैं, एक queue, और दोनों ही सूरतों में मालिक को रिकॉर्ड पर पूरा access मिलता है (Understanding Sharing (opens in a new tab))।

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

Share table: जहाँ स्वामित्व access बनता है

कुछ लोगों को यह भी नहीं पता कि share table क्या है। हर डेटा आर्किटेक्ट को पता होना चाहिए।

किसी रिकॉर्ड की ज़्यादातर शेयरिंग एक जुड़े हुए share object में रखी जाती है, जो access control list का Salesforce वाला रूप है (Understanding Sharing (opens in a new tab))। Account के पास AccountShare है, Contact के पास ContactShare, और कस्टम ऑब्जेक्ट को अपना मिलता है: Truck__c के पास Truck__Share (Sharing a Record Using Apex (opens in a new tab))। इसकी हर पंक्ति चार बातें कहती है:

• कौन-सा रिकॉर्ड: parent ID।
• कौन: एक यूज़र, या एक ग्रुप (एक public group, किसी रोल का ग्रुप, एक territory)।
• कितना: Read, Edit, या All (पूरा access)।
• क्यों: row cause। मालिक के लिए Owner, शेयरिंग रूल के लिए Rule, manual share के लिए Manual, Team, वे implicit कारण जो Salesforce किसी account और उसके children के बीच जोड़ता है, और वे कारण जो कोई डेवलपर Apex sharing के लिए तय करता है।

क्लास में मैं Workbench खोलता हूँ और कोई रिकॉर्ड शेयर करते समय share table पर query करता हूँ, और आप पंक्तियों को आते-जाते देखते हैं। जब कोई पूछता है “यह व्यक्ति वह क्यों देख सकता है?”, तो जवाब अक्सर एक पंक्ति में, उसके कारण के साथ, बैठा होता है।

लेकिन सब कुछ इसमें नहीं होता। organization-wide default कोई पंक्ति नहीं है। रोल हायरार्की भी वहाँ स्टोर नहीं होती: मालिक से ऊपर के लोगों का access ज़रूरत पड़ने पर निकाला जाता है। और View All, Modify All, View All Data और Modify All Data share table को पूरी तरह छोड़ देते हैं (Sharing a Record Using Apex (opens in a new tab))। जैसा मैं क्लास में कहता हूँ: View All पर टिक करें, और आपने share table को दरकिनार कर दिया।

Salesforce कुछ रिकॉर्ड आपके लिए खुद भी शेयर करता है, उनके आपसी संबंध की वजह से। यह implicit sharing है, और यह किसी account और उसके children के बीच काम करती है। अगर आप कोई contact, case या opportunity देख सकते हैं, तो आप उस account को भी पढ़ सकते हैं जिसका वह है। और account के मालिक को account के contacts, cases और opportunities पर access मिलता है, उस स्तर पर जो मालिक का रोल तय करता है (Implicit Sharing (opens in a new tab))। हाल की रिलीज़ में Salesforce उस child access का कुछ हिस्सा पंक्तियों में स्टोर करने के बजाय ज़रूरत पड़ने पर निकालता है, इसलिए हैरान न हों जब share table की query उसे न दिखाए। मैं यहाँ बस एक इशारा दे रहा हूँ; ब्योरा Relationships and Built-In Sharing में है।

एक और अपवाद, तब के लिए जब आपके पास बहुत-से एक्सटर्नल यूज़र हों। High-volume community users, यानी हज़ारों से लेकर लाखों ग्राहकों के लिए बने Customer Community लाइसेंस, का कोई रोल नहीं होता, वे public groups में नहीं हो सकते, और उन्हें शेयरिंग रूल या manual shares से रिकॉर्ड नहीं दिए जा सकते (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab))। उनके लिए share table जवाब नहीं है: वे sharing sets के ज़रिए रिकॉर्ड तक पहुँचते हैं, जो किसी रिकॉर्ड के account या contact को यूज़र के अपने account या contact से मिलाते हैं। यह उन वजहों में से एक है जिनसे ये लाइसेंस स्केल करते हैं। Sharing and Visibility कोर्स इसे Sharing with External Users में कवर करता है।

और मॉड्यूल 7 याद रखें: detail ऑब्जेक्ट का कोई share object होता ही नहीं। उसका access master के share object और master-detail फ़ील्ड की Sharing Setting से आता है।

डेटा आर्किटेक्ट को इसकी परवाह क्यों है? क्योंकि स्वामित्व इसी टेबल में लिखा जाता है। हर मालिक का बदलाव, हर नया शेयरिंग रूल, हर यूज़र का रोल या ग्रुप बदलना, इन सबका मतलब है Salesforce का पंक्तियाँ जोड़ना और हटाना। कुछ हज़ार रिकॉर्ड पर किसी का ध्यान नहीं जाता। 10 मिलियन पर, जिनमें से ज़्यादातर का मालिक एक ही यूज़र हो, यही वह recalculation है जिससे हम थोड़ी देर में मिलेंगे।

परीक्षा-ज्ञान। कस्टम ऑब्जेक्ट के share object का नाम Object__Share होता है, जैसे Truck__Share। एक detail ऑब्जेक्ट का कोई share object नहीं होता: उसका access master से आता है। और जब किसी रिकॉर्ड का मालिक बदलता है, तो उसके manual shares हट जाते हैं, जबकि डेवलपर के अपने कारण वाली Apex sharing बनी रहती है।

यहीं डेटा मॉडल सिक्योरिटी मॉडल को कमान सौंपता है, और बाकी मैं Sharing and Visibility Architect कोर्स में पढ़ाता हूँ: Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, implicit shares के लिए Relationships and Built-In Sharing, और Apex sharing के कारणों के लिए Programmatic Sharing and Secure Code। इस कोर्स में, अध्याय 12 इसे इंसानों, एप्लिकेशन और एजेंट के लिए एक साथ लाता है।

कभी-कभी स्वामित्व विरासत में मिलता है

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

सिस्टम के बनाए रिकॉर्ड का मालिक कौन?

अब बात दिलचस्प होती है। एक व्यक्ति account बनाता है, और शायद वही मालिक बन जाता है। लेकिन एक ERP रात भर में 100,000 ट्रांज़ैक्शन भेजता है। उनका मालिक कौन है? इंटीग्रेशन यूज़र? एक queue? डेटा से निकाला गया कोई regional मालिक? एक सिस्टम account जिसके बारे में पाँच साल से किसी ने सोचा तक नहीं? और अब एजेंट भी रिकॉर्ड बनाते हैं।

मेरी राय: यह इस पर निर्भर करता है कि शेयरिंग के लिए स्वामित्व मायने रखता है या नहीं। इंटीग्रेशन यूज़र, या एजेंट यूज़र, एक मान्य यूज़र है, और वह रिकॉर्ड का मालिक हो सकता है। अगर उस ऑब्जेक्ट में स्वामित्व access तय करता है (रोल हायरार्की या शेयरिंग रूल के ज़रिए), तो रिकॉर्ड सही मालिक को असाइन करें: एक असली यूज़र, एक queue, या एक समर्पित owner यूज़र। अगर नहीं करता, तो सिस्टम यूज़र को ही मालिक रखना बेहतर चुनाव हो सकता है, क्योंकि तब ऑडिट ट्रेल सीधे उस चीज़ तक ले जाती है जिसने रिकॉर्ड बनाया।

दोनों ही सूरतों में, इसे सोच-समझकर तय करें। जो इंटीग्रेशन account हर चीज़ का मालिक है, वह चुपचाप आपके सिक्योरिटी आर्किटेक्चर का हिस्सा बन चुका है, और किसी को पता होना चाहिए कि अगर उसे कभी निष्क्रिय किया गया तो क्या होगा।

स्वामित्व स्केल की समस्या बन सकता है

बँटवारा भी मायने रखता है। हज़ारों मालिकों में बँटे 10 मिलियन रिकॉर्ड एक आकार है। एक ही यूज़र के 10 मिलियन रिकॉर्ड बिल्कुल अलग आकार है। जब एक अकेला यूज़र किसी ऑब्जेक्ट के 10,000 से ज़्यादा रिकॉर्ड का मालिक होता है, तो Salesforce इसे ownership data skew कहता है (Ownership Data Skew (opens in a new tab))। यह आमतौर पर तब होता है जब कोई सब कुछ एक यूज़र या queue पर डाल देता है: बिना असाइन हुए सारे leads एक placeholder यूज़र पर, हर इंटीग्रेशन रिकॉर्ड इंटीग्रेशन यूज़र पर। यह तब तक बेअसर है जब तक वह यूज़र रोल हायरार्की में जगह नहीं बदलता, या किसी ऐसे ग्रुप में आता-जाता नहीं जिस पर कोई शेयरिंग रूल निर्भर है। तब Salesforce को शेयरिंग की बहुत बड़ी संख्या में एंट्री बदलनी पड़ती हैं, और आपको लंबे चलने वाले recalculations मिलते हैं।

सलाह व्यावहारिक है। जहाँ हो सके, स्वामित्व को ज़्यादा यूज़र में बाँटें। अगर एक यूज़र को बहुत कुछ का मालिक होना ही है, तो उसे रोल हायरार्की से बाहर रखें; अगर उसे रोल चाहिए, तो उसे सबसे ऊपर उसके अपने रोल में रखें और उसे हिलाएँ नहीं, और उसे उन public groups से बाहर रखें जिन्हें शेयरिंग रूल इस्तेमाल करते हैं (Ownership Data Skew (opens in a new tab))। यही सोच पिछले मॉड्यूल वाले बहुत ज़्यादा children वाले parent पर भी लागू होती है, यानी parent-child skew।

तो बँटवारा फ़िज़िकल मॉडल का हिस्सा है। सिर्फ़ यह न पूछें कि कितने रिकॉर्ड हैं; यह पूछें कि वे कैसे बँटे हैं। यह Steve की “शून्यों की गिनती” (Number of Zeros) का एक और रूप है: सिर्फ़ कितने शून्य नहीं, बल्कि शून्य कहाँ इकट्ठा हैं। भाग 2 skew में गहराई तक जाता है; यहाँ मैं चाहता हूँ कि आप इसे आते हुए देख लें। Sharing and Visibility कोर्स इसे Sharing at Scale में फिर उठाता है।

“डिफ़ॉल्ट मालिक” आर्किटेक्चर बन जाता है

यह एक pattern है जो मैं हर समय देखता हूँ। किसी को नहीं पता कि किसी चीज़ का मालिक कौन होना चाहिए, तो कोई कह देता है, “बस सबको इंटीग्रेशन यूज़र को असाइन कर दो,” या “System नाम का एक generic यूज़र बना दो।” शायद यह सही हो। लेकिन इसे गलती से न करें। एक अस्थायी डिफ़ॉल्ट की आदत होती है स्थायी बन जाने की: दो साल बाद हर रिकॉर्ड integration@company.com का है, किसी को याद नहीं कि क्यों, और इसे बदलना एक पूरा प्रोजेक्ट है। यही अध्याय 1 की पलटने की कसौटी (Reversibility Test) है: एक मिलियन रिकॉर्ड एक मालिक को देने से पहले पूछें कि बाद में इसे बदलने में क्या लगेगा।

दोबारा असाइन करना जीवनचक्र की एक घटना है

मालिक बदलते हैं। रिप नौकरी छोड़ते हैं, territories बदलती हैं, टीमें फिर से संगठित होती हैं, regions का फिर से संतुलन होता है। मालिक पर क्या-क्या निर्भर है: शेयरिंग, ऑटोमेशन, रिपोर्ट, queues, escalations, इंटीग्रेशन? अगर मालिक बदलने से यह बदलता है कि रिकॉर्ड कौन देख सकता है, तो दोबारा असाइन करना एडमिन की साफ़-सफ़ाई नहीं है। यह एक सिक्योरिटी घटना है, और एक मिलियन रिकॉर्ड पर यह एक ऑपरेशनल घटना भी है। ऐसा होने पर share table पर नज़र रखें: मालिक बदलने पर manual shares हट जाते हैं, जबकि डेवलपर के अपने कारण वाली Apex sharing इस बदलाव के बाद भी बची रहती है (Understanding Sharing (opens in a new tab))। क्लास में मैं किसी के साथ एक रिकॉर्ड शेयर करता हूँ, मालिक बदलता हूँ, और उस व्यक्ति का access चला जाता है। कमरा हमेशा हैरान होता है।

और याद रखें कि स्वामित्व और access एक ही चीज़ नहीं हैं। मालिक अकेला व्यक्ति नहीं है जिसे रिकॉर्ड देखना होता है, और Salesforce के पास access देने के कई तरीके हैं: रोल हायरार्की, शेयरिंग रूल, teams, territories, manual और programmatic sharing। Sharing and Visibility कोर्स इन पर गहराई से जाता है, Steve’s 22 Ways to Share a Record से शुरू करके। आर्किटेक्ट की बात ज़्यादा सीधी है: हर access समस्या को स्वामित्व से हल न करें। अगर आप सिर्फ़ इसलिए मालिक इधर-उधर कर रहे हैं कि कोई रिकॉर्ड देख सके, तो शायद आप गलत समस्या हल कर रहे हैं।

बनना तो बस शुरुआत है

बहुत-सी डेटा मॉडलिंग बनने पर ही रुक जाती है: फ़ील्ड, ऑब्जेक्ट, संबंध, हो गया। लेकिन रिकॉर्ड दस साल तक जी सकता है। वह अपडेट होता है, मालिक बदलता है, status और संबंध बदलता है, निष्क्रिय होता है, इतिहास बन जाता है, उसे आर्काइव करने की ज़रूरत पड़ सकती है, और किसी दिन शायद डिलीट करने की। आर्किटेक्चर सिर्फ़ यह नहीं है कि रिकॉर्ड कैसे पैदा होता है। यह है कि जन्म से मृत्यु तक क्या होता है।

Click to enlarge

सिर्फ़ पुराना होने की वजह से डिलीट न करें

एक रिटेल पार्टनर काम भेजना बंद कर देता है। account डिलीट कर दें? अपने-आप नहीं: उसकी डिलीवरी, क्लेम और बिलिंग का इतिहास अब भी मायने रखता है। एक ट्रक रिटायर होता है। उसे डिलीट कर दें, उसके डिलीवरी इतिहास और नुकसान के क्लेम समेत? हो सकता है वह चीज़ अब सक्रिय न हो, लेकिन उसका डेटा अब भी है। इसलिए मैं निष्क्रिय को चला गया से अलग रखता हूँ। एक रिटायर हुआ ट्रक मॉडल में रह सकता है; एक पूर्व कर्मचारी अब भी ऑडिट इतिहास में दिख सकता है। ऑपरेशनल रिश्ता खत्म होने के बाद भी आर्किटेक्चर को वे तथ्य रखने होंगे जो मायने रखते हैं।

डेटा रखने की अवधि एक बिज़नेस requirement है

दूसरा पहलू: सब कुछ हमेशा के लिए रखना भी आर्किटेक्चर नहीं है। स्टोरेज बढ़ता है, रिपोर्ट धीमी होती हैं, सर्च में शोर बढ़ता है, और निजता का कानून कह सकता है कि कुछ डेटा जाना ही चाहिए। इसलिए मुझे हम इसे कितने समय तक रखते हैं? का साफ़ जवाब चाहिए। “Salesforce इसे रखता है” कोई retention policy नहीं है।

और ज़्यादातर, यह ट्रांज़ैक्शनल डेटा का सवाल है। रेफ़रेंस डेटा, यानी प्रोडक्ट, सर्विस के प्रकार, डिस्ट्रिब्यूशन सेंटर, बहुत बड़ा नहीं होता, और दूसरे रिकॉर्ड उसकी ओर इशारा करते हैं, इसलिए वह आमतौर पर बना रहता है। ग्राहक डेटा बीच में है: ऐसा दिन आ सकता है जब आप किसी ग्राहक का end-of-life करें, खासकर जब आप निजी डेटा रखे हुए हों और उसे रखने की वजह खत्म हो जाए। लेकिन मात्रा ट्रांज़ैक्शन में है: डिलीवरी, ऑर्डर, cases, अपॉइंटमेंट, जो हर दिन बनते हैं, हमेशा। यही करोड़ों पंक्तियों तक बढ़ता है, और यहीं retention साफ़-साफ़ तय होना चाहिए: शायद org में दो साल का ऑपरेशनल डेटा, कहीं और सात साल के वित्तीय रिकॉर्ड, कुछ फ़ोटो के लिए नब्बे दिन। ये बिज़नेस के नियम हैं, और अगर किसी ने नहीं पूछा है, तो आर्किटेक्ट को पूछना चाहिए।

मैं सालों से क्लास में कहता आया हूँ: अगर आप आज आर्काइव नहीं कर रहे, तो क्या आप कभी करेंगे? “इसे बाद में देख लेंगे” की आदत होती है तीन सौ मिलियन रिकॉर्ड पर एक आपातकालीन प्रोजेक्ट बन जाने की। भाग 2 में आर्काइव करने और purge करने पर एक पूरा मॉड्यूल है, इसी सवाल पर बना।

Steve Trucking: डिलीवरी का मालिक कौन?

एक डिलीवरी रिटेल पार्टनर के मैनिफ़ेस्ट से, एक इंटीग्रेशन के ज़रिए बनती है, दिन में लगभग 3,300 बार। उसका मालिक कौन है? रिटेल पार्टनर नहीं; वह एक बिज़नेस रिश्ता है। प्राप्तकर्ता नहीं। क्रू उसे पूरा करता है, लेकिन क्या हर बार क्रू के ट्रक बदलने पर रिकॉर्ड का मालिक बदलना चाहिए? डिस्पैचर? डिस्ट्रिब्यूशन सेंटर? एक queue? वह इंटीग्रेशन यूज़र जिसने उसे बनाया?

अब इस मॉड्यूल को लागू करें, उस सवाल से शुरू करके जो इसे तय करता है: क्या स्वामित्व किसी के डिलीवरी access को तय करता है? Steve Trucking में नहीं करता। डिस्पैचर अपने डिस्ट्रिब्यूशन सेंटर की डिलीवरी देखते हैं, क्रू अपने रूट वाली, और हर रिटेलर partner portal में अपनी देखता है। इनमें से कुछ भी इस पर निर्भर नहीं कि रिकॉर्ड का मालिक कौन है; यह डिस्ट्रिब्यूशन सेंटर, रूट और पार्टनर से आता है।

तो मेरा जवाब: डिलीवरी का मालिक इंटीग्रेशन यूज़र है। यह इसका अच्छा उदाहरण है कि कोई सिस्टम यूज़र सोच-समझकर रिकॉर्ड का मालिक हो:

• ऑडिट ट्रेल ईमानदार है। हर डिलीवरी का मालिक बताता है कि वह कहाँ से आई: मैनिफ़ेस्ट इंटीग्रेशन से।
• Access शेयरिंग से आता है, स्वामित्व से नहीं। डिस्ट्रिब्यूशन सेंटर पर criteria-based शेयरिंग रूल हर DC की टीम को उसकी डिलीवरी देते हैं; पार्टनर अपनी डिलीवरी portal के ज़रिए देखते हैं।
• Skew को डिज़ाइन से बाहर रखा गया है। दिन में 3,300 के हिसाब से, इंटीग्रेशन यूज़र तीन दिन में 10,000 डिलीवरी पार कर जाता है, यानी पहले दिन से ownership skew, और अगर हम इसकी योजना बनाएँ तो यह ठीक है। इंटीग्रेशन यूज़र का कोई रोल नहीं है, इसलिए हायरार्की में उसके ऊपर कुछ भी दोबारा कैलकुलेट नहीं करना पड़ता, और वह उन public groups से बाहर रहता है जिन्हें हमारे शेयरिंग रूल इस्तेमाल करते हैं।
• कोई डिलीवरी दोबारा असाइन नहीं करता। क्रू ट्रक बदलते हैं और डिस्पैचर शिफ़्ट बदलते हैं, और मालिक कभी नहीं हिलता, इसलिए दोबारा असाइनमेंट का कोई तूफ़ान नहीं आता और खोने के लिए कोई manual shares नहीं होते।

और लिख लें कि अगर वह यूज़र कभी निष्क्रिय किया गया या बदला गया तो क्या होगा, क्योंकि अब वह लाखों रिकॉर्ड का मालिक है। यही वह निर्णय है जिसे अगली टीम को ढूँढना पड़ेगा।

परीक्षा से आगे: AI क्या बदलता है। एजेंट मशीन की रफ़्तार से रिकॉर्ड बनाते और बदलते हैं। अगर कोई एजेंट अपने यूज़र के तहत 100,000 रिकॉर्ड बना दे, तो “मालिक बाद में ठीक कर देंगे” बन जाता है skew, शेयरिंग का recalculation और एक सफ़ाई प्रोजेक्ट। एजेंट के लाइव होने से पहले उसके स्वामित्व का नियम तय करें, उसी सवाल से: क्या यहाँ शेयरिंग के लिए स्वामित्व मायने रखता है?

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

• स्वामित्व बिज़नेस की ज़िम्मेदारी दर्शाता है, एक सिक्योरिटी तंत्र, या दोनों, और अगर Owner में नहीं, तो ज़िम्मेदारी कहाँ रहती है।
• रिकॉर्ड को अपना मालिक चाहिए, या उसे किसी parent से विरासत में मिलना चाहिए।
• इंटीग्रेशन और एजेंट के बनाए रिकॉर्ड का मालिक कौन है, इस पर निर्भर करते हुए कि स्वामित्व शेयरिंग तय करता है या नहीं।
• स्वामित्व कैसे बँटा है, और जब एक यूज़र को बहुत कुछ का मालिक होना ही हो तब ownership skew से कैसे बचें।
• रिकॉर्ड कब निष्क्रिय होते हैं, कब आर्काइव होते हैं, कितने समय तक रखे जाते हैं, और डिलीट करना कब सही है।

जब आप कोई फ़िज़िकल मॉडल देखें, तो सिर्फ़ यह न पूछें कि डेटा कहाँ स्टोर है। पूछें आज इसका मालिक कौन है, कल कौन हो सकता है, और जब हमें इसकी ज़रूरत नहीं रहेगी तब क्या होगा। आगे: सही ऑब्जेक्ट, फ़ील्ड, संबंध और मालिक के बावजूद, डेटा को भरोसेमंद बने रहना होता है।

और जानें

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): मालिकों (एक यूज़र, या कस्टम ऑब्जेक्ट, cases और leads के लिए एक queue) को पूरा access मिलता है; ज़्यादातर शेयरिंग एक जुड़े हुए sharing object में रहती है; रोल हायरार्की रनटाइम पर निकाली जाती है; मालिक बदलने पर manual shares हट जाते हैं, Apex managed sharing बनी रहती है; row cause के मान।
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): AccountShare, MyCustomObject__Share; detail ऑब्जेक्ट का कोई sharing object नहीं होता; share object किन चीज़ों को ट्रैक नहीं करता (OWD, रोल हायरार्की, View All और Modify All)।
• Salesforce Help, Implicit Sharing (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): किसी account और उसके contacts, cases और opportunities के बीच access।
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) और Sharing Rule Considerations (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): कोई रोल नहीं, कोई शेयरिंग रूल या manual shares नहीं; इनकी जगह sharing sets।
• Sharing and Visibility Architect कोर्स: Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, Relationships and Built-In Sharing, Programmatic Sharing and Secure Code, Sharing with External Users, Sharing at Scale।
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) और Parent-Child Data Skew (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।