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

Data Architect कोर्स के अध्याय 3 की अध्ययन गाइड। पहले दस मॉड्यूल पढ़ें; यह पेज आपको जाँचने में मदद करता है कि क्या याद रहा।

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

यह वह अध्याय है जहाँ मॉडल प्लेटफ़ॉर्म से मिलता है, और परीक्षा का बड़ा हिस्सा इसी पर टिका है। यह दोनों सबसे बड़े खंडों को आधार देता है, Data Modeling and Database Design और Salesforce Data Management, जिनमें से हर एक परीक्षा का एक-चौथाई हिस्सा है। प्लेटफ़ॉर्म की संख्याएँ बदलती रहती हैं: चेकलिस्ट वही संख्याएँ देती है जो मॉड्यूल बताते हैं, जाँचने की तारीख़ के साथ। सीखें कि हर सीमा किसलिए है, और उस पर भरोसा करने से पहले मौजूदा संख्या देख लें।

परीक्षा के लिए

आगे बढ़ते हुए इन पर निशान लगाते जाएँ। हर एक उस जगह का लिंक देती है जहाँ उसे सिखाया गया है।

DM-1: प्लेटफ़ॉर्म पर डेटा मॉडल डिज़ाइन करना

• मैं जानता हूँ कि Salesforce एक मेटाडेटा-आधारित (metadata-driven), multitenant प्लेटफ़ॉर्म है: ऑब्जेक्ट मेटाडेटा है, नई टेबल नहीं, और हर ऑब्जेक्ट को उसके बनते ही उसके API मिल जाते हैं। (मेटाडेटा ही ब्लूप्रिंट है, आपका API ऑब्जेक्ट के साथ ही आ गया)
• मैं जानता हूँ कि governor limits (प्लेटफ़ॉर्म की सीमाएँ) इसलिए हैं ताकि कोई एक tenant साझा संसाधनों पर कब्ज़ा न कर सके। (आप लिफ़्ट पर कब्ज़ा नहीं कर सकते)
• मैं स्टैंडर्ड डेटा मॉडल पढ़ सकता हूँ: Lead का Account, Contact और Opportunity में बदलना; Opportunity Product एक Price Book Entry की ओर इशारा करता है, जो Product2 की ओर इशारा करती है; और सर्विस की तरफ़ Case, Asset और Entitlement। (Sales मॉडल, Service मॉडल)
• मैं जानता हूँ कि New Custom Object स्क्रीन क्या तय करती है: Text या Auto Number रिकॉर्ड नाम; Object Classification (sharing, Bulk API और Streaming API चालू हों तो यह Enterprise Application ऑब्जेक्ट है, बंद हों तो Light Application ऑब्जेक्ट); और Allow Search, जो डिफ़ॉल्ट रूप से बंद रहता है। (New Custom Object स्क्रीन)
• मैं API नाम पढ़ सकता हूँ: स्टैंडर्ड ऑब्जेक्ट और फ़ील्ड का कोई prefix या suffix नहीं होता; कस्टम ऑब्जेक्ट और फ़ील्ड __c पर खत्म होते हैं; managed package अपना namespace prefix (abc__) जोड़ता है; और किसी package के ऑब्जेक्ट पर आप जो फ़ील्ड जोड़ते हैं, उसे __c मिलता है, लेकिन vendor का prefix कभी नहीं। (Prefix और suffix)
• मैं किसी स्टैंडर्ड ऑब्जेक्ट के लिए साफ़ फ़िट की कसौटी लागू कर सकता हूँ, और जानता हूँ कि कब मतलब या वज़न कस्टम ऑब्जेक्ट की ओर इशारा करता है। (साफ़ फ़िट की कसौटी)
• मैं जानता हूँ कि Asset और Person Account किसलिए हैं, कि एक Person Account बिज़नेस Account से लगभग दोगुना स्टोरेज लेता है, और कि एक बार Person Account चालू हो जाएँ तो उन्हें बंद नहीं किया जा सकता। (Asset एक अच्छा उदाहरण है, Person Account, व्यक्ति कब Account होता है?)
• मैं ज़रूरी व्यवहार के हिसाब से फ़ील्ड टाइप चुनता हूँ (फ़्लीट नंबर Number नहीं है), और जानता हूँ कि date/time GMT में स्टोर होता है और हर पढ़ने वाले के टाइम ज़ोन में दिखता है, इसलिए उसकी तुलना रेंज से होती है, बराबरी से नहीं। (संख्या हमेशा संख्या नहीं होती, Date, Date/Time और Time)
• मैं जानता हूँ कि टेक्स्ट दो तरह का होता है: रिकॉर्ड पर 255 अक्षरों तक (इंडेक्स हो सकता है, unique या External ID के रूप में इस्तेमाल हो सकता है), और उससे ऊपर Long या Rich text, जिसमें न इंडेक्स है, न WHERE फ़िल्टरिंग, न फ़ॉर्मूले। (Text परिवार)
• मैं जानता हूँ कि auto number Name कब इस्तेमाल करें, और कि वह रिकॉर्ड का ID नहीं है। (क्या किसी इंसान को इसे पहचानना है?)
• मैं जानता हूँ कि External ID से कोई इंटीग्रेशन कैसे upsert करता है, और चाइल्ड रिकॉर्ड को उनके पैरेंट के External ID से कैसे लोड करता है। (External ID)
• मैं जानता हूँ कि कब किसी वैल्यू को फ़ॉर्मूले से निकाला (derived) जाना चाहिए, और कब वह एक ऐतिहासिक तथ्य है जिसे स्टोर करना ज़रूरी है। (स्टोर करें या निकालें?)
• मैं तार्किक जंक्शन ऑब्जेक्ट (मॉडलिंग का विचार: एक ऑब्जेक्ट जो many-to-many में दो दूसरे ऑब्जेक्ट को जोड़ता है, अपने एट्रिब्यूट के साथ) और Salesforce Junction Object (दो master-detail संबंधों वाला एक कस्टम ऑब्जेक्ट) का फ़र्क जानता हूँ, और यह भी कि Salesforce का मतलब दूसरे वाले से होता है। (दो parent चौड़ा)
• मैं hierarchical संबंध जानता हूँ: एक खास lookup जो सिर्फ़ User ऑब्जेक्ट पर होता है, जैसे स्टैंडर्ड Manager फ़ील्ड, जो सीधे या घुमा-फिराकर उसी यूज़र पर वापस नहीं आ सकता, और जो रोल हायरार्की नहीं है। (Hierarchical)
• मैं lookup और master-detail का फ़र्क जानता हूँ: स्वामित्व, शेयरिंग, अनिवार्य पैरेंट, कैस्केड डिलीट, roll-up summary। (Lookup, Master-Detail)
• मैं जानता हूँ कि master-detail ऐसे ऑब्जेक्ट पर नहीं बनाया जा सकता जिसमें पहले से डेटा हो (lookup बनाएँ, उसे भरें, फिर बदलें), वह वापस lookup तभी बन सकता है जब master पर कोई roll-up न हो, और किसी चाइल्ड को दूसरी जगह ले जाने के लिए Allow reparenting चाहिए। (क्या child अपना parent बदल सकता है?)
• मैं master-detail के लिए प्लेटफ़ॉर्म का आकार जानता हूँ: तीन कस्टम detail स्तर तक गहरा (lookup कहीं भी श्रृंखला तोड़ सकता है), और दो master-detail पैरेंट चौड़ा। Salesforce Junction Object में पहले बना master-detail primary होता है (owner, look, division), दूसरा secondary होता है, और एक्सेस के लिए दोनों पैरेंट चाहिए: सबसे सख़्त नियम जीतता है। (तीन स्तर गहरे, दो parent चौड़ा)
• मैं जानता हूँ कि पैरेंट डिलीट होने पर lookup के तीन विकल्प हैं: फ़ील्ड खाली करना (डिफ़ॉल्ट), डिलीट को रोकना, या कैस्केड, जो तब तक बंद रहता है जब तक Salesforce उसे चालू न करे, और जो शेयरिंग को बायपास करता है। (Lookup)
• मैं जानता हूँ कि self-relationship का lookup होना ज़रूरी है, और दो जो पहले से बने हैं: Account का Parent Account और Case का Parent Case। (Self-relationships)
• मैं जानता हूँ कि roll-up की दोबारा गणना में समय लग सकता है, कि roll-up ऐसे फ़ॉर्मूले का इस्तेमाल नहीं कर सकता जिसमें NOW(), TODAY() या cross-object रेफ़रेंस हो, और कि सिर्फ़ roll-up पाने के लिए master-detail न चुनें: flow या trigger से अपडेट रखा गया एक स्टोर किया हुआ फ़ील्ड इसका विकल्प है। (Roll-ups उपयोगी हैं, लेकिन मुफ़्त नहीं)
• मैं संबंधों की वे सीमाएँ जानता हूँ जो मॉड्यूल बताता है: हर ऑब्जेक्ट पर दो master-detail; डिफ़ॉल्ट रूप से 40 संबंध फ़ील्ड (अधिकतम 50); डिफ़ॉल्ट रूप से 25 roll-up (अधिकतम 40)। (संबंधों की भी सीमाएँ हैं)

