खराब डेटा को बाहर रखना

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

मॉड्यूल 2 (कुल 6 में से) — अध्याय डेटा गुणवत्ता और गवर्नेंस, Data Architect कोर्स का अध्याय 5। हर मॉड्यूल अपने आप में पूरा है। पिछला: गवर्नेंस org में डिज़ाइन की जाती है · अगला: अपने डेटा को जानें

यह मॉड्यूल किस सवाल का जवाब देता है: डेटा को अच्छा कैसे रखें, और हमेशा वैसा ही कैसे बनाए रखें?

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

“काफ़ी अच्छा” एक बिज़नेस परिभाषा है

खराब डेटा को रोकने से पहले, अच्छे को परिभाषित करें। कोई एक परिभाषा नहीं है। अच्छे का मतलब हो सकता है: प्रक्रिया चलाने लायक पूरा, फ़ैसला लेने लायक सटीक, वर्कलोड के लिए काफ़ी ताज़ा, दूसरे सिस्टमों के साथ जोड़ने लायक एकरूप, यह जानने लायक यूनिक कि हम किस ग्राहक की बात कर रहे हैं, ऑटोमेशन के लिए काफ़ी मानक, और यह जानने लायक ट्रेस करने योग्य कि वह कहाँ से आया। यह डेटा पर निर्भर करता है। अगर Steve Trucking किसी रिटेल पार्टनर को बिल भेज रहा है, तो पार्टनर की कानूनी पहचान सही होनी चाहिए। अगर कोई रिप मीटिंग के बाद नोट्स लिख रहा है, तो किसी को हर वाक्य मंज़ूर करने वाली कमेटी की ज़रूरत नहीं है। “काफ़ी अच्छा” एक बिज़नेस परिभाषा है; आर्किटेक्ट उसे मापने और लागू करने लायक बनाता है।

महँगी गलतियों को रोकें

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

खुला या बंद?

Account बनाना इसका क्लासिक उदाहरण है। क्या हर सेल्सपर्सन Account बना पाए? मेरा जवाब: यह डेटा के आसपास की गवर्नेंस पर निर्भर करता है। ज़्यादातर छोटे और मझोले org के लिए खुला क्रिएशन ठीक है। एक रिप किसी संभावित ग्राहक से मिलता है, Account बनाता है, काम पर लग जाता है; CRM इसी के लिए है। डुप्लिकेट रूल, अनिवार्य जानकारी और स्टीवर्डशिप गुणवत्ता संभालते हैं। मैं सिर्फ़ इसलिए कोई भारी-भरकम मंज़ूरी प्रक्रिया नहीं जोड़ता कि गवर्नेंस सुनने में ज़िम्मेदार लगती है।

अब लैंडस्केप बदलिए। कानूनी ग्राहक ERP में मास्टर है, ERP पहचानकर्ता के साथ Salesforce में आता है, और ERP आधिकारिक है। अब खुले क्रिएशन का मतलब है एक ही गवर्न की गई इकाई को बनाने के दो रास्ते। जब ERP और एक रिप दोनों एक ही कंपनी बनाएँ, तो कौन जीतता है, इंटीग्रेशन कौन-सा पहचानकर्ता इस्तेमाल करते हैं, इतिहास किस रिकॉर्ड में रहता है? खुला क्रिएशन अब इस्तेमाल में आसानी का सवाल नहीं रहता, मास्टर डेटा का सवाल बन जाता है। जब Account किसी ERP में मास्टर होते हैं या उसके साथ सिंक होते हैं, तो क्रिएशन बंद करें।

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

बीच का रास्ता: एक अस्थायी रिकॉर्ड टाइप

