स्टैंडर्ड डेटा मॉडल

🌐 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 (कुल 10 में से) — अध्याय Salesforce डेटा आर्किटेक्चर, Data Architect कोर्स का अध्याय 3। हर मॉड्यूल अपने आप में पूरा है। पिछला: Salesforce डेटा प्लेटफ़ॉर्म: डेटाबेस से कहीं बढ़कर · अगला: अपना खुद का बनाएँ: कस्टम ऑब्जेक्ट

यह मॉड्यूल किस सवाल का जवाब देता है: Salesforce ने आपके लिए पहले से क्या मॉडल कर रखा है, और वह किस तरह जुड़ा है?

मॉड्यूल 1 में मैंने आपसे कहा था कि मदरशिप की ओर देखें: कुछ नया ईजाद करने से पहले देखें कि खुद Salesforce उसे कैसे करता है। इस मॉड्यूल में हम सच में देखते हैं। Salesforce ने अपने स्टैंडर्ड ऑब्जेक्ट में आपके बिज़नेस का बहुत-सा हिस्सा पहले से मॉडल कर रखा है, और मैं जिन orgs में जाता हूँ, उनमें से ज़्यादातर में दो मॉडल ही ज़्यादातर काम करते हैं: Sales मॉडल और Service मॉडल। कोई चीज़ कस्टम ऑब्जेक्ट की हकदार है या नहीं, यह तय करने से पहले आपको जानना होगा कि वहाँ पहले से क्या है। यही अगले दो मॉड्यूल हैं।

ऑब्जेक्ट को स्टैंडर्ड क्या बनाता है

स्टैंडर्ड ऑब्जेक्ट बॉक्स से बाहर ही मिलता है। उसे Salesforce ने बनाया है, उसका एक तय उद्देश्य है, और वह अपने फ़ील्ड और संबंधों के साथ आता है। आप उसमें फ़ील्ड जोड़ सकते हैं, उसके आसपास ऑटोमेशन बना सकते हैं और उसके लेआउट बदल सकते हैं, लेकिन उसे नए सिरे से डिज़ाइन नहीं कर सकते: स्टैंडर्ड फ़ील्ड और संबंध Salesforce के हैं।

नामों पर ध्यान दें। Account, Contact, Case। न कोई prefix, न कोई suffix। यह जगह Salesforce ने अपने लिए रखी है। हम जो कुछ भी बनाते हैं, वह __c पर खत्म होता है, ताकि Salesforce कभी भी नए स्टैंडर्ड ऑब्जेक्ट जोड़ सके और आपके org की किसी चीज़ से टकराव न हो। और वह हर रिलीज़ में ऐसा करता भी है।

कभी किसी ने एक product ऑब्जेक्ट बनाया था जो चला नहीं और उसे पीछे छोड़ना पड़ा। इसीलिए API नाम Product2 है। जब कोई मुझसे कहता है कि वह Salesforce जानता है, तो यह मेरी पहली कसौटी होती है।

Sales मॉडल

बाईं ओर से शुरू करें, Lead से: कोई ऐसा जो ग्राहक बन सकता है। Lead अभी असल में मॉडल का हिस्सा नहीं है। यह एक होल्डिंग एरिया (इंतज़ार की जगह) है। जब आप उसे convert करते हैं, तो Salesforce असली रिकॉर्ड बनाता है: एक Account, एक Contact, और अगर कोई सौदा है, तो एक Opportunity। इसीलिए मैं Lead को एक तरफ़ अलग बनाता हूँ।

Account कंपनी है। उसके Contacts वहाँ के लोग हैं। Opportunity उस Account के साथ एक सौदा है। अब तक कुछ भी अनपेक्षित नहीं।

अब बात दिलचस्प होती है। सौदे में क्या है? हर लाइन एक Opportunity Product है, और Opportunity Product सीधे Product की ओर इशारा नहीं करता। वह एक Price Book Entry की ओर इशारा करता है: यह प्रोडक्ट, इस कीमत पर, इस price book में। Price Book Entry, Product और Price Book के बीच बैठता है, ताकि एक ही प्रोडक्ट की स्टैंडर्ड price book में एक कीमत हो और आपकी पार्टनर price book में दूसरी।

यानी दो संबंध जो एक के बाद एक चीज़ें बन गए। अध्याय 2 का डिलीवरी आइटम (Delivery Item) याद है, डिलीवरी और प्रोडक्ट के बीच, और कुत्ते का करतब, कुत्ते और करतब के बीच? Salesforce ने यहाँ ठीक यही किया है, दो बार: Opportunity Product, Opportunity और Price Book Entry के बीच, और Price Book Entry, Product और Price Book के बीच। जब आप इसे पढ़ सकते हैं, तो आप स्टैंडर्ड डेटा मॉडल का ज़्यादातर हिस्सा पढ़ सकते हैं।

Click to enlarge

यह रही वह कड़ी करीब से, उन फ़ील्ड के साथ जो इसे जोड़े रखते हैं:

Click to enlarge

एक नियम जिस पर लोग अटकते हैं: एक स्टैंडर्ड price book होती है, और किसी भी दूसरी price book की Price Book Entry सीधे प्रोडक्ट की स्टैंडर्ड कीमत इस्तेमाल कर सकती है। किसी Opportunity के प्रोडक्ट लोड करने से पहले जान लें कि वह कौन-सी price book इस्तेमाल करती है।

Service मॉडल

अब घर का दूसरा हिस्सा। वही Account, वही Contacts। जब कुछ गड़बड़ होती है, तो ग्राहक एक Case खोलता है।

Case आमतौर पर किसी ऐसी चीज़ के बारे में होता है जो ग्राहक के पास है, और Salesforce के पास उसके लिए एक ऑब्जेक्ट है: Asset। मॉड्यूल 5 में मैं इसे वह स्टैंडर्ड ऑब्जेक्ट कहूँगा जिसे लोग नज़रअंदाज़ कर देते हैं। यह ऐसी चीज़ है जो ग्राहक के पास है, चाहे उसने आपसे खरीदी हो या नहीं।

और ग्राहक किस चीज़ का हकदार है? वह है Entitlement: वह सपोर्ट जो किसी Account को मिलना चाहिए, जो अक्सर किसी asset, प्रोडक्ट या सर्विस कॉन्ट्रैक्ट से जुड़ा होता है। Case पर एक Entitlement लगाइए, और अब Case जानता है कि उसे किस स्तर का सपोर्ट मिलना चाहिए।

Click to enlarge

उस लाइन को देखें जो Case से वापस खुद Case तक जाती है। हर Case में एक Parent Case फ़ील्ड होता है, और वह किसी दूसरे Case की ओर इशारा करता है। यह एक self-lookup है: किसी ऑब्जेक्ट का खुद से संबंध। पहली बार देखने पर यह बहुत लोगों को उलझा देता है, इसलिए यहाँ दो वजहें हैं जिनके लिए मैं इसे इस्तेमाल करता हूँ।

पहली: एक बड़ी समस्या जो छोटी-छोटी समस्याओं में बँट जाती है। ग्राहक बताता है कि पूरा इंस्टॉलेशन बंद है। हम नेटवर्क, हार्डवेयर और कॉन्फ़िगरेशन के लिए sub-case खोलते हैं, हर एक पर अलग से काम होता है, और वे सब ऊपर की ओर हल होते हैं: जब तक वे पूरे न हों, parent case पूरा नहीं होता।

दूसरी: इतिहास। पिछले महीने एक Case बंद हुआ था, और अब वही समस्या लौट आई है। नया Case मूल Case की ओर इशारा करता है, ताकि जो भी उसे खोले, वह देख सके कि यह पहले भी हो चुका है, और उसके बारे में क्या किया गया था।

मॉड्यूल 7 में संबंधों तक पहुँचने पर हम self-lookup पर लौटेंगे।

ध्यान दें कि Account और Contact दोनों डायग्राम में एक ही जगह पर हैं। ये वही रिकॉर्ड हैं। एक सेल्स रिप और एक सर्विस एजेंट एक ही ग्राहक को देख रहे हैं, घर के अलग-अलग हिस्सों से। स्टैंडर्ड पर टिके रहने का यह सबसे मज़बूत तर्कों में से एक है: ये मॉडल आपस में मिलने के लिए ही बनाए गए थे।

फ़ाइलें और Attachments

रिकॉर्ड पर सब कुछ फ़ील्ड नहीं होता। कॉन्ट्रैक्ट, फ़ोटो, PDF और स्प्रेडशीट फ़ाइलें हैं, और उनकी जगह Salesforce Files में है, पुराने Attachments मॉडल में नहीं, जो legacy है। अगर दस्तावेज़ पहले से SharePoint Online, OneDrive, Google Drive या Box में है, तो Files Connect यूज़र को उसे Salesforce में कॉपी किए बिना Salesforce से ही खोलने देता है।

फ़ाइलें रिकॉर्ड से अलग तरीके से गिनी जाती हैं। Salesforce स्टोरेज को दो हिस्सों में बाँटता है: file storage में attachments, Files, Salesforce CRM Content, Chatter फ़ाइलें वगैरह रहती हैं, और data storage में आपके रिकॉर्ड। जब हर रिकॉर्ड के साथ फ़ोटो या स्कैन जुड़ते हैं, तो file storage तेज़ी से बढ़ता है, इसलिए बड़ी संख्या में इमेज, जैसे किसी फ़ील्ड ऐप की फ़ोटो, की जगह अक्सर पूरी तरह Salesforce से बाहर होती है, और Salesforce सिर्फ़ एक लिंक रखता है। मॉड्यूल 4 इस पर लौटता है।

दो कॉलम हों या दो सौ