DM-2: ऐसा मॉडल जो शेयरिंग का सम्मान करे और स्केल हो

• मैं जानता हूँ कि master-detail चाइल्ड का अपना कोई owner और कोई share table नहीं होता: एक्सेस master से आता है। (स्वामित्व भी साथ चला आता है)
• मैं parent-child skew जानता हूँ: Salesforce का मार्गदर्शन है कि एक पैरेंट पर लगभग 10,000 से ज़्यादा चाइल्ड न हों। (10,000 children का सवाल)
• मैं ownership skew (एक यूज़र का किसी ऑब्जेक्ट के 10,000 से ज़्यादा रिकॉर्ड का मालिक होना) और उसका मार्गदर्शन जानता हूँ: स्वामित्व बाँटें, या उस यूज़र को रोल हायरार्की से बाहर रखें या सबसे ऊपर अकेला रखें, और शेयरिंग रूल में इस्तेमाल होने वाले पब्लिक ग्रुप्स से बाहर रखें। (स्वामित्व स्केल की समस्या बन सकता है)
• मैं share table जानता हूँ: कस्टम ऑब्जेक्ट का share ऑब्जेक्ट Object__Share होता है; detail ऑब्जेक्ट का कोई share ऑब्जेक्ट नहीं होता, उसका एक्सेस master से आता है; और owner बदलने से manual shares हट जाते हैं, लेकिन अपने reason वाली Apex sharing बनी रहती है। (Share table)
• मैं तय कर सकता हूँ कि इंटीग्रेशन और एजेंट जो रिकॉर्ड बनाते हैं, उनका मालिक कौन हो, इस आधार पर कि स्वामित्व शेयरिंग तय करता है या नहीं। (सिस्टम के बनाए रिकॉर्ड का मालिक कौन?)

