डेटा को सुसंगत रखना

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: मैं डेटा को सुसंगत कैसे रखूँ, और हर परत की कीमत क्या है?

हर कोई साफ़ डेटा चाहता है। मैं कभी किसी ऐसी requirements मीटिंग में नहीं गया जहाँ किसी ने कहा हो, “हमें असल में असंगत डेटा चाहिए।” असहमति बाद में आती है: नियम हम लागू कहाँ करें? स्क्रीन पर? एक required फ़ील्ड? एक पिकलिस्ट, एक वैलिडेशन रूल, एक डुप्लिकेट रूल, एक flow, Apex? ये सब मदद करते हैं। ये एक-दूसरे की जगह नहीं ले सकते, और हर परत की एक कीमत है।

मेरा आम नियम है कि नियम को जितना नीचे उचित रूप से ले जा सकें, ले जाएँ। अगर कोई मान हमेशा पाँच चीज़ों में से एक ही हो सकता है, तो लोगों को कुछ भी टाइप करने न दें और फिर बाद में ऑटोमेशन से सफ़ाई न करें। अगर दो रिकॉर्ड में कभी एक ही पहचानकर्ता नहीं होना चाहिए, तो किसी के रिपोर्ट में उसे पकड़ने पर भरोसा न करें। अगर किसी नियम को हर हाल में लागू होना है, चाहे रिकॉर्ड किसी स्क्रीन, API, इंटीग्रेशन, डेटा लोड या एजेंट से आए, तो उसे सिर्फ़ UI में लागू न करें। नियम डेटा के जितना करीब होगा, उससे बचना उतना ही मुश्किल होगा। मैं इसे सुसंगतता की सीढ़ी (consistency ladder) कहता हूँ।

पहला डंडा: फ़ील्ड टाइप और शब्दावली

सुसंगतता का पहला नियम वही है जो मॉड्यूल 6 में था: सही टाइप चुनें। तारीख एक Date है, पल एक Date/Time है, पैसा Currency है। यह किसी के नियम लिखने से पहले की सुसंगतता है।

किसी डिलीवरी के status को text फ़ील्ड बनाइए, और आपको मिलेंगे Delivered, delivered, DELIVERED, Complete, Done और Dropped off, और किसी को पता लगाना पड़ेगा कि इन छह का मतलब एक ही है या नहीं। या शब्दावली एक बार तय करें: Delivered, एक मान, एक मतलब। इसे एक प्रतिबंधित पिकलिस्ट बनाएँ ताकि यह सूची से बाहर की हर चीज़ को अस्वीकार करे, API से भी, और जब कई फ़ील्ड एक ही सूची साझा करें तो एक ग्लोबल वैल्यू सेट (मॉड्यूल 6 में ब्योरा है)।

लेकिन सिर्फ़ लोगों को टाइप करने से रोकने के लिए पिकलिस्ट इस्तेमाल न करें। क्या यह सच में एक मान है, या एक और entity? नौ डिस्ट्रिब्यूशन सेंटर, हर एक का बस एक नाम, पिकलिस्ट जैसे लग सकते हैं; पते, मैनेजर, क्षमता और ट्रकों वाले नौ डिस्ट्रिब्यूशन सेंटर रिकॉर्ड हैं। नियम को मॉडल को मज़बूत करना चाहिए, किसी खराब मॉडल की भरपाई नहीं। और अगर यह सच में एक नियंत्रित शब्दावली है, तो उसे फ़ील्ड पर ही नियंत्रित करें। अव्यवस्था की छूट देकर फिर AZ, Arizona, Ariz और Phoenix area को उस मान में बदलने के लिए flow न बनाएँ जो आप शुरू से चाहते थे।

दूसरा डंडा: Required और Unique

Required और Unique इसलिए आकर्षक हैं क्योंकि ये सीधे हैं: बॉक्स पर टिक करें, समस्या हल। कभी-कभी। अगर हर ट्रक के पास बनने के दिन से एक fleet नंबर है, और किन्हीं दो ट्रकों का एक जैसा नहीं है, तो दोनों बॉक्स बिज़नेस के असली नियम दर्शाते हैं। यह मज़बूत सुसंगतता है।

