Salesforce फ़िज़िकल मॉडल डिज़ाइन करें

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: हम अपने लॉजिकल मॉडल को Salesforce आर्किटेक्चर में कैसे बदलें?

यह पूरा अध्याय एक ही लंबी दलील रहा है कि प्लेटफ़ॉर्म का एक आकार होता है: स्टैंडर्ड और कस्टम ऑब्जेक्ट, वे जगहें जहाँ डेटा रह सकता है, फ़ील्ड टाइप, संबंध, स्वामित्व, लाइसेंस, सुसंगतता के नियम, स्टोरेज और स्केल। इनमें से हर एक यह बदल सकता है कि अध्याय 2 का लॉजिकल मॉडल कैसे बनेगा। अब इन सबको Steve Trucking के एक हिस्से पर जोड़कर देखते हैं।

एक हिस्सा, पूरी कंपनी नहीं। आर्किटेक्ट्स की एक गलती मैं अक्सर देखता हूँ: पूरे एंटरप्राइज़ को एक ही डायग्राम में हल करने की कोशिश। मुझे कुछ ऐसा चाहिए जिस पर हम ठीक से सोच सकें: एक रिटेल पार्टनर (Retail Partner) एक मैनिफ़ेस्ट (Manifest) भेजता है, Steve Trucking उसमें लिखा सामान डिलीवर करता है, और हम हर डिलीवरी के बारे में ज़रूरी जानकारी रखते हैं। फिर हम फ़िज़िकल निर्णय एक-एक करके लेते हैं। पूरा डिज़ाइन भाग 1 का चेकपॉइंट है।

जो हम पहले से जानते हैं, वहीं से शुरू करें

अध्याय 2 ने कॉन्सेप्चुअल काम कर दिया था: रिटेल पार्टनर, प्राप्तकर्ता (Recipient), मैनिफ़ेस्ट, डिलीवरी, डिलीवरी आइटम, स्टॉप का प्रकार, क्रू, ट्रक, डिस्ट्रिब्यूशन सेंटर, फ़ोटो। हमने संबंधों के नाम रखे और पूछा कि उनका मतलब क्या है। मैं वह दोहराऊँगा नहीं। अब सवाल यह है कि ये कॉन्सेप्ट Salesforce पर कैसे रहते हैं। ब्रीफ़ का एक तथ्य तुरंत मायने रखता है: Steve Trucking अपॉइंटमेंट, क्रू और मोबाइल ऐप के लिए पहले से Field Service चलाता है।

रिटेल पार्टनर: Account का आविष्कार न करें

रिटेल पार्टनर एक कंपनी है जिसके लिए Steve Trucking काम करता है। Salesforce के पास कंपनियों के लिए बना एक ऑब्जेक्ट पहले से है: Account। साफ़ फ़िट। इसलिए सिर्फ़ इस वजह से Retail_Partner__c नहीं बनेगा कि बिज़नेस “पार्टनर” कहता है। यह एक Account है, जिसका Retail Partner रिकॉर्ड टाइप उसे बाकी संगठनों से अलग करता है, और इसके साथ आते हैं कॉन्ट्रैक्ट, केस, DC मैनेजरों के लिए Contacts, और उन Contacts के लिए पोर्टल एक्सेस। आसान निर्णय। सारे निर्णय ऐसे नहीं होते।

पार्टनर का ऑर्डर नंबर हमारा यूनिक ID नहीं है

हर रिटेल पार्टनर अपने रेफ़रेंस भेजता है। एक पार्टनर का ऑर्डर 8843119 जैसा दिखता है, दूसरे का A-984732 जैसा। ये नंबर मायने रखते हैं, लेकिन ये किसके हैं? पार्टनर के। Salesforce का अपना रिकॉर्ड ID है, और पार्टनर के पास वह रेफ़रेंस है जिससे वह हमसे बात करता है। दोनों साथ रह सकते हैं; यही अध्याय 2 का “एक चीज़, कई पहचानकर्ता (identifiers)” है।

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

डिलीवरी: मदरशिप की ओर देखें