data storage भी किसी डेटाबेस से अलग तरीके से गिना जाता है। आम डेटाबेस में दो कॉलम और एक मिलियन पंक्तियों वाली टेबल छोटी होती है, और सौ कॉलम और एक मिलियन पंक्तियों वाली टेबल एक हाथी। Salesforce दोनों को बराबर तौलता है: ज़्यादातर रिकॉर्ड लगभग 2 KB के गिने जाते हैं, चाहे उनमें कितने भी फ़ील्ड हों। कुछ अपवाद हैं। एक campaign ज़्यादा गिना जाता है, एक email message अपने असली आकार में गिना जाता है, और एक person account लगभग 4 KB गिना जाता है, क्योंकि वह एक Account भी है और एक Contact भी।

एक सुझाव। जब भी मैं किसी नए org में जाता हूँ, तो सबसे पहले जिन जगहों पर जाता हूँ, उनमें से एक है Setup → Storage Usage। पहली ही कॉल पर मैं क्लाइंट से उसका स्क्रीनशॉट तक माँग लेता हूँ। वह स्क्रीन झूठ नहीं बोलती। वह बताती है कि कौन-से ऑब्जेक्ट बढ़ रहे हैं, और कौन-से पहले से ही हाथी बन चुके हैं।

Person Account: जब ग्राहक एक व्यक्ति हो

Account और Contact का मॉडल किसी कंपनी और वहाँ के लोगों के लिए बढ़िया काम करता है। लेकिन अगर आपका ग्राहक कंपनी नहीं है तो? अगर वह एक व्यक्ति है तो?

इसके लिए है person account: एक Account और एक Contact, एक ही रिकॉर्ड में जुड़े हुए, अलग-अलग व्यक्तियों के लिए। उनके Contact फ़ील्ड साथ आते हैं, और कस्टम फ़ील्ड अपने suffix __pc के साथ दिखते हैं। हर person account, Account और Contact दोनों के स्टोरेज में गिना जाता है, क्योंकि अंदर से वह दोनों है।

इन्हें चालू करने से पहले एक चेतावनी: person account एक बार enable होने के बाद disable नहीं किए जा सकते। यह अध्याय 1 की पलटने की कसौटी (Reversibility Test) अपने सबसे शुद्ध रूप में है। ये कब फ़ायदेमंद हैं, इस पर मेरी राय मॉड्यूल 5 में है।

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

• कुछ भी नया डिज़ाइन करने से पहले, बिज़नेस के कौन-से हिस्से Salesforce पहले ही मॉडल कर चुका है।
• कोई अवधारणा Sales मॉडल में जाएगी, Service मॉडल में या दोनों में, यह जानते हुए कि दोनों Account और Contact साझा करते हैं।
• दस्तावेज़ और इमेज कहाँ रहेंगे: Salesforce Files में, किसी जुड़े हुए फ़ाइल सिस्टम में, या प्लेटफ़ॉर्म से बाहर एक लिंक के साथ।
• डेटा का स्टोरेज में कितना खर्च होगा, उसी तरह गिनकर जैसे Salesforce गिनता है: रिकॉर्ड से, कॉलम से नहीं।
• ग्राहक एक कंपनी है या एक व्यक्ति, कोई ऐसी चीज़ चालू करने से पहले जिसे बंद नहीं किया जा सकता।

और जब Salesforce के पास वह न हो जो आपको चाहिए? तब आप उसे बनाते हैं। वह आगे है।

और जानें

• OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): किसी Opportunity से जुड़े Product2 प्रोडक्ट की सूची का एक सदस्य (“a member of the list of Product2 products associated with an Opportunity”); Price Book Entry अनिवार्य है।
• PricebookEntry (opens in a new tab), Object Reference (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): Pricebook2 और Product2 के बीच एक जुड़ाव (“an association between a Pricebook2 and Product2”); एक entry स्टैंडर्ड कीमत इस्तेमाल कर सकती है।
• Case (opens in a new tab), Object Reference (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): ParentId, हायरार्की में parent case का ID, जिसका लेबल Parent Case है (“the ID of the parent case in the hierarchy. The label is Parent Case”); Case का एक lookup।
• Entitlement (opens in a new tab), Object Reference (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): वह ग्राहक सपोर्ट जो किसी Account या Contact को मिलना चाहिए (“the customer support an account or contact is eligible to receive”), जो किसी asset, प्रोडक्ट या सर्विस कॉन्ट्रैक्ट पर आधारित हो सकता है।
• Data and Storage Resources (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): file storage और data storage में क्या-क्या आता है।
• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): ज़्यादातर Salesforce रिकॉर्ड लगभग 2 KB data storage लेते हैं (“Most Salesforce records consume approximately 2 KB of data storage”); person account लगभग 4 KB।
• Enable Person Accounts (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): Person Accounts एक बार enable होने के बाद disable नहीं हो सकता (“After Person Accounts is enabled, it can’t be disabled.”)।
• Files Connect FAQ (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-09-25 को जाँचा गया)।