लेकिन एक बार प्लेटफ़ॉर्म कोई नियम लागू कर दे, तो उसे इसकी परवाह नहीं कि आपके प्रोसेस में मंगलवार दोपहर को कोई अपवाद है। यह उदाहरण मैं सालों से क्लास में देता आया हूँ। एक ऑब्जेक्ट काफ़ी समय से है, ढेर सारे रिकॉर्ड के साथ। कोई एक फ़ील्ड जोड़ता है और Required पर टिक करता है। वे रिकॉर्ड बनाकर टेस्ट करते हैं: बढ़िया चलता है। फिर शनिवार रात, deployment, टेस्ट चलते हैं, और एक पुरानी test class नए फ़ील्ड के बिना ऑब्जेक्ट बनाती है। धड़ाम। या कोई उस फ़ील्ड के आने से पहले का कोई पुराना रिकॉर्ड एडिट करता है। या इंटीग्रेशन वही payload भेजता है जो वह पाँच साल से भेज रहा है। धड़ाम। “लेकिन हमने वह फ़ील्ड तो बदला ही नहीं।” प्लेटफ़ॉर्म को परवाह नहीं: आपने यह अनुबंध बदल दिया कि एक मान्य रिकॉर्ड क्या है। नया नियम सिर्फ़ नए डेटा पर असर नहीं डालता; वह बदल देता है कि आप पुराने डेटा के साथ क्या कर सकते हैं।

तीसरा डंडा: वैलिडेशन रूल

वैलिडेशन रूल से हम कहीं ज़्यादा समृद्ध बातें कह सकते हैं। अगर status Delivered है, तो असली डिलीवरी का समय भरा होना चाहिए। अगर स्टॉप एक इंस्टॉलेशन है, तो स्टॉप बंद करने से पहले checklist पूरी होनी चाहिए। ये रिकॉर्ड सेव होने पर चलते हैं, इसलिए ये रिकॉर्ड की रक्षा करते हैं, चाहे वह किसी पेज, API, डेटा लोड, इंटीग्रेशन या एजेंट से सेव हुआ हो। यही असली बात है। अगर नियम को रिकॉर्ड की रक्षा करनी है, तो उसे वहाँ रखें जहाँ हर write उससे टकराए।

इनके दाँत भी होते हैं। यही इनकी ताकत है और यही इनकी कीमत।

पुराने रिकॉर्ड की समस्या

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

इसलिए वैलिडेशन रूल को सिर्फ़ यह नहीं कहना चाहिए कि क्या सच होना चाहिए। उसे यह भी कहना चाहिए कि इसे कब लागू करना है। ISNEW() और ISCHANGED() जैसे functions आपको किसी नियम को नए रिकॉर्ड तक, या उन saves तक सीमित करने देते हैं जिनमें संबंधित फ़ील्ड सच में बदलते हैं (Validation Rule Considerations (opens in a new tab))।

लेकिन रिकॉर्ड सिर्फ़ तब नहीं बदलता जब कोई व्यक्ति उसे एडिट करता है, और इसकी कई वजहें आपके नियंत्रण से बाहर हैं। इंटीग्रेशन रात में status अपडेट करता है। एक flow कोई तारीख डाल देता है। एक मैनेजर किसी territory को दोबारा असाइन करता है और दस हज़ार रिकॉर्ड पर मालिक बदल जाता है। कोई डिलीवरी आइटम एडिट करता है, डिलीवरी पर roll-up दोबारा कैलकुलेट होता है, और इससे डिलीवरी सेव होती है, तो डिलीवरी का वैलिडेशन रूल ऐसे यूज़र के लिए चल पड़ता है जिसने उसे छुआ तक नहीं (Roll-Up Summary Field (opens in a new tab) चेतावनी देता है कि वैलिडेशन errors detail या master पर दिख सकती हैं)। इनमें से हर save आपके नए नियम से टकराता है। इसलिए हर नए नियम के लिए पूछें: क्या यह नियम उस save पर लागू होना चाहिए?

ये रहे विकल्प, और आप इन्हें नियम में बुनते हैं:

• हमेशा, हर save पर। तब सही जब नियम सच में रिकॉर्ड के बारे में हो और पुराना डेटा उस पर खरा उतरता हो। लेकिन जानें कि “हर save” का मतलब क्या है: एक batch job जो सिर्फ़ मालिक बदलता है, या रिकॉर्ड पर कहीं भी किसी फ़ील्ड का कोई छोटा-सा एडिट, उसे भी इससे पास होना होगा।
• सिर्फ़ नए रिकॉर्ड के लिए, ISNEW() से। नियम रिकॉर्ड को एक बार जाँचता है, जब वह बनता है, और फिर कभी नहीं। अतीत जैसा था वैसा रहता है, लेकिन भविष्य भी: बाद का कोई एडिट किसी नए रिकॉर्ड से नियम तुड़वा सकता है और कोई उसे नहीं रोकेगा। अगर यह मायने रखता है, तो इसे अगले वाले के साथ जोड़ें।
• सिर्फ़ तब जब उससे जुड़े फ़ील्ड बदलें, ISCHANGED() से। फ़ोन नंबर एडिट करने से डिलीवरी-समय वाला नियम नहीं जागता।
• कुछ खास लिखने वालों के लिए नहीं। एक custom permission, जिसे formula में $Permission के रूप में जाँचा जाता है, इंटीग्रेशन यूज़र या किसी डेटा माइग्रेशन को निकल जाने देता है, जबकि लोगों पर नियम लागू रहता है (How to Reference a Custom Permission in a Validation Rule (opens in a new tab))। इसे सोच-समझकर और कम लोगों को दें।
• किसी तारीख से आगे, CreatedDate की तुलना उस दिन से करके जब नियम लाइव हुआ, जब “नया” का मतलब हो “जब से हमने इसे लागू करना शुरू किया।” ISNEW() से अलग, यह उन रिकॉर्ड को बाद के हर save पर जाँचता रहता है, इसलिए वही चेतावनी लागू होती है: कोई छोटा बदलाव, जैसे batch में मालिक का अपडेट, किसी ऐसे रिकॉर्ड पर फ़ेल हो सकता है जो भटक चुका हो।

पहले से मौजूद रिकॉर्ड पर नियम जोड़ रहे हैं? इसे चालू करने से पहले इसके नतीजों पर सोच लें। अब हर मौजूदा रिकॉर्ड को अपने अगले save पर इससे पास होना होगा, और वह save कहीं से भी आ सकता है जिसकी आपने उम्मीद नहीं की थी: रात का कोई इंटीग्रेशन, batch में मालिक का बदलाव, एक roll-up, किसी list view से mass update। इनमें से कौन-से इससे टकराएँगे, और जब एक रिकॉर्ड फ़ेल होगा तो उस job का क्या होगा? चालू करने से पहले सेक्शन में वह क्रम है जो मैं इस्तेमाल करता हूँ।

नियम को खुश करने के लिए इतिहास दोबारा न लिखें

उन बीस हज़ार पुराने रिकॉर्ड का क्या? अगर डेटा गलत है और आपको सही मान पता हैं, तो उसे ठीक करें। लेकिन मैंने एक और तरह का “इलाज” देखा है: किसी को ऐतिहासिक सच नहीं पता, उन्हें बस रिकॉर्ड पास करवाने हैं, इसलिए वे उन्हें ऐसे मानों से अपडेट कर देते हैं जो आज के नियम को संतुष्ट करें। मुझे यह पसंद नहीं। पुराने रिकॉर्ड को नियम के मुताबिक बनाने के लिए अपडेट करना LastModifiedDate बदल देता है और अहम ऐतिहासिक जानकारी नष्ट कर देता है, और मान गढ़ने का मतलब है यह दिखावा करना कि हम अतीत के बारे में कुछ ऐसा जानते हैं जो हम नहीं जानते। इतिहास दोबारा लिखने के बजाय नियम को उससे पहले के रिकॉर्ड के लिए एक bypass दें। यह भद्दा हो सकता है, लेकिन ईमानदार है।

UI वैलिडेशन, डेटा वैलिडेशन नहीं है