यहीं पर Delivery__c बनाने का मन करता है। बिज़नेस ने “डिलीवरी” कहा, तो हमें एक Delivery ऑब्जेक्ट चाहिए। ठीक यही मैं नहीं चाहता कि आप सबसे पहले करें। मदरशिप की ओर देखें, जैसे हमने मॉड्यूल 2 में किया था। किसी जगह पर किए जाने वाले काम के लिए, जिसका जीवनचक्र हो, आइटम हों, शेड्यूलिंग हो और फ़ील्ड में एक क्रू हो, Salesforce के पास पहले से क्या है? Field Service का Work Order (कार्य आदेश): Salesforce इसे किसी ग्राहक के लिए किया जाने वाला फ़ील्ड सर्विस का काम बताता है (WorkOrder (opens in a new tab))। तय विज़िट और उसकी समय-सीमा Service Appointment है, और डिस्पैच इसी को शेड्यूल करता है और क्रू का ऐप इसी को दिखाता है।

तो डिलीवरी → Work Order। इसलिए नहीं कि शब्द मेल खाते हैं; वे नहीं खाते। इसलिए कि व्यवहार उस प्लेटफ़ॉर्म क्षमता से मेल खाता है जिसके लिए हम पहले से पैसे दे रहे हैं और जिसे इस्तेमाल करना चाहते हैं। स्टैंडर्ड ऑब्जेक्ट का बिज़नेस की शब्दावली से मेल खाना ज़रूरी नहीं। ज़रूरी यह है कि वह कॉन्सेप्ट को सही तरह दर्शाए।

Click to enlarge

चरण 1 (कुल 4 में से): मदरशिप। हर कार्ड बिज़नेस कॉन्सेप्ट है, और उसके नीचे उसका Salesforce ऑब्जेक्ट।

लेकिन स्टैंडर्ड ऑब्जेक्ट अपने साथ सामान भी लाते हैं

दूसरा पहलू: Work Order मुफ़्त नहीं है। वह अपने साथ Field Service लाइसेंसिंग, अपने संबंध, सिक्योरिटी का व्यवहार, अनिवार्य फ़ील्ड, ऑटोमेशन और जीवनचक्र लाता है, और प्लेटफ़ॉर्म के दूसरे हिस्से उससे एक खास तरह के व्यवहार की उम्मीद करते हैं। हम इसे इसलिए चुन रहे हैं क्योंकि फ़िट साफ़ है और हम उसके आसपास बनी चीज़ें इस्तेमाल कर रहे हैं। अगर Steve Trucking को Field Service का कुछ भी नहीं चाहिए होता और मॉडल हर कदम पर प्रोसेस से टकराता, तो मैं दोबारा सोचता। आर्किटेक्चर फ़िट है, लेबल नहीं।

डिलीवरी आइटम: मॉडल के पीछे चलें

एक बार डिलीवरी Work Order बन गई, तो कुछ भी नया ईजाद करने से पहले उस मॉडल का बाकी हिस्सा देखें। Work Order Line Item किसी Work Order का एक उप-काम (subtask) है (WorkOrderLineItem (opens in a new tab)): फ़्रिज, इंस्टॉलेशन, पुराना सामान उठाकर ले जाना (haul-away)। तो डिलीवरी आइटम → Work Order Line Item। गौर करें, पहले निर्णय ने दूसरे को आकार दिया। हम हर एंटिटी के लिए अलग-अलग ऑब्जेक्ट नहीं चुन रहे। एक मॉडल अपनाएँ, और उसके आसपास कस्टम संरचनाएँ बनाने से पहले उसका बाकी हिस्सा समझें।

यह किस तरह का स्टॉप है?

Steve Trucking में एक स्टॉप या तो सिर्फ़ डिलीवरी है, या इंस्टॉलेशन के साथ डिलीवरी, या पुराना सामान उठाने के साथ डिलीवरी, और हर प्रकार की अपनी अवधि, क्रू के कौशल और इंस्टॉलेशन चेकलिस्ट है। अध्याय 2 में हमने तय किया था कि यह एक एंटिटी है, लेबल नहीं। Field Service में यह पहले से है: Work Type, एक तरह के काम का टेम्पलेट, जिसे Work Order और line item पर लागू किया जा सकता है (WorkType (opens in a new tab))। तो स्टॉप का प्रकार → Work Type। फिर से, इसलिए नहीं कि Work Type नाम की कोई चीज़ मौजूद है, बल्कि इसलिए कि कॉन्सेप्ट और व्यवहार मेल खाते हैं।

