मैचिंग, मर्जिंग और सर्वाइवरशिप

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: डुप्लिकेट कैसे ढूँढें, और कैसे तय करें कि कौन-से मान बचे रहें?

Salesforce में दो contacts हैं: Daniel Reyes, Dallas, d.reyes@example.com, और Dan Reyes, Dallas, d.reyes@example.com। एक ही व्यक्ति? शायद। क्या हमें उन्हें merge करना चाहिए? यह एक अलग सवाल है। और अगर करते हैं, तो कौन-सा फ़ोन नंबर, पता और पदनाम बचा रहेगा? यह फिर अलग सवाल है। आर्किटेक्ट को तीन फ़ैसले अलग-अलग रखने होते हैं:

• मैचिंग: क्या ये रिकॉर्ड एक ही चीज़ को दर्शाते हैं?
• मर्जिंग: क्या इन्हें एक रिकॉर्ड बन जाना चाहिए?
• सर्वाइवरशिप: अगर हम डेटा मिलाते हैं, तो कौन-से मान जीतेंगे?

मैचिंग पहले आती है

अध्याय 3 ने Salesforce के डुप्लिकेट रूल और मैचिंग रूल कवर किए थे, इसलिए मैं उनका तरीका दोबारा नहीं पढ़ाऊँगा। आर्किटेक्चर का सवाल यह है कि कौन-सा सबूत इतना मज़बूत है कि कहा जा सके ये एक ही हो सकते हैं? एक व्यक्ति के लिए: ईमेल, फ़ोन, नाम और पता, एक ग्राहक नंबर, कोई मेल। एक कंपनी के लिए: कानूनी नाम, टैक्स ID, ERP ग्राहक ID, पता, वेब डोमेन। सवाल यह नहीं कि “क्या Salesforce इन फ़ील्ड की तुलना कर सकता है?” बल्कि यह कि “कौन-सा मेल हमें इतना भरोसा देता है कि हम कदम उठा सकें?”

और हूबहू मेल का मतलब पक्का नहीं है। साझा ईमेल एक मज़बूत संकेत है, सबूत नहीं: परिवार एक ही पता साझा करते हैं, कंपनियाँ purchasing@company.com इस्तेमाल करती हैं, फ़ोन नंबर पूरे घर के होते हैं, नाम और पते यूनिक नहीं होते, और मज़बूत ID भी दोबारा इस्तेमाल होते हैं, गलत टाइप होते हैं या फिर से बाँट दिए जाते हैं। मैचिंग स्ट्रिंग की तुलना नहीं है। यह पहचान के बारे में एक बयान है।

गलत होने की कीमत

जब मैं यह पढ़ाता हूँ, तो डोमेन बदल देता हूँ। ऑटोमोटिव मार्केटिंग डेटा में हम गलती से तय कर देते हैं कि दो Daniel Reyes एक ही व्यक्ति हैं, और गलत व्यक्ति को एक SUV का ऑफ़र चला जाता है। अच्छा नहीं, लेकिन जोखिम कम। अब वही गलत मैच मेडिकल डेटा में कीजिए: दो अलग-अलग लोगों का मेडिकल इतिहास एक में मिल गया। वही मैचिंग की गलती, बिल्कुल अलग नतीजा। इसीलिए मैचिंग की कोई सार्वभौमिक “अच्छी” सीमा नहीं है। कभी बड़ा जोखिम एक मैच चूक जाना है; कभी दो ऐसे लोगों को मिला देना जो एक नहीं हैं। जहाँ गलत मैच महँगे हैं, वहाँ मैं जान-बूझकर कम मैच करता हूँ।

पहले सामंजस्य, फिर मैच, फिर कंसॉलिडेट

मैचिंग डेटा के आकार पर भी निर्भर करती है। AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198। सामंजस्य (harmonization) मानों को तुलना के लायक बनाता है: स्टैंडर्ड फ़ॉर्मेट, एक जैसे संक्षिप्त रूप, मैप किए गए कोड। फिर आप मैच करते हैं। जब पता चल जाए कि रिकॉर्ड एक साथ हैं, तभी आप उनकी जानकारी को एक रूप में कंसॉलिडेट करते हैं। सामंजस्य मैचिंग नहीं है, मैचिंग merge नहीं है, और कंसॉलिडेट करना ज़रूरी नहीं कि मास्टर करना हो।