DM-4: big object बनाम स्टैंडर्ड और कस्टम ऑब्जेक्ट

• मैं डेटा के तीन घर जानता हूँ: core पर (sObjects, जिन पर रोज़ काम होता है), संदर्भित (कोई दूसरा सिस्टम सच का स्रोत है: Salesforce Connect के एक्सटर्नल ऑब्जेक्ट, __x, या कस्टम कॉल), और आर्काइव (core पर big object, __b, में या core से बाहर किसी warehouse में)। (Core पर और core से बाहर)
• मैं जानता हूँ कि एक्सटर्नल ऑब्जेक्ट हर बार छुए जाने पर एक callout करते हैं, इसलिए latency और स्रोत सिस्टम की उपलब्धता मायने रखती है। (संदर्भित)
• मैं big object जानता हूँ: विशाल वॉल्यूम, उनके इंडेक्स के ज़रिए सटीक मिलान या रेंज से क्वेरी, कोई स्टैंडर्ड UI या रिपोर्टिंग नहीं, सिर्फ़ ऑब्जेक्ट और फ़ील्ड permissions, कोई ऑटोमेशन नहीं। (आर्काइव)
• मैं जानता हूँ कि ज़्यादातर रिकॉर्ड, फ़ील्ड चाहे जितने हों, लगभग 2 KB डेटा स्टोरेज गिने जाते हैं, और फ़ाइलें अलग से फ़ाइल स्टोरेज में गिनी जाती हैं। (दो कॉलम हों या दो सौ, फ़ाइलें और Attachments)