Click to enlarge

चरण 2 (कुल 4 में से): मॉडल के पीछे चलें। line item और Work Type, Work Order के साथ आते हैं।

मैनिफ़ेस्ट: अब मुझे कस्टम ऑब्जेक्ट चाहिए

क्या “Phoenix DC पर मंगलवार के लिए पार्टनर की सूची” के लिए कोई स्टैंडर्ड ऑब्जेक्ट है? असल में नहीं, और सिर्फ़ यह कहने के लिए कि हम स्टैंडर्ड पर टिके रहे, मैं इसे किसी बेमेल ऑब्जेक्ट में ठूँसूँगा नहीं। मैनिफ़ेस्ट → Manifest__c। यह प्राप्ति की इकाई है: यह कहाँ से आया (एक फ़ाइल, एक API बैच), कब आया, इसका स्टेटस और कुल योग, और जब कोई पार्टनर उसी दिन इसे दोबारा भेजता है, तो किसकी तुलना होती है। मैनिफ़ेस्ट की हर लाइन एक Work Order बनती है, जो वापस उससे जुड़ी रहती है।

कस्टम होना विफलता नहीं है। जब किसी कॉन्सेप्ट का कोई साफ़ स्टैंडर्ड ठिकाना न हो, तो प्लेटफ़ॉर्म हमें यही देता है। गलती कस्टम ऑब्जेक्ट बनाना नहीं है; गलती है यह जाँचे बिना उसे बनाना कि प्लेटफ़ॉर्म के पास वह कॉन्सेप्ट पहले से है या नहीं।

Click to enlarge

चरण 3 (कुल 4 में से): अकेला कस्टम ऑब्जेक्ट, जहाँ कोई स्टैंडर्ड ऑब्जेक्ट फ़िट नहीं होता।

फ़ोटो: Salesforce इसे स्टोर कर सकता है, इसका मतलब यह नहीं कि करना चाहिए

“हमें डिलीवरी की फ़ोटो Salesforce में चाहिए।” “Salesforce में” का मतलब क्या है? यूज़र्स को उन्हें Salesforce से देखना है, हाँ। क्या इसका मतलब है कि इमेज फ़ाइलें core स्टोरेज में ही रहें? ज़रूरी नहीं। शून्य गिनें: हर डिलीवरी पर लगभग चार फ़ोटो, इंस्टॉलेशन के साथ और ज़्यादा, और साल में 1 मिलियन डिलीवरी पर, यह साल में चार से पाँच मिलियन फ़ोटो है, और डिलीवरी हर साल 30% बढ़ती हैं।

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

फ़ील्ड: मतलब को दिखने दें

Work Order को फ़ील्ड चाहिए: पार्टनर का रेफ़रेंस, डिलीवरी का समय-स्लॉट, डिलीवरी का असली समय, स्टेटस, और “गेट कोड” या “आँगन में कुत्ता है” जैसे नोट्स। मैं इसे फ़ील्ड की सूची नहीं बनाऊँगा; वह काम मॉड्यूल 6 ने किया। हर फ़ील्ड पर सवाल चलाएँ: इसका मतलब क्या है, इसका मालिक कौन है, क्या यह बदलता है, क्या यह पहचानकर्ता (identifier) है, नियंत्रित शब्दावली है, स्टोर किया गया है या निकाला गया (derived), संवेदनशील है। पार्टनर का रेफ़रेंस External ID है, इसलिए उसका यूनिक होना इंटीग्रेशन कॉन्ट्रैक्ट का हिस्सा है, सिर्फ़ एक चेकबॉक्स नहीं। डिलीवरी का असली समय एक पल है, इसलिए Date/Time। स्टेटस व्यवहार चलाता है, इसलिए नियंत्रित सूची, कभी फ़्री टेक्स्ट नहीं। और किसी व्यक्ति के घर के बारे में डिलीवरी नोट्स व्यक्तिगत डेटा हैं, इसलिए उनका वर्गीकरण होता है। हर फ़ील्ड का सिरा उसके मतलब तक जाता है।

