सही ऑब्जेक्ट चुनें

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: किसी बिज़नेस अवधारणा को किस तरह का Salesforce ऑब्जेक्ट बनना चाहिए, और लाइसेंस क्या करने देते हैं?

Salesforce में सबसे आसान कामों में से एक है कस्टम ऑब्जेक्ट बनाना। ठीक इसी वजह से मुझे लगता है कि हम ज़रूरत से ज़्यादा बना लेते हैं।

आप एक requirements सेशन में हैं और कोई कहता है, “हमें अपने डिस्ट्रिब्यूटर ट्रैक करने हैं।” नया कस्टम ऑब्जेक्ट: Distributor। हो गया। बस, मैं चाहता हूँ कि आर्किटेक्ट पहले एक अलग सवाल पूछे: डिस्ट्रिब्यूटर है क्या? यह एक कंपनी है। Salesforce के पास कंपनी को दर्शाने का पहले से एक काफ़ी अच्छा तरीका है। उसे Account कहते हैं। इसका मतलब यह नहीं कि जवाब हमेशा Account ही है। लेकिन अगर मुझे समझाना पड़े कि कोई कंपनी Account क्यों नहीं है, तो मुझे “बिज़नेस उन्हें डिस्ट्रिब्यूटर कहता है” से बेहतर वजह चाहिए।

यहीं अध्याय 2 का लॉजिकल मॉडल प्लेटफ़ॉर्म से मिलता है, और मेरी शुरुआती राय सीधी है: अगर बिज़नेस अवधारणा किसी स्टैंडर्ड ऑब्जेक्ट के तय उद्देश्य में साफ़-साफ़ बैठती है, तो वहीं से शुरू करें।

अर्थ से शुरू करें

जब कोई चीज़ ऑब्जेक्ट बनने की हकदार हो, तब भी वह अपने-आप कस्टम ऑब्जेक्ट बनने की हकदार नहीं हो जाती। पूछें कि वह चीज़ असल में किसे दर्शाती है। किसी भी रूप का कोई बिज़नेस या संगठन? Account से शुरू करें। उस संगठन के साथ काम करने वाला कोई व्यक्ति? Contact। कोई चीज़ जो ग्राहक के पास है या उसने खरीदी है? Asset। कोई चीज़ जिसे आप बेचने की कोशिश कर रहे हैं? अब Opportunity बातचीत में आती है।

इसीलिए हमने मॉड्यूल 2 में सबसे पहले मदरशिप की ओर देखा। वे मॉडल हर बिज़नेस में फ़िट नहीं होते, लेकिन हमें उन्हें सिर्फ़ इसलिए नज़रअंदाज़ नहीं करना चाहिए कि अपना बनाना ज़्यादा साफ़-सुथरा लगता है। New Custom Object से पहले पूछें कि Salesforce इस अवधारणा को कैसे मॉडल करता है, उस मॉडल के आसपास क्या-क्या बना है, और उसकी जगह कुछ और रखने पर आप क्या खो देंगे।

साफ़ फ़िट की कसौटी

मेरी कसौटी एक सवाल है: क्या यह बिज़नेस अवधारणा स्टैंडर्ड ऑब्जेक्ट के तय उद्देश्य में साफ़-साफ़ बैठती है? अगर बैठती है, तो मेरा झुकाव स्टैंडर्ड ऑब्जेक्ट की ओर होता है।

डिस्ट्रिब्यूटर एक कंपनी है जिससे हमारा रिश्ता है, इसलिए Account साफ़ फ़िट है। मुझे इससे कोई दिक्कत नहीं कि यूज़र एक कंपनी को डिस्ट्रिब्यूटर कहते हैं, दूसरी को सप्लायर, तीसरी को रिटेल पार्टनर और चौथी को ग्राहक। ये बिज़नेस की भूमिकाएँ हैं, और इनके लिए चार भौतिक ऑब्जेक्ट की ज़रूरत नहीं। बिज़नेस के अलग नामों का मतलब अपने-आप अलग डेटा संरचनाएँ नहीं होता। एक type, एक रिकॉर्ड टाइप या एक संबंध यह फ़र्क संभाल सकता है।