SDM-1: लाइसेंस और वे ऑब्जेक्ट जिन्हें लोग इस्तेमाल कर सकते हैं

• मैं तीन आंतरिक लाइसेंस जानता हूँ, Sales Cloud, Service Cloud और Platform, और यह कि हर एक क्या इस्तेमाल कर सकता है। (तीन आंतरिक लाइसेंस)
• मैं जानता हूँ कि लाइसेंस डेटा मॉडल का हिस्सा हैं: Salesforce Platform यूज़र्स को Leads, Campaigns, Opportunities या Forecasts नहीं मिलते, और Customer Community यूज़र्स Opportunity इस्तेमाल नहीं कर सकते। (अब मैं सब कुछ उलझा देता हूँ: लाइसेंसिंग)
• मैं बाहरी लाइसेंस के स्तर जानता हूँ: Customer Community, Customer Community Plus (रिपोर्ट, डैशबोर्ड, स्टैंडर्ड शेयरिंग), Partner Community (सेल्स ऑब्जेक्ट); और यह कि Partner Community को Person Account के साथ इस्तेमाल नहीं किया जा सकता। (स्टेडियम)
• मैं member-based बनाम login-based लाइसेंसिंग जानता हूँ, और यह कि कौन-सी किस आबादी के लिए ठीक है। (वे कैसे भुगतान करते हैं, इससे डिज़ाइन बदलता है)
• मैं जानता हूँ कि कुछ प्लेटफ़ॉर्म लाइसेंस यूज़र्स को दस कस्टम ऑब्जेक्ट तक के एक ऐप तक सीमित रखते हैं, और उसके भीतर काम करने के लिए रिकॉर्ड टाइप वाला पैटर्न भी। (जब लाइसेंस मॉडल को आकार देता है)
• मैं जानता हूँ कि Salesforce Integration लाइसेंस सिस्टम-से-सिस्टम, सिर्फ़ API वाले यूज़र्स के लिए है। (अब सिर्फ़ लोग ही यूज़र नहीं हैं)
• मैं जानता हूँ कि SLA रिपोर्टिंग के लिए entitlements और milestones चाहिए, जिनके लिए Service लाइसेंस चाहिए। (अब मैं सब कुछ उलझा देता हूँ: लाइसेंसिंग)

SDM-2: डेटा को एकरूप रखना