संबंध: सिर्फ़ बॉक्स न जोड़ें

Account से Work Order, Work Order से उसके line item, मैनिफ़ेस्ट से Work Order, और स्टॉप का वर्णन करता Work Type। फिर हर लाइन के लिए मॉड्यूल 7 के सवाल: क्या चाइल्ड अकेला रह सकता है, उसका मालिक कौन है, क्या एक्सेस विरासत में मिलता है, क्या वह दूसरी जगह जा सकता है, डिलीट होने पर क्या होता है, कितने चाइल्ड जमा हो सकते हैं? मुट्ठी भर रिटेल पार्टनर Accounts के नीचे हर Work Order, यानी हर पैरेंट के नीचे सैकड़ों हज़ार चाइल्ड: यह skew का सवाल है, जिसका जवाब हम भाग 2 में देंगे। और Field Service के स्टैंडर्ड संबंधों के लिए, यह मान लेने के बजाय कि वे वैसे ही हैं जैसे हम डिज़ाइन करते, देखें कि Salesforce ने उन्हें पहले से कैसे बनाया है। जब आप कोई स्टैंडर्ड मॉडल अपनाते हैं, तो आप उसके अंदर Salesforce के लिए गए निर्णय भी अपनाते हैं। उसके ऊपर कुछ बनाने से पहले उन्हें समझें।

स्वामित्व और प्राप्तकर्ता: डिफ़ॉल्ट को फ़ैसला न करने दें

दो निर्णय, जो कोई डिफ़ॉल्ट खुशी-खुशी हमारे लिए ले लेगा।

डिलीवरी का मालिक कौन है? इसका जवाब हमने मॉड्यूल 8 में दिया था, और वह सीधे Work Order पर लागू होता है: यहाँ स्वामित्व किसी के एक्सेस को तय नहीं करता, इसलिए इंटीग्रेशन यूज़र अपने बनाए Work Orders का मालिक है। डिस्पैचर अपने डिस्ट्रिब्यूशन सेंटर के Work Orders देखते हैं, क्रू अपने रूट के, और हर रिटेल पार्टनर पोर्टल के ज़रिए अपने, और यह सब शेयरिंग से होता है, स्वामित्व से नहीं। इंटीग्रेशन यूज़र का कोई रोल नहीं है और वह उन पब्लिक ग्रुप्स से बाहर रहता है जिन्हें हमारे शेयरिंग रूल इस्तेमाल करते हैं, क्योंकि रोज़ 3,300 की दर से वह तीन दिन में 10,000 रिकॉर्ड पार कर जाता है। और हम लिखकर रखते हैं कि अगर वह यूज़र कभी बदला गया तो क्या होगा।

प्राप्तकर्ता क्या है? एक Contact? एक Person Account? कुछ ऐसा जो सिर्फ़ डिलीवरी पर रखा जाए? यह इस पर निर्भर है कि क्या Steve Trucking का इन लोगों से कोई संबंध है भी (ये रिटेल पार्टनर्स के ग्राहक हैं), क्या एक पार्टनर कभी दूसरे के प्राप्तकर्ता देख सकता है, उनका व्यक्तिगत डेटा कितने समय तक रखा जा सकता है, और स्केल: हर साल लगभग 1 मिलियन नए प्राप्तकर्ता। यह सब हमारे पास अभी नहीं है, और यह ठीक है। कभी-कभी सही जवाब होता है हम अभी पर्याप्त नहीं जानते। सवाल लिख लें और जानकारी जुटाएँ; अनिश्चितता को किसी कस्टम ऑब्जेक्ट में दफ़न न करें। इसका जवाब हम भाग 1 के चेकपॉइंट पर देंगे, जब अध्याय 4 से 6 हमें एंटरप्राइज़ और मास्टर डेटा की तस्वीर दे देंगे।