यह रहा बीच का रास्ता जो मुझे पसंद है। सेल्स को एक खास रिकॉर्ड टाइप, यानी prospect या provisional (अस्थायी) टाइप, के तहत Account बनाने दें, और उसके गवर्न वाले टाइप में बदलने को नियंत्रित करें। सेल्स कंपनी को दर्ज करता है और बेचना शुरू कर देता है। रिकॉर्ड साफ़ कहता है: अभी आधिकारिक सिस्टम में स्थापित नहीं हुआ। फिर एक नियंत्रित प्रक्रिया उसे बदलती है: Finance उसे मंज़ूर करता है, या कोई इंटीग्रेशन उसे ERP को भेजता है, जो या तो उसे किसी मौजूदा ग्राहक से मिलाता है या नया बनाता है और आधिकारिक पहचानकर्ता वापस भेजता है। अब रिकॉर्ड एक सीमा पार करता है, अस्थायी → गवर्न किया गया, जो उस स्थिति से बहुत अलग है जहाँ दो सिस्टम अपने-अपने हिसाब से मास्टर रिकॉर्ड बना रहे हों।

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

हर फ़्लो के लिए एक रिकॉर्ड टाइप

पूरे फ़्लो को एक तस्वीर पर रखें और आप देखेंगे कि यह क्यों काम करता है। ग्राहक और प्रोडक्ट ERP से अंदर आते हैं। Opportunity और उनके लाइन आइटम बाहर जाते हैं और ERP के ऑर्डर बनते हैं। और Account? कुछ अंदर आते हैं, कुछ बाहर जाते हैं। इसलिए एक आम पैटर्न जो मैंने कई इम्प्लीमेंटेशन में देखा है, वह है Account पर दो रिकॉर्ड टाइप, हर दिशा के लिए एक। एक Sales Account Salesforce में जन्म लेता है: रिप उसे बनाते हैं, बदलते हैं, उसे बेचते हैं, और जब वह ग्राहक बनता है तो उसे ERP को भेजा जाता है। एक ERP Account (मैंने इसे Customer, या सीधे SAP कहा है) ERP में जन्म लेता है और इंटीग्रेशन से अंदर आता है। वह रिकॉर्ड टाइप इंटीग्रेशन के सिवा कोई नहीं बनाता, और उसके मास्टर डेटा फ़ील्ड (कानूनी नाम, पते, भुगतान की शर्तें) यूज़र्स के लिए सिर्फ़ पढ़ने लायक होते हैं। रिकॉर्ड टाइप बताता है कि रिकॉर्ड किस ओर बहता है, तो मास्टरिंग की दिशा रिकॉर्ड पर ही दिख जाती है।

Click to enlarge

हर फ़्लो के लिए एक रिकॉर्ड टाइप: Sales Account बाहर जाते हैं, ERP Account अंदर आते हैं।

यह मुश्किल मामले को खत्म नहीं करता। एक रिप Steve’s Plumbing के लिए एक lead कन्वर्ट करता है, लेकिन Steve’s Plumbing पहले से एक ERP Account के रूप में मौजूद है, और किसी तरह डुप्लिकेट जाँच उसे पकड़ नहीं पाई। अब आप मर्ज कर रहे हैं, चाइल्ड रिकॉर्ड को नए पैरेंट से जोड़ रहे हैं और तय कर रहे हैं कि कौन-सा रिकॉर्ड बचेगा (अध्याय 6, मॉड्यूल 3)।