यह कसौटी उलटी दिशा में भी काम करती है। अध्याय 1 में मैंने आपके लिए एक सवाल छोड़ा था: एक ग्राहक के बिज़नेस की कई डिलीवरी लोकेशन हैं। क्या हर लोकेशन एक Account होनी चाहिए, या एक कस्टम ऑब्जेक्ट?

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

एक कस्टम ऑब्जेक्ट, Account का child, हल्का हो सकता है: बस पते के फ़ील्ड, एक जगह जहाँ हम डिलीवरी करते हैं, अपने जीवनचक्र के साथ जिसे मैं अलग से नियंत्रित कर सकता हूँ।

तो यह एक संतुलन है: आप जो बोझ उठाते हैं, बनाम आपको जो फ़ायदा मिलता है। अगर मुझे सिर्फ़ अपने जीवनचक्र वाला एक पता चाहिए, तो वहाँ मैं कस्टम जाता हूँ।

Case के sub-issues के साथ भी यही बात है। अगर हर sub-issue सच में एक Case है, जिस पर कोई एजेंट काम करता है, अपने status और सर्विस लेवल के साथ, तो उन्हें मॉड्यूल 2 वाले Parent Case से नेस्ट करें। लेकिन अगर यह बस एक checklist आइटम है जिस पर कोई Case की तरह काम नहीं करता, तो एक पूरा Case बहुत-सी ऐसी चीज़ें ढोता है जिन्हें वह कभी इस्तेमाल नहीं करेगा, और एक सीधा-सादा कस्टम child कम भारी हो सकता है। इसलिए नहीं कि कस्टम ज़्यादा साफ़-सुथरा है। इसलिए कि अर्थ अलग है, या बोझ गलत है।

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

जब आप कोई स्टैंडर्ड ऑब्जेक्ट चुनते हैं, तो आप सिर्फ़ उसके फ़ील्ड नहीं चुन रहे होते। आप कुछ ऐसा चुन रहे होते हैं जिसे Salesforce के प्रोडक्ट पहले से समझते हैं: रिपोर्टिंग, ऑटोमेशन, बने-बनाए संबंध, प्रोडक्ट फ़ीचर, AppExchange packages, और जो कुछ भी Salesforce आगे बनाएगा। यह बेहद कीमती हो सकता है।

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

Asset एक अच्छा उदाहरण है

Asset उन स्टैंडर्ड ऑब्जेक्ट में से एक है जिन्हें लोग नज़रअंदाज़ कर देते हैं। मैं इसे सबसे आसान शब्दों में ऐसे कहता हूँ: यह ऐसी चीज़ है जो ग्राहक के पास है। हो सकता है उसने हमसे खरीदी हो, हो सकता है नहीं। मेरे ग्राहक की साइट पर रखे किसी प्रतिस्पर्धी के प्रोडक्ट की भी मुझे परवाह है, क्योंकि मैं उसकी सर्विस कर रहा हूँ, या उसे बदलवाने की कोशिश कर रहा हूँ, या मुझे उनका installed base समझना है। अगर मैं पहले Asset को देखे बिना Customer_Product__c बना दूँ, तो मैंने एक आर्किटेक्चरल सवाल छोड़ दिया। Asset अपने-आप नहीं जीतता, लेकिन उसे परखा जाना चाहिए।

Person Account: व्यक्ति कब Account होता है?

मॉड्यूल 2 में हम person account से मिले थे: एक Account और एक Contact, एक ही रिकॉर्ड में, उन ग्राहकों के लिए जो व्यक्ति हैं। अब निर्णय।

मेरी राय: B2C के लिए, इनके बिना काम चलाना मुश्किल है। Accounts और Contacts के साथ इतना कुछ बॉक्स से बाहर ही आता है कि कीमत और बोझ इसके लायक हैं। और कीमत है: एक business account से लगभग दोगुना स्टोरेज, एक ऐसा स्विच जिसे आप बंद नहीं कर सकते, और कुछ एक्सटर्नल लाइसेंस इन्हें इस्तेमाल नहीं कर सकते। Partner Community को person account के साथ इस्तेमाल नहीं किया जा सकता (Experience Cloud User Licenses (opens in a new tab))। इसलिए सवाल यह नहीं है कि “क्या हमारे डेटाबेस में लोग हैं?” हर org में लोग होते हैं। सवाल है “क्या इस बिज़नेस में व्यक्ति ही असल में Account है?” Contact का व्यक्ति होना उसे person account नहीं बनाता। बिज़नेस का रिश्ता बनाता है।