सुसंगतता: मॉडल को सही परत पर बचाएँ

मॉड्यूल 9 की सीढ़ी यहाँ लागू होती है: पार्टनर का रेफ़रेंस एक External ID है, यूनिक, ताकि दोबारा भेजा गया मैनिफ़ेस्ट डुप्लिकेट बनाने के बजाय upsert हो; स्टेटस एक प्रतिबंधित सूची है; डिलीवरी का असली समय तभी अनिवार्य है जब स्टेटस Delivered हो; इंस्टॉलेशन वाला स्टॉप अपनी चेकलिस्ट और फ़ोटो के बिना बंद नहीं हो सकता। एक विशाल flow नहीं। हर नियम अपनी सीढ़ी के डंडे पर।

हर टुकड़ा कहाँ रहता है

इस हिस्से पर एक और नज़र, मॉड्यूल 4 के सवाल के साथ: डेटा का हर टुकड़ा कहाँ रहता है? मेरी क्लास की स्लाइड्स में यह एक स्लाइड है, लॉजिकल बनाम फ़िज़िकल: अध्याय 2 की लॉजिकल एंटिटी, और हर एक भौतिक रूप से कहाँ पहुँचती है: core पर, एक sObject के रूप में (कस्टम हो तो __c) या एक big object (__b) के रूप में, या core से बाहर, एक एक्सटर्नल ऑब्जेक्ट (__x) के रूप में या ऐसे डेटा के रूप में जो कभी Salesforce में आता ही नहीं।

• core पर, जिस पर रोज़ काम होता है: Account, Work Orders और उनके line item, Service Appointments, Work Types, Manifest__c।
• core पर, आर्काइव किया हुआ: तीन साल से पुरानी डिलीवरी Delivery History में चली जाती हैं, जो एक big object है, क्लेम के लिए अब भी मौजूद, बस पीछे के गोदाम में।
• संदर्भित (referenced): रिटेल पार्टनर के अपने ऑर्डर की जानकारी पार्टनर के सिस्टम में ही रहती है; हम पार्टनर का रेफ़रेंस एक External ID के रूप में रखते हैं, और जब किसी को ज़रूरत हो तो बाकी जानकारी एक एक्सटर्नल ऑब्जेक्ट या इंटीग्रेशन के ज़रिए पाते हैं।
• core से बाहर: फ़ोटो, लाखों इमेज के लिए बने स्टोरेज में, Work Order से एक लिंक के साथ।

यही फ़िज़िकल मॉडल है: सिर्फ़ कौन-सा ऑब्जेक्ट नहीं, बल्कि कौन-सा घर भी।

अब पूरे हिस्से को देखें

• रिटेल पार्टनर → Account, Retail Partner रिकॉर्ड टाइप के साथ; DC मैनेजर Contacts के रूप में।
• डिलीवरी → Field Service Work Order, एक Service Appointment के ज़रिए शेड्यूल।
• डिलीवरी आइटम → Work Order Line Item।
• स्टॉप का प्रकार → Work Type।
• मैनिफ़ेस्ट → कस्टम Manifest__c।
• पार्टनर का रेफ़रेंस → Work Order पर External ID, हर पार्टनर के लिए यूनिक।
• फ़ोटो → core से बाहर स्टोर; Salesforce रेफ़रेंस और पूर्णता का फ़्लैग रखता है।
• डिलीवरी का इतिहास → तीन साल बाद एक big object में आर्काइव।
• स्वामित्व → इंटीग्रेशन यूज़र, एक्सेस शेयरिंग के ज़रिए (मॉड्यूल 8)।
• प्राप्तकर्ता → खुला सवाल, भाग 1 के चेकपॉइंट के लिए।

Click to enlarge

चरण 4 (कुल 4 में से): पूरा हिस्सा, core पर, आर्काइव किया हुआ और core से बाहर। हर लाइन एक lookup है: Salesforce ने Field Service को lookups पर बनाया है, और हम उसके निर्णय भी उसके साथ अपनाते हैं।