किसी फ़ील्ड को पेज लेआउट पर required बनाइए, और यूज़र उसके बिना सेव नहीं कर सकते। फिर रात का इंटीग्रेशन 50,000 रिकॉर्ड डालता है। क्या उसने आपका पेज इस्तेमाल किया? नहीं। न ही bulk load ने, API client ने या एजेंट ने। UI की requirement उस स्क्रीन की रक्षा करती है, डेटा की नहीं। dynamic forms पर फ़ील्ड वैलिडेशन से भी इसी तरह बचा जा सकता है। इसलिए पूछें: यह डेटा कहाँ-कहाँ से आ सकता है? Lightning, portal, मोबाइल, इंटीग्रेशन, API, bulk load, Flow, Apex, एक एजेंट। जितने ज़्यादा दरवाज़े, उतना ही कम मैं ऐसे नियम पर भरोसा करता हूँ जो उनमें से सिर्फ़ एक की रखवाली करता है।

चौथा डंडा: डुप्लिकेट रूल

अब हम एक रिकॉर्ड के अंदर की सुसंगतता से रिकॉर्ड के बीच की सुसंगतता की ओर बढ़ते हैं। Acme Corporation, ACME Corp, Acme Inc.: चार ग्राहक या एक? कोई फ़ील्ड नियम इसका जवाब नहीं दे सकता। मैचिंग रूल तय करते हैं कि रिकॉर्ड की तुलना कैसे हो; डुप्लिकेट रूल तय करते हैं कि संभावित डुप्लिकेट मिलने पर क्या हो: चेतावनी के साथ इजाज़त, रोकना, या रिपोर्ट करना। आपके पास हर ऑब्जेक्ट पर ज़्यादा से ज़्यादा पाँच सक्रिय डुप्लिकेट रूल हो सकते हैं और हर एक में ज़्यादा से ज़्यादा तीन मैचिंग रूल, और match keys हर तुलना को सबसे संभावित 100 डुप्लिकेट तक सीमित कर देती हैं (Things to Know About Duplicate Rules (opens in a new tab))।

इनकी कीमत है रुकावट। अगर किसी रिप के बनाए हर account पर Possible duplicate found आता है, तो कभी-कभी आप ठीक यही चाहते हैं, और कभी-कभी लोग बिना पढ़े क्लिक करके आगे बढ़ना सीख जाते हैं। जायज़ रिकॉर्ड एक जैसे दिख सकते हैं, और किसी इंटीग्रेशन को किसी व्यक्ति से अलग व्यवहार की ज़रूरत हो सकती है। और चेतावनी Salesforce की अपनी है: उसका alert और संभावित डुप्लिकेट की उसकी सूची आपकी बनाई किसी कस्टम स्क्रीन में शायद मेल न खाए, और जब save headless हो, यानी कोई इंटीग्रेशन, डेटा लोड, एजेंट, तो उसे दिखाने के लिए कोई स्क्रीन होती ही नहीं। इसलिए तय करें कि हर रास्ते पर डुप्लिकेट कैसे सामने आएगा: किसी व्यक्ति के लिए चेतावनी, API के लिए रुका हुआ save और एक error, या बाद में किसी के देखने के लिए Report विकल्प और duplicate record sets। अच्छा आर्किटेक्चर ज़्यादा से ज़्यादा सख्ती नहीं है; यह सही सख्ती है।

और जाँचें कि कोई डुप्लिकेट रूल असल में किन दरवाज़ों की रखवाली करता है (Things to Know About Duplicate Rules (opens in a new tab))। API और डेटा import टूल के ज़रिए कोई चेतावनी नहीं देखता: alert पर सेट रूल सीधे save को रोक देता है। कुछ रास्ते नियमों को पूरी तरह छोड़ देते हैं: Quick Create, Undelete बटन, manual merge, Lightning Sync या Einstein Activity Capture से जुड़े रिकॉर्ड। और एक ही पल में सेव हुए रिकॉर्ड की आपस में तुलना नहीं होती, सिर्फ़ Salesforce में पहले से मौजूद रिकॉर्ड से होती है। एक फ़ाइल लोड करें जिसमें एक ही ग्राहक दो बार हो, और दोनों पंक्तियाँ निकल सकती हैं। डुप्लिकेट रूल एक अच्छा जाल है। यह दरवाज़े का ताला नहीं है।