• मैं किसी नियम को सुसंगतता की सीढ़ी के सही डंडे पर रख सकता हूँ: फ़ील्ड टाइप और शब्दावली, required और unique, वैलिडेशन रूल, डुप्लिकेट रूल, ऑटोमेशन। (डेटा को सुसंगत रखना)
• मैं जानता हूँ कि प्रतिबंधित पिकलिस्ट सूची से बाहर की वैल्यू ठुकरा देती है, API से आने पर भी, और ग्लोबल वैल्यू सेट एक ही सूची कई फ़ील्ड में साझा करता है (1,000 वैल्यू तक)। (पहला डंडा)
• मैं जानता हूँ कि पेज लेआउट की अनिवार्यता सिर्फ़ उस स्क्रीन को बचाती है, डेटा को नहीं, और वैलिडेशन रूल हर save पर चलते हैं। (UI वैलिडेशन डेटा वैलिडेशन नहीं है, तीसरा डंडा)
• मैं किसी वैलिडेशन रूल का दायरा ISNEW() और ISCHANGED(), एक कस्टम permission या गो-लाइव की तारीख़ से तय कर सकता हूँ, यह जानते हुए कि हर विकल्प कौन-से saves अब भी जाँचता है (उनमें वे भी जो मेरे नियंत्रण में नहीं, जैसे batch में owner बदलना या कोई roll-up)। (पुराने रिकॉर्ड की समस्या)
• मैं मैचिंग रूल और डुप्लिकेट रूल जानता हूँ, मॉड्यूल में बताई गई सीमाएँ (हर ऑब्जेक्ट पर पाँच सक्रिय डुप्लिकेट रूल, हर एक में तीन मैचिंग रूल), और यह कि वे अलग-अलग सिस्टमों के बीच पहचान की समस्या हल नहीं करते। (चौथा डंडा: डुप्लिकेट रूल)
• मैं जानता हूँ कि डुप्लिकेट रूल एक ही पल में save हुए रिकॉर्ड की आपस में तुलना नहीं करते, कि API और import से होने वाले saves बिना किसी चेतावनी के रोक दिए जाते हैं, और कि एक save और उससे शुरू होने वाला सब कुछ एक ही ट्रांज़ैक्शन के रूप में वापस (roll back) होता है। (चौथा डंडा, सब या कुछ नहीं)
• मैं जानता हूँ कि Workflow Rules और Process Builder का सपोर्ट खत्म हो चुका है; ऑटोमेशन का मतलब है Flow या Apex। (पाँचवाँ डंडा: ऑटोमेशन)

परीक्षा से आगे

परीक्षा फ़र्श है, छत नहीं। ये इस अध्याय की वे आदतें हैं जो एक आर्किटेक्ट को चाहिए, चाहे कोई सवाल कभी उनके बारे में पूछे या न पूछे।

• प्लेटफ़ॉर्म का एक आकार होता है। जिस प्लेटफ़ॉर्म पर आप हैं, उसके लिए डिज़ाइन करें, किसी आम डेटाबेस के लिए नहीं।
• मदरशिप की ओर देखें। कोई कॉन्सेप्ट ईजाद करने से पहले देखें कि Salesforce उसे कैसे मॉडल करता है।
• हर ऑब्जेक्ट एक प्रतिबद्धता है: स्टोरेज, सीमाएँ, एक शेयरिंग मॉडल, लाइसेंस और निर्भरताएँ।
• ऑब्जेक्ट चुनने से पहले पूछें कि डेटा कहाँ रहता है: core पर, संदर्भित, या आर्काइव।
• कोई भी API नाम पढ़ें और आप जान जाते हैं कि उसे किसने बनाया, और आप क्या बदल सकते हैं।
• अगर आप आज आर्काइव नहीं कर रहे, तो क्या कभी करेंगे?
• big object सुझाने से पहले उनका प्रोटोटाइप बनाएँ।
• बिज़नेस के अलग नामों का मतलब अपने-आप अलग ऑब्जेक्ट नहीं होता।
• पूछें कि किन पहचानों (identities) को डेटा चाहिए: लोग, ग्राहक, पार्टनर, इंटीग्रेशन और एजेंट।
• हर फ़ील्ड को एक description मिलता है, और जहाँ मायने रखता हो, वर्गीकरण भी।
• पहले संबंध का व्यवहार बताएँ; कॉन्फ़िगरेशन उसे लागू करता है। किसी फ़ीचर के लिए मॉडल को न बिगाड़ें।
• डिलीट का सवाल: अगर कोई पैरेंट को डिलीट कर दे, तो चाइल्ड का क्या होना चाहिए?
• चुनें कि कौन-सी कड़ी श्रृंखला तोड़ती है: lookup वहाँ बनाएँ जहाँ चाइल्ड की सच में अपनी ज़िंदगी है।
• स्वामित्व primary से, एक्सेस दोनों से: सबसे सख़्त नियम जीतता है।
• निष्क्रिय और ख़त्म को अलग रखें, और रिटेंशन को एक बिज़नेस नियम बनाएँ।
• नियम को उतना नीचे रखें जितना वह सही मायने में जाता है, और जायज़ इतिहास को दोबारा लिखने के बजाय उसे एक बायपास दें।
• डायग्राम आर्किटेक्चर नहीं है। हर संरचना का सिरा किसी बिज़नेस कारण तक ढूँढ पाएँ।