Click to enlarge

अब मैं सब कुछ उलझा देता हूँ: लाइसेंसिंग

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

तीन आंतरिक लाइसेंस

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

Sales Cloud (अब Agentforce Sales)। इन यूज़र के पास पूरा Salesforce user license होता है: स्टैंडर्ड CRM ऑब्जेक्ट, और कोई भी स्टैंडर्ड या कस्टम ऐप। यानी accounts और contacts के ऊपर leads, opportunities और forecasts, और cases भी: एक सेल्स रिप कॉल से पहले ग्राहक के खुले cases देख सकता है। campaigns बनाने और चलाने के लिए एक और चीज़ चाहिए, Marketing User feature license।

Service Cloud (अब Agentforce Service)। वही Salesforce user license, सर्विस के लिए सेट किया हुआ। Cases केंद्र में होते हैं, जिन पर Service Console में काम होता है: Service Cloud User feature license ही Salesforce Console for Service खोलता है। यहीं service-level agreements (SLA) रहते हैं, entitlement management और milestones के ज़रिए, और यहीं Knowledge आता है, जिसे ज़्यादातर editions एक add-on के रूप में खरीदते हैं।

Platform (Salesforce Platform)। उन लोगों के लिए जिन्हें आपके कस्टम ऐप चाहिए, CRM नहीं। उन्हें accounts, contacts, रिपोर्ट, डैशबोर्ड, दस्तावेज़ और org का हर कस्टम ऐप मिलता है। जो उन्हें नहीं मिलता: forecasts, leads, campaigns और opportunities। इसकी कीमत कम है, ठीक इसीलिए इतने सारे बड़े कस्टम ऐप इस पर चलते हैं, और ठीक इसीलिए यह आपके डेटा मॉडल को मुश्किल में डाल सकता है।

	Sales Cloud	Service Cloud	Platform
User license	Salesforce	Salesforce	Salesforce Platform
किसके लिए बना	बेचना	ग्राहकों को सपोर्ट देना	कस्टम ऐप
Accounts, contacts	हाँ	हाँ	हाँ
Leads, opportunities, forecasts	हाँ	हाँ	नहीं
Cases	हाँ, ग्राहक के cases देखने के लिए	केंद्र में, Service Console में	नहीं
Service-level agreements	नहीं	हाँ, entitlements और milestones	नहीं
कस्टम ऑब्जेक्ट और ऐप	हाँ	हाँ	हाँ

टेबल को वैसे पढ़ें जैसे एक आर्किटेक्ट पढ़ता है। अगर यूज़र का एक बड़ा समूह Platform पर है, तो कोई भी डिज़ाइन जो उनका काम Opportunity पर रखता है, शुरू होने से पहले ही टूटा हुआ है। अगर एक्ज़ीक्यूटिव को SLA के आँकड़े चाहिए, तो उनका लाइसेंस तय करता है कि वे उन्हें देख सकते हैं या नहीं। ये तीन टाइप व्यवहार तय करते हैं।

Click to enlarge

जब लाइसेंस ऑब्जेक्ट तय करता है

Opportunity वह शिकार है जिससे मेरा सबसे ज़्यादा सामना हुआ है। आपने टेबल में देखा: Platform यूज़र को यह नहीं मिलता (Standard User Licenses (opens in a new tab)), और Customer Community यूज़र भी इस पर काम नहीं कर सकते। तो requirement Opportunity जैसी दिखती है, कोई कहता है “चलो Opportunity इस्तेमाल करते हैं,” और फिर मैं पूछता हूँ कि access किसे चाहिए। अगर एक बड़ी आबादी Platform या Customer Community लाइसेंस पर है, तो लाइसेंस अब खरीद-विभाग की कोई बारीकी नहीं रहा। यह एक आर्किटेक्चरल बाधा है, और आमतौर पर डिज़ाइन को कस्टम ऑब्जेक्ट की ओर धकेलती है।