परीक्षा-ज्ञान। डुप्लिकेट रूल एक ही पल में सेव हुए रिकॉर्ड की आपस में तुलना नहीं करते, सिर्फ़ Salesforce में पहले से मौजूद रिकॉर्ड से करते हैं। API और import टूल के ज़रिए कोई alert नहीं होता: रूल जिस डुप्लिकेट को पकड़ता है, वह बस सेव नहीं होता। और एक save और उससे शुरू होने वाली हर चीज़ एक ट्रांज़ैक्शन के रूप में चलती है: अगर कोई भी हिस्सा फ़ेल हो, तो सब कुछ वापस हो जाता है।

एक सीमा। डुप्लिकेट रूल एक org को साफ़ रखते हैं। ये एंटरप्राइज़ स्तर पर ग्राहक की पहचान की समस्या हल नहीं करते। अगर Salesforce के पास Acme Corporation है, ERP के पास ACME-10382 और बिलिंग के पास ग्राहक 77193, तो डुप्लिकेट रूल आपको नहीं बता सकता कि ये एक ही कंपनी हैं। यह मास्टर डेटा है, अध्याय 6।

पाँचवाँ डंडा: ऑटोमेशन

कुछ नियम निचले डंडों के लिए बहुत पेचीदा होते हैं: उन्हें जुड़े हुए रिकॉर्ड चाहिए, कोई दूसरा सिस्टम, निर्भर रिकॉर्ड, कई कदमों वाला प्रोसेस। यह Flow है, Apex है, कभी-कभी इंटीग्रेशन का लॉजिक। (Workflow Rules या Process Builder नहीं; इनका सपोर्ट खत्म हो चुका है।) ऑटोमेशन ताकतवर है और ज़्यादा महँगा भी: ज़्यादा चलते-फिरते हिस्से, ज़्यादा टेस्टिंग, ज़्यादा error handling, एक ऑटोमेशन के दूसरे से टकराने के ज़्यादा तरीके। और कोड अपनी errors खुद लाता है। अगर फ़ील्ड टाइप इसे लागू कर सकता है, तो मैं Apex नहीं लिखता। अगर कोई वैलिडेशन रूल इसे साफ़ कह देता है, तो मैं सिर्फ़ इसलिए flow नहीं बनाता कि Flow मौजूद है। फ़ील्ड की समस्या को प्रोसेस इंजन से हल न करें।

सब या कुछ नहीं: जब रिकॉर्ड साथ बदलते हैं

अब तक हर डंडा एक save की रक्षा करता है। लेकिन रिकॉर्ड साथ बदलते हैं: एक डिलीवरी और उसके आइटम, एक ऑर्डर और उसकी लाइनें, एक flow जो तीन ऑब्जेक्ट अपडेट करता है। यहाँ प्लेटफ़ॉर्म आपको एक मज़बूत गारंटी देता है। एक save और उससे शुरू होने वाली हर चीज़, triggers, flows, वे classes जिन्हें वे कॉल करते हैं, एक ट्रांज़ैक्शन के रूप में चलती है: अगर कोई भी हिस्सा फ़ेल हो, तो पूरी चीज़ वापस हो जाती है और कुछ भी commit नहीं होता (Apex Transactions (opens in a new tab))। आपको आधी डिलीवरी नहीं मिलती।

Bulk काम वह अपवाद है जिसे आप चुनते हैं। एक डेटा लोड या Apex का Database method आंशिक सफलता की इजाज़त दे सकता है: अच्छे रिकॉर्ड सेव हो जाते हैं, खराब वाले अपनी errors के साथ लौट आते हैं, और किसी को उन्हें संभालना पड़ता है (DML Statements vs. Database Class Methods (opens in a new tab))। एक मिलियन पंक्तियों के लोड के लिए यह अक्सर सही होता है, लेकिन तब सुसंगतता एक प्रोसेस बन जाती है: error फ़ाइल कौन पढ़ता है, और फ़ेल हुए रिकॉर्ड का क्या होता है?