जानने लायक शब्द

शब्द	एक पंक्ति में
मेटाडेटा-आधारित (Metadata-driven)	ऑब्जेक्ट और फ़ील्ड ऐसी परिभाषाएँ हैं जिन्हें प्लेटफ़ॉर्म रनटाइम पर पढ़ता है, नई भौतिक टेबल नहीं
Multitenancy	कई orgs इन्फ़्रास्ट्रक्चर साझा करते हैं, हर एक अलग-थलग, जैसे एक बिल्डिंग में अपार्टमेंट
Governor limits	वे सीमाएँ जो किसी एक tenant को साझा संसाधनों पर एकाधिकार करने से रोकती हैं
एक्सटर्नल ऑब्जेक्ट (External object)	Salesforce Connect के ज़रिए Salesforce में दिखने वाला डेटा, जो हर बार छूने पर अपने स्रोत से लाया जाता है
Big object	बहुत बड़े, कभी-कभार इस्तेमाल होने वाले डेटा के लिए स्टोरेज, जिसकी क्वेरी उसके इंडेक्स से होती है
Person Account	एक व्यक्ति, जिसे Account के रूप में दर्शाया जाता है, business-to-consumer मॉडल के लिए
साफ़ फ़िट (Clean fit)	ऐसा बिज़नेस कॉन्सेप्ट जो किसी स्टैंडर्ड ऑब्जेक्ट के इच्छित उद्देश्य से मेल खाता है
External ID	एक फ़ील्ड जिसमें किसी दूसरे सिस्टम का पहचानकर्ता (identifier) होता है, upsert और मिलान के लिए
Upsert	रिकॉर्ड मौजूद हो तो उसे अपडेट करें, न हो तो बनाएँ
Lookup	ऐसा संबंध जिसमें चाइल्ड का अपना owner और अपनी ज़िंदगी रहती है
Master-detail	ऐसा संबंध जिसमें चाइल्ड पैरेंट का होता है: विरासत में मिला owner और शेयरिंग, कैस्केड डिलीट, roll-ups
तार्किक जंक्शन ऑब्जेक्ट (Logical junction object)	मॉडलिंग का विचार: एक ऑब्जेक्ट जो many-to-many में दो दूसरे ऑब्जेक्ट को जोड़ता है और अपने एट्रिब्यूट रखता है, चाहे उसे कैसे भी बनाया जाए
Salesforce Junction Object	Salesforce “junction object” से जो मतलब लेता है: दो master-detail संबंधों वाला एक कस्टम ऑब्जेक्ट
Primary और secondary master	Salesforce Junction Object का पहले बना master-detail (owner, look, division) और उसका दूसरा (रिपोर्ट का दायरा; पहला हटाया जाए तो यह primary बन जाता है)
Hierarchical संबंध	एक खास lookup जो सिर्फ़ User ऑब्जेक्ट पर होता है, जैसे Manager, जो उसी यूज़र पर वापस नहीं आ सकता
Namespace prefix	managed package के ऑब्जेक्ट और फ़ील्ड पर vendor का prefix, जैसे abc__Inspection__c
Share table	share ऑब्जेक्ट (AccountShare, Truck__Share), जिसमें किसी रिकॉर्ड की ज़्यादातर शेयरिंग रहती है, हर यूज़र या ग्रुप के लिए एक पंक्ति, उसके reason के साथ
Roll-up summary	master पर एक फ़ील्ड जो उसके details को गिनता है, जोड़ता है, या उनमें न्यूनतम या अधिकतम ढूँढता है
Data skew	एक पैरेंट या एक owner के नीचे बहुत ज़्यादा रिकॉर्ड, जिससे लॉक और लंबी शेयरिंग पुनर्गणना होती है
Member-based / login-based	हर बाहरी यूज़र के हिसाब से भुगतान, या हर महीने हर लॉगिन के हिसाब से
सुसंगतता की सीढ़ी (Consistency ladder)	डेटा के नियम लागू करने वाली परतें, फ़ील्ड टाइप से लेकर ऑटोमेशन तक
प्रतिबंधित पिकलिस्ट (Restricted picklist)	ऐसी पिकलिस्ट जो अपनी सूची से बाहर की कोई भी वैल्यू ठुकरा देती है, स्रोत चाहे कोई भी हो
डेटा वर्गीकरण (Data classification)	owner, उपयोग, संवेदनशीलता और compliance श्रेणी के लिए फ़ील्ड मेटाडेटा