Click to enlarge

पहचान के फ़ैसले चरणों में होते हैं।

मैच का मतलब merge ज़रूरी नहीं

यह इस अध्याय के सबसे अहम अंतरों में से एक है। हमें भरोसा है कि दो पुराने सिस्टमों से आए दो ग्राहक रिकॉर्ड एक ही कंपनी हैं। क्या हमें उन्हें merge करना ही होगा? नहीं। हर एक के पास अपने स्रोत सिस्टम का ID हो सकता है; पुराने ट्रांज़ैक्शन दोनों में से किसी की ओर इशारा कर सकते हैं; ऑडिटरों को रिकॉर्ड का निशान चाहिए हो सकता है; हो सकता है हम अभी माइग्रेट कर रहे हों; हमें ठीक-ठीक जानना पड़ सकता है कि पुराना सिस्टम क्या कहता था। यह जानना कि दो रिकॉर्ड एक ही चीज़ हैं, हमें उन्हें एक में समेटने पर मजबूर नहीं करता। हम उन्हें जोड़ (link) सकते हैं, और अक्सर यही ज़्यादा सुरक्षित आर्किटेक्चर है।

Merge का मेरा नियम: एक साफ़ विजेता

मेरी राय: merge तभी करें जब एक साफ़ विजेता हो और डुप्लिकेट में ऐसा कुछ न हो जिसे आपको रखना है। एक rep ने कल एक डुप्लिकेट account बना दिया; मूल रिकॉर्ड साफ़ तौर पर स्थापित रिकॉर्ड है। Merge के लिए अच्छा उम्मीदवार। अब इसे बदलिए: हमने एक legacy सिस्टम से ग्राहक इम्पोर्ट किए, उनके अपने ID, पुराने मान, और शायद उनसे जुड़े ट्रांज़ैक्शन या ऑडिट की ज़रूरतें। अब मैं कहीं ज़्यादा सावधान हूँ। बाहरी लोड से आए डुप्लिकेट तब रखें जब आपको पुराने मानों तक वापस ट्रेस करना पड़ सकता है, क्योंकि merge वह इतिहास मिटा देता है।

Salesforce merge असल में क्या करता है

लिंक कहता है “ये एक साथ हैं।” Merge कहता है “ये अब एक हैं,” और Salesforce पर यह एक असली बदलाव है। Accounts के लिए आप तीन तक रिकॉर्ड चुनते हैं और उनमें से एक को principal (मुख्य रिकॉर्ड) बनाते हैं; आप चुनते हैं कि बाकियों के कौन-से फ़ील्ड मान रखने हैं, जबकि hidden और read-only फ़ील्ड principal से आते हैं। Merge हुआ रिकॉर्ड सबसे पुराने रिकॉर्ड का Created By और Created Date रखता है, चाहे principal कोई भी हो। Non-principal रिकॉर्ड Recycle Bin में चले जाते हैं। Activities जैसे संबंधित रिकॉर्ड merge हुए रिकॉर्ड पर चले जाते हैं, कुछ अपवादों के साथ। Lightning में merge उन डुप्लिकेट पर काम करता है जिन्हें आपके डुप्लिकेट रूल पकड़ते हैं। और person accounts के लिए, contact point objects merge को सपोर्ट नहीं करते: उनके संबंध खो जाते हैं (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab))।

परीक्षा-ज्ञान। जानें कि Salesforce account merge क्या करता है: तीन तक रिकॉर्ड; एक principal, जिसके hidden और read-only फ़ील्ड रखे जाते हैं; सबसे पुराने रिकॉर्ड का Created By और Created Date, चाहे principal कोई भी हो; बाकी रिकॉर्ड Recycle Bin में जाते हैं; और person accounts के लिए contact point objects merge नहीं होते।