और खुद रिकॉर्ड टाइप पर अटके न रहें। आम तौर पर मैं रिकॉर्ड टाइप से बचता हूँ, जब तक उनके पक्ष में मज़बूत वजह न हो। मैंने उन्हें यहाँ इसलिए इस्तेमाल किया क्योंकि Dynamic Forms से पहले रिकॉर्ड टाइप ही पेज लेआउट चुनता था, और एक लेआउट ERP फ़ील्ड को सिर्फ़ पढ़ने लायक दिखाता था। Dynamic Forms के साथ, visibility रूल किसी फ़ील्ड की वैल्यू के हिसाब से फ़ील्ड दिखा और छिपा सकते हैं, किसी फ़ील्ड को किसी खास पेज पर सिर्फ़ पढ़ने लायक बनाया जा सकता है, और खुद Salesforce कहता है कि Dynamic Forms से ज़रूरी पेज लेआउट और रिकॉर्ड टाइप की संख्या घटती है (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab))। लेकिन किसी पेज पर सिर्फ़ पढ़ने लायक का मतलब है उसी पेज पर सिर्फ़ पढ़ने लायक: API, कोई डेटा लोड या कोई इंटीग्रेशन अब भी उस फ़ील्ड में लिख सकता है। असली लागू करना फ़ील्ड-लेवल सिक्योरिटी या वैलिडेशन रूल से होता है; UI वैलिडेशन डेटा वैलिडेशन नहीं है (अध्याय 3, मॉड्यूल 9)। रिकॉर्ड टाइप अब भी तब अपनी जगह कमाते हैं जब दोनों तरह के Account को अलग पिकलिस्ट वैल्यू या बिज़नेस प्रोसेस चाहिए। जो सच में मायने रखता है, वह यह है कि कोई फ़ील्ड साफ़ बताए कि रिकॉर्ड कहाँ से आया: खुद ERP की key, एक मास्टर-डेटा फ़्लैग, या एक सोर्स पिकलिस्ट। फिर बदलाव की अनुमति उसी फ़ील्ड से चलाएँ।

Click to enlarge

अस्थायी से गवर्न किया गया: सेल्स तुरंत बेचना शुरू करता है; सिर्फ़ आधिकारिक प्रक्रिया रिकॉर्ड को गवर्न किया गया बनाती है।

गवर्न किए गए रिकॉर्ड की रक्षा करें

जब ग्राहक ERP से वापस आता है, तो उसका ERP ID, कानूनी नाम, टैक्स पहचानकर्ता और बिलिंग विवरण गवर्न किए गए एट्रिब्यूट हैं। क्या रिप को उन्हें बदलना चाहिए? नहीं, अगर उनका मालिक ERP है। यही मॉड्यूल 1 की वह नीति है जिसे लागू करने का बिंदु चाहिए: ERP ID सिर्फ़ पढ़ने लायक, कानूनी पहचान नियंत्रित, जबकि रिप अब भी टेरिटरी, रिश्तों के नोट्स और Salesforce के अपने वर्गीकरण बदलता है। लक्ष्य कोई अछूता Account नहीं है। लक्ष्य उस डेटा जिसका मालिक Salesforce है और उस डेटा जिसका Salesforce सिर्फ़ हवाला देता है के बीच एक साफ़ रेखा है। (अध्याय 4 का erp_ प्रीफ़िक्स वह रेखा स्कीमा में दिखाता है।)

आखिर में आपके पास जो गोल्डन रिकॉर्ड होता है, वह असल में एक हाइब्रिड है। ERP के मास्टर-डेटा फ़ील्ड अंदर आते हैं: कानूनी नाम, बिलिंग और शिपिंग पते, भुगतान की शर्तें। फिर Salesforce अपने फ़ील्ड जोड़ता है जो कभी वापस नहीं जाते: एक सेल्स रेटिंग, आखिरी ऑर्डर की तारीख, और लगभग वह सब कुछ जो मार्केटिंग इस्तेमाल करती है। एक ही Account, दो तरह के फ़ील्ड, और हर तरह का एक ही स्रोत।

सबसे मुश्किल हैं दोतरफ़ा फ़्लो (bi-directionals)। मान लीजिए एक रिप को ERP में कानूनी नाम Steve’s Plumbing से Steve’s Plumbing LLC करवाना है। उन्हीं पाँच मिनटों में ERP में कोई उसे Steve’s Plumbing L.L.C. कर देता है। किसका बदलाव जीतता है? सोच यह रखें: अगर कोई फ़ील्ड ERP में मास्टर है, तो आप फ़ील्ड बदल नहीं रहे, उसे बदलने का अनुरोध कर रहे हैं। तय करें कि अनुरोध टकराने पर क्या होता है: ERP जीतता है, अगर इस बीच वैल्यू बदल गई तो अनुरोध खारिज होता है, या वह किसी व्यक्ति के सुलझाने का इंतज़ार करता है। और तय करें कि जुड़े हुए फ़ील्ड एक बदलाव के रूप में साथ जाते हैं या एक-एक करके। अध्याय 6 टकरावों को और आगे ले जाता है (लूप और टक्करें)।

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