खुद को परखें

कोर्स की शैली में छोटे परिदृश्य। खोलने से पहले अपना जवाब तय कर लें।

1. यूज़र्स को ऑर्डर की वह जानकारी देखनी है जिसका मालिक ERP है और जिसे वह दिन भर अपडेट करता है। वे इसे Salesforce में एडिट नहीं करते। इसे कॉपी करके लाएँ या नहीं?

इसे संदर्भित करें: Salesforce Connect के ज़रिए एक्सटर्नल ऑब्जेक्ट ERP को सच का स्रोत बनाए रखते हैं, और सिंक करने के लिए कोई कॉपी नहीं होती। यह मान लें कि हर बार देखने पर एक callout होता है, इसलिए latency और ERP की उपलब्धता मायने रखती है, और यह भारी एडिटिंग या रिपोर्टिंग के बजाय पढ़ने के लिए बेहतर है। फिर से पढ़ें: संदर्भित।

2. बिज़नेस डिस्ट्रिब्यूटर, सप्लायर और रिटेल पार्टनर ट्रैक करना चाहता है। तीन कस्टम ऑब्जेक्ट?

नहीं। ये सब कंपनियाँ हैं, इसलिए Account साफ़ फ़िट है; अलग-अलग नाम भूमिकाएँ हैं, जिन्हें एक type, एक रिकॉर्ड टाइप या एक संबंध दर्शाता है। फिर से पढ़ें: साफ़ फ़िट की कसौटी।

3. एक डिज़ाइन Opportunity इस्तेमाल करता है, लेकिन जिन लोगों को डेटा चाहिए, उनमें से ज़्यादातर के पास Salesforce Platform या Customer Community लाइसेंस हैं। अब क्या?

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

4. ERP हर रात Accounts के अपडेट भेजता है। Salesforce ID के लिए क्वेरी किए बिना इंटीग्रेशन सही रिकॉर्ड कैसे ढूँढे?

ERP का ग्राहक नंबर एक External ID फ़ील्ड में स्टोर करें और उस पर upsert करें: मिले तो अपडेट, न मिले तो नया बनाएँ। चाइल्ड रिकॉर्ड भी अपने पैरेंट के External ID से उसकी ओर इशारा कर सकते हैं। फिर से पढ़ें: External ID।

5. एक डिलीवरी आइटम अपनी डिलीवरी के बिना मौजूद नहीं रह सकता, कभी कहीं नहीं जाता, और उसे अपना owner नहीं चाहिए। एक डिलीवरी रूट तय होने से पहले मौजूद होती है और दूसरे रूट पर जा सकती है। हर एक के लिए कौन-सा संबंध?