फ़ैसला लेने के लिए आपको हर किनारे का मामला जानने की ज़रूरत नहीं। आपको नतीजा जानना है: merge के बाद, जिन स्वतंत्र रिकॉर्ड से आपने शुरुआत की थी, वे खत्म हो जाते हैं। अध्याय 1 की पलटने की कसौटी लागू होती है: लिंक करना आसानी से पलटा जा सकता है; merge नहीं। और ग्राहक शायद ही कभी अकेला होता है: contacts, cases, opportunities, फ़ाइलें, consent रिकॉर्ड, कस्टम children, External ID, इंटीग्रेशन रेफ़रेंस। Parent को merge करने से पहले समझें कि उससे जुड़ी हर चीज़ का क्या होता है। जब डुप्लिकेट किसी लोड के साथ आते हैं, तो मैं टीमों को children के लिए तीन विकल्प देता हूँ: उन्हें बचे हुए रिकॉर्ड पर ले जाएँ; उन्हें लोड ही न करें, अगर किसी को उनकी ज़रूरत नहीं; या उन्हें दूसरे रिकॉर्ड पर ही रहने दें, निष्क्रिय चिह्नित करके, ताकि वे सर्च में फिर भी दिखें। पहला वही है जो merge आपके लिए करता है। बाकी दो निशान बचाए रखते हैं, और अक्सर मकसद यही होता है।

सर्वाइवरशिप: कौन-सा मान जीतता है?

रिकॉर्ड एक साथ हैं, लेकिन असहमत हैं: Salesforce और बिलिंग कहते हैं 602-555-0100, ERP कहता है 602-555-0188। सर्वाइवरशिप नियम विजेता चुनते हैं। आम नियम: सबसे नया (आखिरी अपडेट), सबसे ज़्यादा बार (वह मान जिस पर ज़्यादातर स्रोत सहमत हैं), और स्रोत की प्राथमिकता (इस स्रोत पर उससे ज़्यादा भरोसा करो), साथ में इनके मेल, सीमाएँ, वज़न और बिज़नेस के खास नियम। इनमें से कोई भी अपने आप में सही नहीं है।

“सबसे नया” कोई टेक्निकल सेटिंग नहीं है। यह भरोसे के बारे में एक बयान है: जब सिस्टम असहमत हों, तो सबसे नए मान के सही होने की संभावना ज़्यादा है। मोबाइल नंबर के लिए ठीक। कानूनी नाम के लिए भयानक: अगर उसका मालिक ERP है, तो मुझे फ़र्क़ नहीं पड़ता कि किसी ने पाँच मिनट पहले Salesforce की कॉपी बदली। “सबसे ज़्यादा बार” मानकर चलता है कि सहमति सबूत है, लेकिन तीन पुरानी पड़ चुकी downstream कॉपियाँ स्रोत रिकॉर्ड को वोट में नहीं हरा सकतीं। “स्रोत की प्राथमिकता” इसे सीधे कहती है: हम इस स्रोत पर ज़्यादा भरोसा करते हैं। इसलिए सर्वाइवरशिप आर्किटेक्चर और गवर्नेंस का हिस्सा है, और हर नियम का एक मालिक होना चाहिए। किसने तय किया कि सबसे नया पता जीतेगा, या कि ERP का दर्जा Salesforce से ऊपर है?

अगर मॉड्यूल 1 का अधिकार-मानचित्र पहले से कहता है कि क्रेडिट लिमिट का मालिक ERP है, तो सर्वाइवरशिप आसान है: ERP जीतता है, किसी चतुर स्कोरिंग की ज़रूरत नहीं। कठिन मामले वे एट्रिब्यूट हैं जिनका अधिकार साझा है, अस्पष्ट है, या किसी एक मास्टर के बजाय सबूत पर टिका है। वहीं सर्वाइवरशिप नियम अपनी उपयोगिता साबित करते हैं।

Click to enlarge

सर्वाइवरशिप नियम भरोसे के बारे में बयान हैं।

सीमाएँ, समीक्षा और संवर्धन