और फिर समय का सवाल है। एक ही पल के दो saves दोनों एक ऐसी जाँच पास कर सकते हैं जिसमें दोनों अकेले फ़ेल हो जाते। एक flow जो पहले मौजूदा ऑर्डर ढूँढता है और फिर एक बनाता है, दो को निकल जाने दे सकता है, और हमने अभी देखा कि डुप्लिकेट रूल एक ही समय सेव हुए रिकॉर्ड की तुलना नहीं करते। Unique मार्क किया गया फ़ील्ड, या एक External ID, प्लेटफ़ॉर्म हर save पर जाँचता है, इसलिए उनमें से सिर्फ़ एक जीतता है। यह यूनिकनेस को फ़ील्ड तक नीचे ले जाने की एक और वजह है। Locks, contention और retries अपने आप में एक विषय हैं; अध्याय 11, ट्रांज़ैक्शन, कॉन्करेंसी और विश्वसनीयता, इसमें गहराई तक जाता है।

नियम को नीचे ले जाएँ, जब तक वह वहाँ का न रहे

“जितना नीचे उचित रूप से ले जा सकें” का मतलब “हमेशा सबसे नीचे” नहीं है। अगर कोई फ़ील्ड सिर्फ़ तब required है जब opportunity एक खास stage तक पहुँच जाए, तो उसे schema में required बनाना गलत है; नियम शर्त वाला है, इसलिए वैलिडेशन रूल सही डंडा है। अगर किसी डुप्लिकेट पर किसी व्यक्ति को चेतावनी मिलनी चाहिए लेकिन किसी मंज़ूर इंटीग्रेशन के पास अपना मिलान (reconciliation) है, तो दोनों रास्तों के लिए डिज़ाइन करें। लक्ष्य: सबसे निचली परत जो बिज़नेस के नियम को सही ढंग से दर्शाती हो।

हर परत की एक कीमत है

Click to enlarge

यही वह ट्रेड-ऑफ़ है जो मैं चाहता हूँ कि आप देखें। फ़ील्ड टाइप और नियंत्रित मान सीधे और मज़बूत हैं, लेकिन सिर्फ़ उसके लिए जो एक फ़ील्ड व्यक्त कर सकता है। Required और Unique भोथरे हैं: एक बार चालू, तो हर write को उन्हें संतुष्ट करना होगा। वैलिडेशन रूल ज़्यादा समृद्ध शर्तें व्यक्त करते हैं लेकिन पुराने रिकॉर्ड के एडिट रोक सकते हैं और किसी deployment को चौंका सकते हैं। डुप्लिकेट रूल रिकॉर्ड के बीच रक्षा करते हैं लेकिन यूज़र और इंटीग्रेशन के लिए रुकावट जोड़ते हैं। ऑटोमेशन कुछ भी संभाल लेता है लेकिन आपको orchestration, errors, टेस्ट और परफ़ॉर्मेंस का मालिक बना देता है। कोई परत मुफ़्त नहीं है। हर नियम की परत यह जानते हुए चुनें कि वह कैसे फ़ेल होती है।

चालू करने से पहले

किसी मौजूदा org में नियम जोड़ना एक rollout है, कोई checkbox नहीं। आज कितने रिकॉर्ड इसे तोड़ते हैं, और क्यों? क्या वे सच में गलत हैं? क्या हम सही मान जान सकते हैं? क्या नियम ऐतिहासिक रूप से सच है, या सिर्फ़ अब से? कौन-से इंटीग्रेशन, टेस्ट और ऑटोमेशन इससे टकराएँगे? एक अच्छा क्रम: नापें, जो गलत साबित कर सकें उसे साफ़ करें, नियम का दायरा तय करें, जायज़ इतिहास के लिए एक सोचा-समझा bypass जोड़ें, हर write रास्ते को टेस्ट करें, फिर लागू करें। नापना और साफ़ करना अपने आप में अनुशासन हैं, profiling, standardization, monitoring, stewardship, और अध्याय 5, डेटा गुणवत्ता और गवर्नेंस, इन्हें कवर करता है। शुक्रवार को एक बॉक्स पर टिक करने और शनिवार रात उसके नतीजे खोजने से कहीं बेहतर।