डिलीवरी आइटम से डिलीवरी: master-detail (वह जीवन भर पैरेंट का है, एक्सेस विरासत में पाता है, डिलीट पर कैस्केड होता है)। डिलीवरी से रूट: lookup (उसकी अपनी ज़िंदगी है, शुरू में वैकल्पिक, दूसरी जगह जा सकती है, और रूट डिलीट करने से डिलीवरी कभी डिलीट नहीं होनी चाहिए)। फिर से पढ़ें: बिज़नेस के रिश्ते से शुरू करें।

6. एक इंटीग्रेशन रोज़ 3,300 डिलीवरी बनाता है, सबका मालिक इंटीग्रेशन यूज़र है, जिसका रोल हायरार्की के बीच में है। जोखिम क्या है, और इलाज क्या?

Ownership skew: 10,000 रिकॉर्ड के बाद, उस यूज़र को खिसकाने या उसके ग्रुप बदलने से लंबी शेयरिंग पुनर्गणना शुरू होती है। अगर एक्सेस के लिए स्वामित्व मायने रखता है तो उसे बाँटें; वरना इंटीग्रेशन यूज़र को रोल हायरार्की से बाहर रखें, या सबसे ऊपर किसी रोल में अकेला रखें, और शेयरिंग रूल में इस्तेमाल होने वाले ग्रुप्स से बाहर रखें। फिर से पढ़ें: स्वामित्व स्केल की समस्या बन सकता है।

7. आप एक वैलिडेशन रूल जोड़ते हैं, और 20,000 पुराने रिकॉर्ड उसे तोड़ते हैं। एक यूज़र उनमें से एक पर फ़ोन नंबर बदलता है और save विफल हो जाता है। नियम को क्या करना चाहिए था?

सिर्फ़ यह नहीं बताना था कि क्या सच होना चाहिए, बल्कि यह भी कि कब लागू करना है: संबंधित फ़ील्ड पर ISNEW() या ISCHANGED() से उसका दायरा तय करें, और नियम से पहले के रिकॉर्ड का इतिहास दोबारा लिखने के बजाय उन्हें सोचा-समझा बायपास दें। फिर से पढ़ें: पुराने रिकॉर्ड की समस्या।

8. बिज़नेस चाहता है कि हर डिलीवरी फ़ोटो “Salesforce में” हो: साल में चार से पाँच मिलियन, और 30 प्रतिशत की बढ़त। आप क्या प्रस्ताव देंगे?

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

9. एक क्रू असाइनमेंट (Crew Assignment) के master-detail संबंध क्रू (पहले बना) और ट्रक से हैं। एक डिस्पैचर क्रू देख सकता है, लेकिन ट्रक नहीं। क्या वह क्रू असाइनमेंट देख सकता है?

नहीं। क्रू primary है, इसलिए वह असाइनमेंट को उसका owner और look देता है, लेकिन एक्सेस के लिए दोनों पैरेंट चाहिए: डिस्पैचर को क्रू और ट्रक, दोनों का एक्सेस चाहिए, उस स्तर पर जो हर master-detail फ़ील्ड की Sharing Setting माँगती है। सबसे सख़्त नियम जीतता है। फिर से पढ़ें: दो parent चौड़ा।

10. एक पार्टनर मैनिफ़ेस्ट फ़ाइल दोबारा भेजता है, और उसमें एक ही ग्राहक दो बार है। Account पर आपका एक डुप्लिकेट रूल block पर सेट है। क्या आप सुरक्षित हैं?

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

और जानें

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-09-25 को जाँचा गया): उद्देश्यों और उनके वेटेज की आधिकारिक सूची। परीक्षा बुक करने से पहले हमेशा मौजूदा संस्करण देखें।
• हर मॉड्यूल का अपना “और जानें” खंड उसके प्लेटफ़ॉर्म तथ्यों के पीछे के Salesforce दस्तावेज़ बताता है, जाँचने की तारीख़ के साथ।