यह ऊपर की ओर भी काम करता है। क्लास में मैं पूछता हूँ: CEO को सुंदर डैशबोर्ड चाहिए; Sales लाइसेंस या Service? एक Sales यूज़र सेल्स ऑब्जेक्ट और cases भी देख सकता है, इसलिए सेल्स डैशबोर्ड और खुले cases की गिनती के लिए Sales ठीक है। लेकिन जिस पल एक्ज़ीक्यूटिव को SLA KPIs चाहिए (किसी case का सर्विस लेवल टूटने में कितना समय बाकी है), वह डेटा entitlements और milestones में रहता है, और entitlement management के लिए Agentforce Service चाहिए, जो पहले Service Cloud था (Supported Editions for Service Features (opens in a new tab))। अब आप एक्ज़ीक्यूटिव के लाइसेंस अपग्रेड कर रहे हैं। बिज़नेस requirement सुनें, और जानें कि उसे जिस डेटा की ज़रूरत है, उसके नीचे कौन-सा लाइसेंस है।

स्टेडियम

मैं लाइसेंस को स्टेडियम की सीटों की तरह देखता हूँ। सब एक ही मैच देख रहे हैं। अगर मैं बीच की महँगी सीटें खरीदूँ, तो दोनों टीमों को करीब से देख सकता हूँ। अगर मैं ऊपर कोने में सस्ती गैलरी में हूँ, तो सीटों पर गद्दी नहीं है और मैं दूरबीन से देख रहा हूँ।

ये हैं एक्सटर्नल लाइसेंस, कंपनी के बाहर के लोगों के लिए: ग्राहक और पार्टनर जो किसी Experience Cloud साइट पर लॉग इन करते हैं। तीन हैं जो मैं चाहता हूँ कि आप जानें।

Customer Community: सस्ती गैलरी। बड़ी संख्या में ऐसे एक्सटर्नल यूज़र के लिए बना जिन्हें cases और knowledge चाहिए: अपने सपोर्ट case का हाल देखता एक ग्राहक। सीटों की कीमत लगभग आधी है और ये बहुत बड़ी संख्या में यूज़र को दी जा सकती हैं। वहाँ ऊपर आप क्या खोते हैं? रिपोर्ट, डैशबोर्ड, और share table: वह role-based शेयरिंग जो ऊपर के स्तरों को मिलती है। यह person account के साथ काम करता है।

Customer Community Plus: लगभग आधे रास्ते नीचे। Salesforce इसे उन एक्सटर्नल यूज़र का लाइसेंस बताता है जिन्हें रिपोर्ट, डैशबोर्ड और स्टैंडर्ड शेयरिंग चाहिए: ऐसा ग्राहक जो दूसरे लोगों का access मैनेज करता है, या जिसे अपने आँकड़े देखने हैं।

Partner Community: और करीब, business-to-business के लिए, सेल्स डेटा तक access के साथ। पार्टनर leads और opportunities पर काम करते हैं: वे deals रजिस्टर करते हैं, और आपके साथ campaigns चलाते हैं। यही वह एक्सटर्नल सीट है जो सेल्स ऑब्जेक्ट तक पहुँचती है। एक पेच: इसे person account के साथ इस्तेमाल नहीं किया जा सकता (Experience Cloud User Licenses (opens in a new tab))।

Click to enlarge

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

वे कैसे भुगतान करते हैं, इससे डिज़ाइन बदलता है

एक और सवाल है जो लोग भूल जाते हैं: ये यूज़र लॉग इन कैसे करेंगे? एक्सटर्नल लाइसेंस दो रूपों में आते हैं। Member-based: आप हर यूज़र के हिसाब से भुगतान करते हैं, जो रोज़ लॉग इन करने वाले 500 पार्टनर के लिए ठीक है। Login-based: आप हर महीने एक तय संख्या में लॉगिन खरीदते हैं, जो साल में कुछ बार लॉग इन करने वाले पाँच मिलियन ग्राहकों के लिए ठीक है। एक ही दिन में एक से ज़्यादा बार लॉग इन करना फिर भी एक लॉगिन गिना जाता है (Experience Cloud User Licenses (opens in a new tab))।