डुप्लिकेट बढ़ते जाते हैं। बनने से पहले पकड़ लें, तो छोटी समस्या है। दो साल बाद मिले, जब दोनों से opportunity, केस, कॉन्टैक्ट, इनवॉइस, इंटीग्रेशन और एनालिटिक्स जुड़े हों, तो बड़ी समस्या है। अध्याय 3 के मॉड्यूल 7 ने तरीके (मैचिंग रूल, डुप्लिकेट रूल, यूनिक External ID) कवर किए थे, इसलिए मैं उन्हें दोबारा नहीं पढ़ाऊँगा। गवर्नेंस का सवाल यह है: हमें कहाँ डुप्लिकेशन रोकना ही है, और कहाँ हम उसे सहकर बाद में सुलझाएँगे? मार्केटिंग का कोई साधारण lead अस्पष्टता के साथ जी सकता है। वित्तीय लेन-देन वाला, ERP से गवर्न किया गया ग्राहक नहीं।

जो मशीनें पढ़ती हैं, उसे मानक बनाएँ

फ़्री टेक्स्ट लोगों के लिए शानदार है और तब बेहद खराब जब किसी सिस्टम को उसका मतलब निकालना हो। रूटिंग चलाने वाले किसी फ़ील्ड में Arizona, AZ, Ariz., Phoenix area और Southwest डाल दें, और आपके पास गुणवत्ता की समस्या है। अगर कोई वैल्यू ऑटोमेशन, इंटीग्रेशन, रिपोर्टिंग, सिक्योरिटी, असाइनमेंट या किसी एजेंट की कार्रवाई चलाती है, तो अच्छी तरह सोचें कि उसे कितना मानक होना चाहिए। हर टेक्स्ट फ़ील्ड पिकलिस्ट नहीं बनता, लेकिन लोगों के पढ़ने वाली जानकारी और मशीनों के फ़ैसले वाली जानकारी में फ़र्क करें। दूसरी वाली मज़बूत कंट्रोल की हकदार है।

अनिवार्य फ़ील्ड को नकली डेटा न बनाने दें

हम तय करते हैं कि कोई फ़ील्ड मायने रखता है और उसे अनिवार्य बना देते हैं। यूज़र को जवाब नहीं पता, सिस्टम उसे आगे बढ़ने नहीं देता, तो वह N/A, Unknown, 999999 या test@test.com टाइप कर देता है। फ़ील्ड भरा हुआ है; डेटा कचरा है। कोई चीज़ अनिवार्य करने से पहले पूछें कि क्या उस समय यूज़र को वह सच में पता है। अगर नहीं, तो उसे प्रक्रिया में बाद में अनिवार्य करें, किसी दूसरे सिस्टम को वह देने दें, अस्थायी स्थिति इस्तेमाल करें, या जब “पता नहीं” एक जायज़ जवाब हो, तो साफ़ Unknown का विकल्प दें। वैलिडेशन रूल किसी नीति को लागू कर सकता है। वह किसी को वह नहीं सिखा सकता जो उसे पता ही नहीं।

डेटा की हर सीमा को गुणवत्ता का एक फ़ैसला चाहिए