परीक्षा से आगे: AI क्या बदलता है। एक एजेंट किसी भी व्यक्ति से तेज़ी से रिकॉर्ड बना सकता है, और खराब रिकॉर्ड भी उतनी ही तेज़ी से। “यूज़र जानते हैं कि ऐसा नहीं करना है” कोई सुरक्षा नहीं है जब यूज़र एक एजेंट हो। अहम नियमों को डेटा की परत में रखें, जहाँ हर लिखने वाला उनसे टकराए, ताकि एजेंट को कंपनी के अनलिखे नियम याद न रखने पड़ें।

Steve Trucking: डिलीवरी की रक्षा करें

एक डिलीवरी लें। उसका status एक ही शब्दावली से आता है: एक पिकलिस्ट, प्रतिबंधित। रिटेल पार्टनर का ऑर्डर reference हर पार्टनर के लिए यूनिक होना चाहिए, इसलिए यह एक External ID है, unique मार्क किया हुआ, मैनिफ़ेस्ट को upsert करने के लिए इस्तेमाल होता है। status के Delivered होने पर असली डिलीवरी का समय अनिवार्य है: एक वैलिडेशन रूल, उस बदलाव तक सीमित। किसी इंस्टॉलेशन स्टॉप को तब तक बंद नहीं किया जा सकता जब तक उसकी checklist पूरी न हो और उसकी ज़रूरी फ़ोटो न ली गई हों (डिशवॉशर के लिए, पानी की लाइन, ड्रेन लाइन और लेवल): एक वैलिडेशन रूल, या ऑटोमेशन अगर उसे प्लेटफ़ॉर्म से बाहर स्टोर फ़ोटो जाँचनी हैं। दोबारा भेजे गए मैनिफ़ेस्ट से दो बार आने वाला एक ही ऑर्डर External ID से पकड़ा जाता है; एक जैसे दिखने वाले दो अलग ऑर्डर मिलान (matching) का सवाल हैं।

ध्यान दें, मैंने यह नहीं कहा कि “इन सबको एक flow में डाल दो।” हर नियम अपने डंडे पर बैठा है। हर नियम के लिए पूछें: वह सबसे निचली परत कौन-सी है जो इसे हर मायने रखने वाले write रास्ते के लिए सही ढंग से लागू करती है?

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

• हर नियम किस डंडे पर रहेगा: फ़ील्ड टाइप, नियंत्रित शब्दावली, required या unique, वैलिडेशन रूल, डुप्लिकेट रूल, या ऑटोमेशन।
• किन write रास्तों की रक्षा करनी है: UI, portal, मोबाइल, इंटीग्रेशन, bulk loads, API, ऑटोमेशन और एजेंट।
• कोई नया नियम ऐतिहासिक रिकॉर्ड पर लागू होता है, या अतीत के लिए एक bypass के साथ नए और बदले डेटा तक सीमित है।
• मौजूदा खराब डेटा को सबूत के आधार पर ठीक किया जा सकता है या नहीं, बजाय इसके कि उसे पास कराने के लिए दोबारा लिखा जाए।
• कोई नियम कितनी रुकावट, पेचीदगी और रखरखाव के लायक है।

साफ़ डेटा लोगों से अच्छा डेटा डालने को कहने से नहीं आता। यह ऐसे आर्किटेक्चर से आता है जो सही काम को आसान, गलत काम को मुश्किल, और अहम नियमों से बचना मुश्किल बना दे। आगे, हम Steve Trucking के एक हिस्से पर पूरे अध्याय को एक साथ जोड़ते हैं।

और जानें

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) और Roll-Up Summary Field (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया)।
• Salesforce Help, Picklist Limitations (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): सीमाएँ, वे रास्ते जहाँ नियम नहीं चलते, API और import से होने वाले saves बिना alert के रुक जाते हैं, एक साथ होने वाले saves की तुलना नहीं होती।
• Apex Developer Guide, Apex Transactions (opens in a new tab) और DML Statements vs. Database Class Methods (opens in a new tab) (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): एक ट्रांज़ैक्शन एक इकाई के रूप में वापस होता है; Database methods आंशिक सफलता की इजाज़त दे सकते हैं।
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।