तो जब कोई कहता है “हम एक customer portal बना रहे हैं,” तो मेरा अगला सवाल यह नहीं होता कि कौन-सा template। वह होता है: ग्राहक कौन हैं, कितने हैं, कितनी बार आते हैं, उन्हें कौन-सा डेटा चाहिए, और उन्हें उसके साथ क्या करने की इजाज़त है?

जब लाइसेंस मॉडल को आकार देता है

कभी-कभी लाइसेंस सिर्फ़ ऑब्जेक्ट नहीं चुनता; वह पूरे मॉडल को मोड़ देता है। कुछ platform लाइसेंस यूज़र को ज़्यादा से ज़्यादा दस कस्टम ऑब्जेक्ट वाले एक कस्टम ऐप तक सीमित रखते हैं (उदाहरण के लिए Lightning Platform – One App; Standard User Licenses (opens in a new tab))।

एक शुरुआती प्रोजेक्ट में, एक बड़ी professional-services और construction कंपनी के लिए, हमें पूरे वर्कफ़ोर्स के लिए LinkedIn जैसा कुछ बनाना था: हर किसी की नौकरियाँ, कौशल, सर्टिफ़िकेशन, भाषाएँ और प्रोजेक्ट, ताकि वे किसी खास देश में सर्टिफ़ाइड पुल बनाने वाले को ढूँढ सकें। कोई सीमा न होती, तो मैं user-job, user-skill, user-certification, user-language और user-project ऑब्जेक्ट बनाता, साथ में सर्टिफ़िकेशन और प्रोजेक्ट की रेफ़रेंस सूचियाँ। दस-ऑब्जेक्ट वाले लाइसेंस में, और यह कहे जाने पर कि सारे खर्च न कर दें, यह मुमकिन नहीं था। तो यह “धुन पहचानो” जैसा खेल बन गया: कम से कम कितने ऑब्जेक्ट में मैं इसे बना सकता हूँ? जवाब था दो। एक रेफ़रेंस ऑब्जेक्ट, हर तरह की सूची (नौकरी, कौशल, सर्टिफ़िकेशन, भाषा, प्रोजेक्ट) के लिए एक रिकॉर्ड टाइप के साथ, और एक user attribute ऑब्जेक्ट, मेल खाते रिकॉर्ड टाइप के साथ, जो उसकी ओर इशारा करता था।

यह सबसे अच्छा मॉडल नहीं था। इस पर रिपोर्टिंग सिरदर्द थी, और मैं इसे ज़्यादा साफ़-सुथरा चाहता। लेकिन लाइसेंस यही करने देता था। मैं इन्हें Swiss army knife ऑब्जेक्ट कहता हूँ: इस pattern को अपनी जेब में रखें, और जब सीमाएँ कोई जगह न छोड़ें, तो आपातकालीन शीशा तोड़ें और रिकॉर्ड-टाइप से अलगाव की ओर जाएँ। बस यह जान लें कि आप किस चीज़ का सौदा कर रहे हैं। हर रिकॉर्ड टाइप के लिए अलग permissions की वजह से आपको वैसे भी ऑब्जेक्ट को बाँटना पड़ सकता है।

अब सिर्फ़ लोग ही यूज़र नहीं हैं

लाइसेंसिंग का एक और सवाल अहम हो गया है: उन चीज़ों का क्या जो लोग नहीं हैं? इंटीग्रेशन की अपनी पहचान (identity) होती है। एजेंट की अपनी पहचान होती है। Salesforce के पास अब system-to-system इंटीग्रेशन के लिए Salesforce Integration लाइसेंस है: सिर्फ़ API के लिए, इंसानों के लिए नहीं, और हर Enterprise, Unlimited और Performance Edition org में पाँच शामिल (Standard User Licenses (opens in a new tab))। इसलिए सिर्फ़ यह न पूछें कि किन यूज़र को access चाहिए। पूछें कि किन पहचानों को access चाहिए: एक व्यक्ति, एक ग्राहक, एक पार्टनर, एक इंटीग्रेशन, एक एजेंट। और फिर हर एक को क्या देखना और करना है।