खराब डेटा का स्रोत सिर्फ़ लोग नहीं हैं; इंटीग्रेशन उसे और तेज़ी से बनाते हैं। किसी रिटेल पार्टनर का मैनिफ़ेस्ट कुछ सौ लाइनों के साथ आता है। कुछ में पिन कोड गलत हैं, एक-दो किसी अनजान डिस्ट्रिब्यूशन सेंटर का नाम लेती हैं, दो में एक ही ऑर्डर रेफ़रेंस दोहराया गया है। क्या होगा? पूरी फ़ाइल खारिज करें? अच्छी लाइनें लें और खराब लौटा दें? सब कुछ लोड करें और बाद में साफ़ करें? अपवादों को अलग (quarantine) करें? किसे बताया जाता है, और पार्टनर को कैसे पता चलता है कि क्या फ़ेल हुआ? कोई सार्वभौमिक जवाब नहीं है, लेकिन कोई जवाब होना ज़रूर चाहिए। अध्याय 4 ने कहा था कि हर तीर को एक तरीका चाहिए। इसमें जोड़ें: डेटा की हर सीमा को गुणवत्ता का एक फ़ैसला चाहिए: हम क्या स्वीकार करते हैं, क्या खारिज करते हैं या अलग करते हैं, और अपवाद का मालिक कौन है।

Click to enlarge

डेटा की हर सीमा को गुणवत्ता का एक फ़ैसला चाहिए।

ऐतिहासिक डेटा अलग है

RouteDesk में Steve Trucking का आठ साल का इतिहास है, और उसकी गुणवत्ता हर डिस्ट्रिब्यूशन सेंटर में अलग है। क्या उसे ले जाने से पहले हम आठों साल को आज के मानक तक साफ़ करें? शायद अपने आप नहीं। यह किसलिए है: रोज़ के ऑपरेशन, संदर्भ, क्लेम, रिपोर्टिंग, ट्रेंड विश्लेषण? क्या सारा Salesforce में होना चाहिए, या कुछ कहीं और रह सकता है? माइग्रेशन वाला अध्याय इसमें गहराई से जाता है। गवर्नेंस की बात यह है: इतिहास को अपने आप उसी मानक की ज़रूरत नहीं जो सक्रिय डेटा की है। अगर आप उससे फ़ैसले लेंगे, तो गुणवत्ता मायने रखती है। अगर आप उसे संदर्भ के लिए रख रहे हैं, तो कोई दूसरा मानक चल सकता है। अतीत को साफ़ करने पर ढेर सारा पैसा खर्च करने से पहले मकसद जानें।

वही मापें जिस पर कोई कार्रवाई करेगा

गवर्नेंस कभी पूरी नहीं होती, इसलिए आपको देखना होगा कि गुणवत्ता कब फिसलती है: डुप्लिकेट दर बढ़ रही है, quarantine में ज़्यादा रिकॉर्ड, इंटीग्रेशन से ज़्यादा रिजेक्ट, placeholder वैल्यू फैल रही हैं, नियम से बचने के ज़्यादा अनुरोध, रिपोर्टें जो अब आपस में मेल नहीं खातीं। लेकिन 150 मेट्रिक बनाकर उनमें से 143 को नज़रअंदाज़ न करें। Steve Trucking के लिए शायद ये हों: बिना वैध पार्टनर रेफ़रेंस वाली डिलीवरी, बिना काम लायक पते वाली डिलीवरी, दोहराए गए ऑर्डर रेफ़रेंस, खारिज हुए पार्टनर संदेश, अस्थायी स्थिति में अटके Account। हरे गोलों से भरे डैशबोर्ड का मतलब यह नहीं कि डेटा अच्छा है। वही मापें जिस पर कोई कार्रवाई करने को तैयार है।

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

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

• गुणवत्ता की कौन-सी विफलताएँ इतना नुकसान करती हैं कि रोकथाम वाले कंट्रोल जायज़ हों।
• गवर्न किए गए रिकॉर्ड खुलकर बनते हैं, सिर्फ़ आधिकारिक सिस्टम से बनते हैं, या अस्थायी-से-गवर्न वाले रास्ते से।
• कौन-से एट्रिब्यूट का मालिक Salesforce है और किनका वह सिर्फ़ हवाला देता है।
• जाँच में फ़ेल होने वाले आने वाले डेटा का क्या होता है (स्वीकार, खारिज या अलग) और अपवाद का मालिक कौन है।
• गुणवत्ता के कौन-से संकेत मापे जाते हैं, ताकि स्टीवर्ड फिसलन देख सकें।

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

और जानें

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) और Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।