डायग्राम आर्किटेक्चर नहीं है

मैं आपको वह डायग्राम थमा सकता हूँ, और वह काफ़ी नहीं है। आर्किटेक्चर उसके पीछे का तर्क है। Account क्यों? एक कंपनी, साफ़ फ़िट। Work Order क्यों, Delivery__c क्यों नहीं? डिलीवरी फ़ील्ड के काम की तरह व्यवहार करती है, और Field Service पहले से मौजूद है। कस्टम मैनिफ़ेस्ट क्यों? कोई साफ़ स्टैंडर्ड ठिकाना नहीं। फ़ोटो सीधे Files क्यों नहीं? वॉल्यूम और स्टोरेज का अर्थशास्त्र। External ID क्यों? एक और सिस्टम को सीमा के आर-पार एक स्थिर यूनिक ID चाहिए। Work Orders का मालिक इंटीग्रेशन यूज़र क्यों? यहाँ स्वामित्व एक्सेस तय नहीं करता, और इससे ऑडिट ट्रेल ईमानदार रहता है। प्राप्तकर्ता अब भी खुला क्यों है? हमने अभी पर्याप्त सवालों के जवाब नहीं दिए। लाइनें नतीजा हैं; उन्हें निर्णयों ने बनाया है।

तो यह वह आदत है जिसके साथ मैं चाहता हूँ कि आप अध्याय 3 से निकलें। फ़िज़िकल मॉडल में किसी भी चीज़ की ओर इशारा करें और पूछें क्यों? यह ऑब्जेक्ट क्यों, यह टाइप, यह संबंध, यह मालिक, यह जगह, यह नियम क्यों? आपको जवाब का सिरा पीछे तक ढूँढ पाना चाहिए: कॉन्फ़िगरेशन से फ़िज़िकल मॉडल तक, लॉजिकल मॉडल तक, बिज़नेस की ज़रूरत तक। अगर नहीं ढूँढ पाते, तो किसी ने Setup से डिज़ाइन किया है।

और आपने गौर किया होगा कि कुछ संख्याओं पर हमने पूरा काम नहीं किया: हर पार्टनर की डिलीवरी, line item, फ़ोटो, रिटेंशन, आर्काइविंग। अच्छी बात है। डिज़ाइन पक्का करने से पहले शून्यों की गिनती पूछें: जो मॉडल पचास हज़ार रिकॉर्ड पर शानदार चलता है, वह पाँच सौ मिलियन पर बिल्कुल अलग व्यवहार कर सकता है। वह भाग 2 है।

परीक्षा से आगे: AI क्या बदलता है। किसी AI को Steve Trucking का ब्रीफ़ दें, और वह सेकंडों में एक स्कीमा बना देगा: Account, Work Order, कस्टम ऑब्जेक्ट, फ़ील्ड, यहाँ तक कि डिप्लॉयमेंट मेटाडेटा भी। यह एक शानदार रफ़्तार देने वाली चीज़ है, लेकिन यह समीक्षा नहीं है। आर्किटेक्ट का काम मैपिंग और उनके नतीजों की जाँच की ओर खिसक जाता है: फ़िट, लाइसेंस, स्वामित्व, जीवनचक्र, स्केल, यूनिक ID, सिक्योरिटी, और क्या प्लेटफ़ॉर्म से बाहर रहता है। AI रॉकेट बूस्टर है; वह आपको यह नहीं बताता कि आपकी दिशा सही है या नहीं।

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

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

इस अध्याय की शुरुआत में हमने पूछा था कि मॉडल Salesforce पर कैसे रहे। यही Salesforce डेटा आर्किटेक्चर है: ऑब्जेक्ट बनाना नहीं, Setup रटना नहीं, ज़्यादा सुंदर बॉक्स बनाना नहीं, बल्कि सोच-समझकर बिज़नेस मॉडल को प्लेटफ़ॉर्म के आकार में फ़िट करना। हर संरचना एक प्रतिबद्धता है। वही बनाएँ जिन्हें आप समझा सकें।

और जानें

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) और WorkType (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Steve Trucking का ब्रीफ़।