जोड़ना, मास्टर करना नहीं है

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

Data Architect का अध्याय 6, भाग 1: डेटा आर्किटेक्ट बनना। पिछला: डेटा गुणवत्ता और गवर्नेंस।

“हमें सच का एक ही स्रोत चाहिए।” आर्किटेक्चर में यह सबसे ज़्यादा दोहराए जाने वाले वाक्यों में से एक है, और सबसे कम परखे जाने वालों में से भी। किस चीज़ के लिए? एक account लीजिए। उसका कानूनी नाम, बिलिंग पता और क्रेडिट लिमिट शायद ERP के पास हो; उसका account executive और सपोर्ट टियर Salesforce के पास; और उसकी मार्केटिंग पसंद एक consent प्लेटफ़ॉर्म के पास। एक रिकॉर्ड पर तीन अधिकार, और यह बिल्कुल सामान्य है। इसलिए जब कोई कहता है, “ग्राहक के लिए Salesforce ही हमारा सच का एक स्रोत है,” तो मेरा अगला सवाल हमेशा यही होता है: कौन-सा सच?

यह अध्याय उस सवाल का जवाब सोच-समझकर देने के बारे में है। अधिकार एट्रिब्यूट-दर-एट्रिब्यूट तय होता है। रिकॉर्ड को जोड़ देना उन्हें मास्टर करना नहीं है। और Salesforce अलग-अलग कामों के लिए अलग-अलग टूल देता है: एक org के अंदर डुप्लिकेट मैनेजमेंट और merge; अलग-अलग स्रोतों में एक ही नज़र के लिए Data 360 आइडेंटिटी रेज़ोल्यूशन; और जब मान एक बार तय करके हर जगह वापस भेजने हों, तो एक समर्पित MDM प्लेटफ़ॉर्म। अध्याय चेकपॉइंट 1 पर खत्म होता है, जहाँ भाग 1 Steve Trucking पर एक साथ आता है।

यह तस्वीर AI से बनाई गई है।

इस अध्याय की मेरी राय

• हर एट्रिब्यूट का अपना सच। पूछें कि डेटा का हर टुकड़ा कहाँ बनता है, कहाँ एडिट होता है और कहाँ संदर्भित होता है, और वह कितनी तेज़ी से बदलता है। बाहरी अधिकार को स्कीमा में सिस्टम prefix से दिखाएँ, जैसे sap_ या erp_।
• Prospects अलग होते हैं। वे ERP के जानने से पहले Salesforce में रहते हैं; ERP का अधिकार conversion के बाद लागू होता है।
• Salesforce प्रोजेक्ट्स पर रजिस्ट्री ही आम है, फिर कंसॉलिडेशन और को-एग्ज़िस्टेंस; शुद्ध सेंट्रलाइज़्ड MDM कम ही दिखता है।
• Merge तभी करें जब विजेता साफ़ हो। बाहरी लोड से आए डुप्लिकेट तब रखें जब आपको पीछे तक ट्रेस करना पड़ सकता है; merge वह इतिहास मिटा देता है। और तय करें कि children का क्या होगा: उन्हें खिसकाएँ, उन्हें लोड न करें, या उन्हें एक निष्क्रिय रिकॉर्ड पर रहने दें।
• यूनिफ़ाइड प्रोफ़ाइल एक नक्शा है; गोल्डन रिकॉर्ड एक फ़ैसला है। यह लोगों को उलझा सकता है: आइडेंटिटी रेज़ोल्यूशन एक unified individual बनाता है, लेकिन गोल्डन रिकॉर्ड नहीं।
• मैचिंग कितनी सख़्त हो, यह जोखिम का फ़ैसला है। जहाँ दो लोगों का घुल-मिल जाना महँगा पड़ता है, वहाँ जान-बूझकर कम मैच करें।
• तीन कामों के लिए तीन टूल: merge, आइडेंटिटी रेज़ोल्यूशन, MDM।
• हायरार्की का मास्टर बँटा होता है। अधिकार शाखा-दर-शाखा तय करें।
• “सबसे मुश्किल चीज़ bi-directionals हैं।” दोतरफ़ा इंटीग्रेशन से दो मास्टर नहीं बन जाते। पहली टक्कर से पहले तय करें कि कौन-से फ़ील्ड एक ट्रांज़ैक्शन की तरह साथ-साथ चलेंगे।
• मास्टर डेटा को दिखने लायक बनाएँ। एक फ़ील्ड जो बताए कि यह मास्टर डेटा है (ERP की key या एक flag), वही तय करता है कि क्या एडिट हो सकता है, रिकॉर्ड टाइप नहीं।
• ERP हमारे नियंत्रण में नहीं हैं। हमारे नियंत्रण में यह है कि हम उन्हें Salesforce में कैसे दिखाते हैं: दो ERP में एक ग्राहक एक हायरार्की हो सकता है, बराबरी वाले रिकॉर्ड हो सकते हैं, या हर ERP के लिए एक child वाला एक account, और यह इस पर निर्भर करता है कि क्लाइंट अपने ERP को आपस में कितनी अच्छी तरह सिंक रखता है।