कुछ मैचिंग सबूत को तौलती है: ग्राहक ID का मेल बहुत मज़बूत, ईमेल मज़बूत, फ़ोन मध्यम, मिलता-जुलता नाम कमज़ोर, मिलता-जुलता पता सहायक। एक स्कोर से ऊपर, मैच; दूसरे से नीचे, अलग; बीच में, कोई व्यक्ति समीक्षा करता है। एल्गोरिद्म यहाँ सबक नहीं है। सीमा (threshold) गलती को सहने की आपकी क्षमता है, और इसे बिज़नेस के जोखिम के हिसाब से चलना चाहिए। और जब सबूत सवाल तो उठाए पर उसे सुलझाए नहीं, तो यह दिखावा न करें कि सिस्टम जानता है। उसे समीक्षा के लिए भेजें। धीमा, और यह ठीक है: ऑटोमेशन तब कोई काम का नहीं जब वह पूरे भरोसे से दो अलग ग्राहकों को merge कर दे।

संवर्धन (enrichment) उद्गम का एक और सवाल जोड़ता है। डाक का रेफ़रेंस डेटा, इंडस्ट्री कोड, कंपनियों की जानकारी (firmographics), बाहरी जोखिम स्कोर मास्टर डेटा को बेहतर बनाते हैं, लेकिन हर मान कहाँ से आया, वह कितना भरोसेमंद और ताज़ा है, क्या हम उसे इस मकसद के लिए इस्तेमाल कर सकते हैं, क्या उसमें निजी डेटा है? किसी डेटा प्रोवाइडर से आया “Industry = Transportation” वैसा नहीं है जैसा ग्राहक का ख़ुद आपको बताना। यह अंतर बनाए रखें।

Steve Trucking: मिलता-जुलता, एक जैसा नहीं

दो रिटेल पार्टनर John Smith, 123 Main Street, Columbus को डिलीवरी भेजते हैं, एक ही फ़ोन नंबर के साथ। एक ही व्यक्ति? शायद। क्या Steve Trucking को उन्हें एकीकृत करना चाहिए? याद रखें कि वे किसके हैं: वे प्राप्तकर्ता पार्टनर्स के ग्राहक हैं, और एक पार्टनर को कभी दूसरे के ग्राहक नहीं दिखने चाहिए। एक गलत मैच उस सीमा के पार डेटा घोल देगा। अचानक यह डेटा गुणवत्ता का सवाल नहीं, बल्कि प्राइवेसी और अलगाव का सवाल बन जाता है, और ठीक इसीलिए सीमाएँ नतीजों पर निर्भर करती हैं। फ़ैसला चेकपॉइंट पर होगा। अभी के लिए: मैचिंग की सुविधा को बिज़नेस का फ़ैसला न लेने दें।

कभी-कभी गड़बड़ी को बनाए रखना भी आपको कुछ बताता है। यह रिकॉर्ड पुराने सिस्टम से आया, वह Salesforce से, यह खरीदी गई कंपनी से; उनके ID, उनका इतिहास और यह तथ्य कि वे असहमत थे, सब मायने रख सकते हैं। साफ़ डेटा क़ीमती है। ट्रेस कर पाना भी। आर्किटेक्ट तय करता है कि उस इस्तेमाल के लिए क्या ज़्यादा मायने रखता है।

परीक्षा से आगे: AI क्या बदलता है। पहले खराब मैच का मतलब होता था दो ईमेल या बँटा हुआ सर्विस इतिहास। अब एक एजेंट उसे ढूँढता है जिसे वह ग्राहक समझता है और उसके ऑर्डर, cases, पते और नोट्स खींच लाता है। अगर दो लोग गलती से मैच हो गए, तो वह एक व्यक्ति की जानकारी पर दूसरे के लिए कदम उठा सकता है। मैचिंग का फ़ैसला अब सिक्योरिटी की सीमा का हिस्सा बन गया है, और जहाँ घुल-मिल जाना महँगा है, वहाँ ज़्यादा सख़्त मैचिंग ज़्यादा सुरक्षित डिज़ाइन है।

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

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

सावधानी से मैच करें, सोच-समझकर merge करें, सर्वाइवरशिप नियम इरादे से चुनें। एक साफ़ ग्राहक रिकॉर्ड की ज़्यादा क़ीमत नहीं अगर आप वहाँ गलत ग्राहकों को मिलाकर पहुँचे हैं।

और जानें

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) और Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।