परीक्षा से आगे: AI क्या बदलता है। जैसे-जैसे एजेंट डेटा के एक और उपभोक्ता और निर्माता बनते जा रहे हैं, ऑब्जेक्ट का चुनाव और लाइसेंसिंग सिर्फ़ इंसानों की स्क्रीन के बारे में नहीं रह गए। जानें कि एजेंट किस पहचान से चलता है, वह पहचान किन चीज़ों तक पहुँच सकती है, और क्या मॉडल उसके ज़रूरी डेटा को किसी ऐसे ऑब्जेक्ट या permission के पीछे रख देता है जिसे वह इस्तेमाल नहीं कर सकता।

Steve Trucking: एक आसान, एक मुश्किल

Steve Trucking रिटेल पार्टनर (Retail Partners) के साथ काम करती है। रिटेल पार्टनर क्या है? एक बिज़नेस। आसान: Account। मैं Retail_Partner__c सिर्फ़ इसलिए नहीं बनाता कि किसी ने “पार्टनर” शब्द इस्तेमाल किया।

अब प्राप्तकर्ता (Recipient), वह व्यक्ति जिसे फ़्रिज मिल रहा है। Contact? Person account? कुछ और? साल में एक मिलियन नए प्राप्तकर्ता, जो रिटेल पार्टनर के ग्राहक हैं, हमारे नहीं। यह ठीक उस तरह का सवाल है जहाँ मैं रिश्ते, access और स्केल को समझे बिना किसी ऑब्जेक्ट पर कूदना नहीं चाहता। हम इसे भाग 1 के चेकपॉइंट पर तय करेंगे।

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

• कोई बिज़नेस अवधारणा किसी स्टैंडर्ड ऑब्जेक्ट के तय उद्देश्य में साफ़-साफ़ बैठती है, या उसका अर्थ या बोझ अलग है।
• बिज़नेस के अलग-अलग लेबल अलग-अलग entities हैं, या एक ही entity की बस अलग-अलग भूमिकाएँ।
• क्या डेटा की ज़रूरत वाला हर व्यक्ति, एक्सटर्नल यूज़र, इंटीग्रेशन और एजेंट योजना के लाइसेंस के तहत चुने गए ऑब्जेक्ट तक पहुँच सकता है।
• यूज़र की संख्या और लॉगिन का pattern (member-based या login-based) लाइसेंस और मॉडल को कैसे आकार देते हैं।
• कब कोई लाइसेंस सीमा एक कम-से-आदर्श मॉडल को सही ठहराती है, और उस सौदे की कीमत रिपोर्टिंग और permissions में क्या है।

बात यह नहीं है कि स्टैंडर्ड ऑब्जेक्ट अच्छे हैं और कस्टम ऑब्जेक्ट बुरे। बात यह है कि चुनाव के नतीजे होते हैं, और कभी-कभी वह संज्ञा से तय होता ही नहीं, बल्कि उन लोगों, और मशीनों, से जिन्हें इसे इस्तेमाल करना है।

और जानें

• Salesforce Help, Standard User Licenses (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया, 2026-10-12 को दोबारा जाँचा गया): Platform यूज़र forecasts, leads, campaigns और opportunities के हकदार नहीं हैं; ज़्यादा से ज़्यादा 10 कस्टम ऑब्जेक्ट वाला एक कस्टम ऐप; हर Enterprise Edition org में पाँच Salesforce Integration लाइसेंस।
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया, 2026-10-12 को दोबारा जाँचा गया): Partner Community को person account के साथ इस्तेमाल नहीं किया जा सकता; रिपोर्ट, डैशबोर्ड और स्टैंडर्ड शेयरिंग के लिए Customer Community Plus; एक दिन के कई लॉगिन एक गिने जाते हैं।
• Salesforce Help, Supported Editions for Service Features (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया, 2026-10-12 को दोबारा जाँचा गया): Agentforce Service के साथ service-level agreements (entitlement management); ज़्यादातर editions में Knowledge का अलग खर्च।
• Salesforce Help, Available Feature Licenses (opens in a new tab) (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): Service Cloud User, Salesforce Console for Service तक पहुँच (“Access the Salesforce Console for Service”); campaigns बनाने और मैनेज करने के लिए Marketing User।