तीन कामों के लिए तीन टूल

काम	टूल	यह स्रोतों के साथ क्या करता है
एक org के अंदर डुप्लिकेट, साफ़ विजेता के साथ	डुप्लिकेट मैनेजमेंट और merge	तीन तक रिकॉर्ड merge करता है; बाकी Recycle Bin में चले जाते हैं
स्रोतों के पार एक पहचान और एक ही नज़र	Data 360 आइडेंटिटी रेज़ोल्यूशन	उन्हें जोड़ता है; किसी को नहीं बदलता (एक रजिस्ट्री)
एक नियंत्रित मान, हर सिस्टम को वापस भेजा जाता है	एक समर्पित MDM प्लेटफ़ॉर्म	मान तय करता है और उसे बाँटता है (को-एग्ज़िस्टेंस या सेंट्रलाइज़्ड)

इस अध्याय का रास्ता

छह मॉड्यूल और एक चुनौती, हर एक अपने आप में पूरा।

1. हर एट्रिब्यूट के लिए सच का एक स्रोत। अधिकार-मानचित्र, हाइब्रिड गोल्डन रिकॉर्ड, और भरोसे के संकेत।
2. मास्टर डेटा के चार तरीके। रजिस्ट्री, कंसॉलिडेशन, को-एग्ज़िस्टेंस और सेंट्रलाइज़्ड, और क्यों एक साझा मॉडल एक साझा सच नहीं है।
3. मैचिंग, मर्जिंग और सर्वाइवरशिप। गलत मैच की कीमत, Salesforce merge असल में क्या करता है (और children का क्या होता है), और सर्वाइवरशिप भरोसे के बारे में एक बयान के रूप में।
4. नक्शा कोई फ़ैसला नहीं है। मैच रूल और मैच मेथड, मिलान के नियम (reconciliation rules), और क्यों यूनिफ़ाइड प्रोफ़ाइल गोल्डन रिकॉर्ड नहीं है।
5. जब अधिकार साझा हो। अनुरोध बनाम अपडेट, लूप और टक्करें, बँटे मास्टर वाली हायरार्की, और दो ERP में एक ग्राहक।
6. चेकपॉइंट 1 की चुनौती, फिर चेकपॉइंट 1: Steve Trucking, मैं इसे कैसे आर्किटेक्ट करता। पहले चुनौती आज़माएँ: भाग 1 का डिज़ाइन बनाएँ और उसका बचाव करें, फिर उसकी तुलना मेरे डिज़ाइन से करें, और देखें कि अध्याय 4 के लैंडस्केप से क्या बदलता है।

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

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

• हर अहम एट्रिब्यूट के लिए कौन-सा सिस्टम आधिकारिक है, और यह मॉडल में कैसे दिखता है।
• हर डेटा डोमेन के लिए मास्टरिंग की कौन-सी शैली ठीक है, और मास्टरिंग लेयर को कितना अधिकार मिलता है।
• कब merge करें, कब जोड़ें, और हर सर्वाइवरशिप नियम का मालिक कौन है।
• मैचिंग कितनी सख़्त हो, इस आधार पर कि गलत मैच की कीमत क्या है।
• कहाँ दोतरफ़ा डेटा और साझा हायरार्की को साफ़ सीमाओं की ज़रूरत है।

परीक्षा से आगे: एजेंटों को काम करने के लिए एक पहचान चाहिए, और इससे दोनों तरफ़ दाँव बढ़ जाता है। ज़रूरत से ज़्यादा मैचिंग एक प्राइवेसी घटना बन जाती है, और जो एजेंट “ग्राहक को अपडेट करता है” उसे हर एट्रिब्यूट के system of record में लिखना होता है, यूनिफ़ाइड प्रोफ़ाइल में नहीं। हर मॉड्यूल इस बात के साथ खत्म होता है कि AI क्या बदलता है।

और जानें

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) और Identity Resolution Reconciliation Rules (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।

अगला: भाग 2 स्केल के लिए डिज़ाइन (coming soon) से शुरू होता है।