फ़ील्ड भी आर्किटेक्चर हैं

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: Salesforce को डेटा के हर टुकड़े को भौतिक रूप से कैसे दर्शाना चाहिए?

फ़ील्ड बनाने में लगभग एक मिनट लगता है। New Field, एक टाइप चुनें, नाम दें, Next, Next, Save। ठीक इसीलिए फ़ील्ड को आर्किटेक्चर नहीं माना जाता।

किसी ऐसे org में जाइए जो दस साल से चल रहा है और Account खोलिए। पाँच सौ फ़ील्ड। Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c। तीन अलग-अलग ग्राहक नंबर। एक checkbox जिसे कोई डिलीट नहीं करेगा, क्योंकि किसी को नहीं पता कि कौन-सा इंटीग्रेशन अब भी उसे इस्तेमाल करता है। फ़ील्ड बनाने में एक मिनट लगा। उसके साथ जीने में साल लगते हैं। तो इस मॉड्यूल का विचार सीधा है: फ़ील्ड एक आर्किटेक्चरल निर्णय है। हमेशा बड़ा नहीं, लेकिन हर फ़ील्ड डेटा के अर्थ, व्यवहार, पहचान या गुणवत्ता के बारे में कुछ दर्ज करता है, और ऑब्जेक्ट की तरह, फ़ील्ड जोड़ना आसान है और हटाना हैरानी की हद तक मुश्किल।

इस डेटा का असल में मतलब क्या है?

अध्याय 2 में हमने अपनी entities को एट्रिब्यूट दिए थे: एक डिलीवरी की एक तय समय-सीमा (scheduled window) होती है, एक ट्रक का VIN होता है। अब हम उन्हें लागू करते हैं, और यहीं लोग सीधे “text field” पर कूद जाते हैं। रुकिए। टाइप से पहले मैं जानना चाहता हूँ कि डेटा का मतलब क्या है। क्या यह एक संख्या है, या एक पहचानकर्ता (identifier) जिसमें संयोग से अंक हैं? एक तारीख, या समय का एक पल? खुला टेक्स्ट, या मंज़ूर मानों के सेट में से एक? किसी व्यक्ति ने डाला, या किसी दूसरे सिस्टम का है? क्या यह बदल सकता है? क्या इसे यूनिक होना चाहिए? क्या यह खाली रह सकता है? क्या इसे स्टोर करना भी चाहिए, या कैलकुलेट करना चाहिए? ये Setup के सवाल नहीं हैं। ये डेटा आर्किटेक्चर के सवाल हैं, और फ़ील्ड टाइप इनका जवाब देने के बाद आता है।

संख्या हमेशा संख्या नहीं होती

Steve Trucking हर ट्रक को एक fleet नंबर देती है, मान लीजिए 001247। Number फ़ील्ड? शायद नहीं। क्या हम fleet नंबर जोड़ते हैं? क्या ट्रक 1247 में से ट्रक 1246 घटाने पर एक ट्रक बचता है? यह एक पहचानकर्ता है जिसमें संयोग से अंक हैं, और Number फ़ील्ड तो शुरू के शून्य भी हटा देगा। यही बात पिन कोड, प्रोडक्ट कोड, अकाउंट नंबर और ट्रैकिंग नंबर पर लागू होती है। मान कैसा दिखता है, इससे पता नहीं चलता कि उसका मतलब क्या है। टाइप उस व्यवहार के लिए चुनें जिसकी आपको ज़रूरत है, इसके लिए नहीं कि सैंपल डेटा कैसा दिखता है।

क्या किसी इंसान को इसे पहचानना है?

हर कस्टम ऑब्जेक्ट को एक Name फ़ील्ड मिलता है, और पहला निर्णय है text या auto number। मैं पूछता हूँ: क्या किसी इंसान को इस चीज़ को पहचानना है? लोग रिटेल पार्टनर को नाम से जानते हैं और ट्रक को उसके fleet नंबर से। लेकिन वह मैनिफ़ेस्ट जो सिस्टम हर रात बनाता है? किसी को “Manifest 10-02 Number 3” सिर्फ़ इसलिए टाइप नहीं करना चाहिए कि Salesforce को एक Name चाहिए था। उसे auto number दें। बस उस बने हुए Name को रिकॉर्ड के ID से न मिलाएँ: auto number यूज़र की मदद करता है, Salesforce ID रिकॉर्ड को पहचानता है, और रिटेल पार्टनर का अपना मैनिफ़ेस्ट reference उसी चीज़ को सभी सिस्टम में पहचान सकता है। तीन अलग-अलग काम।

Details स्क्रीन

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

New Custom Field, चरण 2: ब्योरा (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में

दो बॉक्स एक जैसे दिखते हैं और अलग-अलग काम करते हैं। Description उन लोगों के लिए है जो org का रखरखाव करते हैं, और अब उन AI टूल के लिए भी जो इसे पढ़ते हैं: फ़ील्ड का मतलब क्या है, उसका मालिक कौन है, वह कहाँ से आता है। Help Text स्क्रीन पर बैठे यूज़र के लिए है: यहाँ क्या टाइप करना है। दोनों भरें। फिर आते हैं Required, Unique और External ID, और इनमें से हर एक अपने सेक्शन का हकदार है। उनके नीचे, Default Value एक formula हो सकता है, ताकि नया रिकॉर्ड खाली मान के बजाय एक समझदारी भरे मान से शुरू हो।

Required दिखने से बड़ा निर्णय है

फ़ील्ड विज़ार्ड में Required नाम का एक छोटा-सा checkbox है, और जैसा हमने अध्याय 1 में देखा, यह एक टाइम बम हो सकता है। आपके पास पाँच साल से एक ऑब्जेक्ट है और दो मिलियन रिकॉर्ड, और अब कोई तय करता है कि एक नए फ़ील्ड में हमेशा मान होना चाहिए। उन दो मिलियन रिकॉर्ड का क्या जो उससे पहले के हैं? उन इंटीग्रेशन का क्या जो इसे भेजते ही नहीं? उस ऑटोमेशन का क्या जो मान पता चलने से पहले ही रिकॉर्ड बना देता है? उस प्रोसेस का क्या जहाँ मान तीन कदम बाद ही सामने आता है?

“Required” डेटा-गुणवत्ता का निर्णय लगता है, और कभी-कभी होता भी है। लेकिन कोई मान कब पता चलता है, यह बिज़नेस प्रोसेस का हिस्सा है। इसलिए Required पर सिर्फ़ इसलिए टिक न करें कि कोई कहता है “हमें यह हमेशा चाहिए।” पूछें कि यह कब पता चलता है, कौन इसे देता है, और जब नहीं मिलता तब क्या होता है। मॉड्यूल 7 में हम इसे सुसंगतता की पूरी सीढ़ी पर रखेंगे।

Unique का भी एक मतलब है

अगर मैं किसी फ़ील्ड को unique मार्क करता हूँ, तो मैं बिज़नेस के बारे में एक बयान दे रहा हूँ: यह नहीं कि “यह आमतौर पर दोहराया नहीं जाता,” बल्कि “दो रिकॉर्ड में यह मान कभी नहीं हो सकता।” यह बड़ी बात है। और स्क्रीन आपसे एक और चीज़ तय करवाती है: क्या “ABC” और “abc” एक ही मान हैं या अलग? किसी व्यक्ति के टाइप किए किसी भी मान के लिए case-insensitive ज़्यादा सुरक्षित डिफ़ॉल्ट है। अध्याय 2 का की वाला नियम, यूनिक, न बदलने वाली, बिना अर्थ वाली, कभी PII नहीं, यहाँ लागू होता है। अगर कोई मुझसे कहता है कि कर्मचारी का ईमेल यूनिक है, तो मैं पूछना शुरू करता हूँ: क्या यह बदल सकता है, क्या कोई नौकरी छोड़कर वापस आ सकता है, क्या पते दोबारा इस्तेमाल हो सकते हैं, किसी अधिग्रहण के बाद क्या होता है? ईमेल उपयोगी हो सकता है, आज यूनिक भी। इससे वह एक अच्छी की नहीं बन जाता।

External ID: सीमा के पार रिकॉर्ड पहचानना

यहीं External ID अपनी कीमत वसूल करते हैं। स्क्रीन इसे अच्छी तरह बताती है: फ़ील्ड “किसी एक्सटर्नल सिस्टम का यूनिक रिकॉर्ड पहचानकर्ता” (“the unique record identifier from an external system”) बन जाता है। ERP के पास ग्राहक 873492 है; Salesforce के पास अपना रिकॉर्ड ID है। जब ERP कोई अपडेट भेजता है, तो हमें कैसे पता चले कि वह किस रिकॉर्ड का है? किसी फ़ील्ड को External ID मार्क करें और इंटीग्रेशन उस पर upsert कर सकता है: रिकॉर्ड न हो तो बना दे, हो तो अपडेट कर दे (Upsert a Record Using an External ID (opens in a new tab))। और जब आप child रिकॉर्ड लोड करते हैं, तो पहले Salesforce ID के लिए query करने के बजाय parent को उसके External ID से बता सकते हैं। मैं कहना पसंद करता हूँ कि आप lookup का काम Salesforce को करने देते हैं। बहुत ताकतवर।

ध्यान दें कि ERP का नंबर Salesforce रिकॉर्ड का ID नहीं बन जाता। यह एक एट्रिब्यूट है, और एक रिकॉर्ड में ऐसे कई हो सकते हैं: एक ERP ग्राहक ID, एक legacy ID, किसी पार्टनर का ID। यह ठीक है। एक बिज़नेस entity को कई सिस्टम अलग-अलग तरह से जान सकते हैं। आर्किटेक्चरल सवाल यह है कि हर पहचानकर्ता का मालिक कौन-सा सिस्टम है, और वह क्या वादा करता है: इसे unique तभी मार्क करें जब बिज़नेस सच में इसकी गारंटी देता हो।

एक-एक करके फ़ील्ड टाइप

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

Setup, New Custom Field, चरण 1: डेटा टाइप (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में

यह रही पूरी सूची एक नज़र में, हर एक के बारे में वह एक बात जो मैं चाहूँगा कि आप याद रखें।

समूह	टाइप	याद रखें
कैलकुलेट होने वाले	Auto Number	ज़्यादा से ज़्यादा 30 अक्षर, जिनमें से 20 prefix या suffix के; लोगों के लिए एक लेबल, रिकॉर्ड का ID नहीं
	Formula	पढ़े जाने पर कैलकुलेट होता है, स्टोर नहीं होता; 3,900 अक्षर
	Roll-Up Summary	details की गिनती, जोड़, न्यूनतम या अधिकतम; सिर्फ़ master-detail
संबंध	Lookup, Master-Detail, External Lookup	मॉड्यूल 7
डेटा	Checkbox	सही या गलत, आपके चुने डिफ़ॉल्ट के साथ; flows में null फिर भी आ सकता है
	Number, Percent, Currency	राउंडिंग के नियम; शुरू के शून्य हट जाते हैं; 15 दशमलव स्थान
	Date, Date/Time, Time	एक दिन, एक पल, या दिन का एक समय; पल UTC में स्टोर होते हैं
	Email, Phone, URL	सेव होने पर फ़ॉर्मेट और जाँच: 80, 40 और 255 अक्षर
	Geolocation, Address	कंपाउंड फ़ील्ड जो एक फ़ील्ड से ज़्यादा गिने जाते हैं: 3 और 9
	Picklist, Multi-Select	एक नियंत्रित शब्दावली, जिसका मालिक एक एडमिन है
	Text, Text Area, Long, Rich, Encrypted	255 तक रिकॉर्ड पर और इंडेक्स हो सकता है; उससे ऊपर, न इंडेक्स न फ़िल्टरिंग

वे फ़ील्ड जिन्हें Salesforce कैलकुलेट करता है

Auto Number हर नए रिकॉर्ड को एक क्रम में अगला नंबर देता है, आपके तय किए फ़ॉर्मेट में, जैसे T-{000000}। इसे तब इस्तेमाल करें जब किसी इंसान को एक आसान पहचान चाहिए और किसी को उसे गढ़ना न पड़े। पूरा मान ज़्यादा से ज़्यादा 30 अक्षर का होता है, और उनमें से 20 prefix या suffix के लिए आरक्षित हैं। बस अध्याय 2 की बात याद रखें: यह लोगों के लिए एक लेबल है, रिकॉर्ड का ID नहीं, और नंबर हमेशा सख्ती से क्रम में नहीं होते।

Formula फ़ील्ड दूसरे फ़ील्ड से एक मान कैलकुलेट करते हैं। ये ताकतवर हैं, और ये रिकॉर्ड के पढ़े जाने पर कैलकुलेट होते हैं, सेव होने पर नहीं, इसलिए कुछ भी स्टोर नहीं होता जो पुराना पड़ जाए। आप चुनते हैं कि formula क्या लौटाएगा: checkbox, currency, date, date/time, number, percent, text या time।

New Custom Field, formula: return type चुनना (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में

फिर आप खुद formula लिखते हैं, फ़ील्ड, operators और functions के साथ, और उसका syntax जाँचते हैं। Use Formula Assistant बटन पर ध्यान दें: अब Salesforce का AI formula लिखने में आपकी मदद करेगा। इसे इस्तेमाल करें, और फिर पढ़ें कि उसने क्या लिखा। formula के मालिक आप हैं, assistant नहीं।

Formula editor, Formula Assistant के साथ (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में एक formula ज़्यादा से ज़्यादा 3,900 अक्षर का हो सकता है, और सेव या compile होने पर 15,000 bytes से ज़्यादा नहीं हो सकता; एक लंबे formula को कई formula फ़ील्ड में बाँटा जा सकता है जो एक-दूसरे का हवाला देते हैं। Long text areas, encrypted फ़ील्ड और Description फ़ील्ड इनमें इस्तेमाल नहीं किए जा सकते।

Roll-Up Summary फ़ील्ड master पर रहते हैं और उसके detail रिकॉर्ड की गिनती, जोड़, या न्यूनतम या अधिकतम निकालते हैं। ये सिर्फ़ master-detail संबंध पर काम करते हैं, जो master-detail चुनने की सबसे बड़ी वजहों में से एक है। हम इन पर, और इनकी सीमाओं पर, मॉड्यूल 7 में लौटेंगे।

स्टोर करें या निकालें?

क्या हमें यह मान स्टोर करना भी है? अगर मेरे पास मात्रा और प्रति इकाई कीमत है, तो क्या किसी व्यक्ति को, या किसी ऑटोमेशन को, कुल रकम संभालनी चाहिए? शायद एक formula को इसे निकालना चाहिए: कैलकुलेशन का एक स्रोत, पढ़े जाने पर दोबारा कैलकुलेट, तो मात्रा बदलें और जवाब साथ चलता है। formulas की अपनी सीमाएँ हैं (सेव का आकार और दिखाई जाने वाली लंबाई; Formula Field Limits and Restrictions (opens in a new tab)), और पेचीदा formulas को संभालना मुश्किल हो जाता है।

लेकिन कभी-कभी बिज़नेस को आज का जवाब नहीं चाहिए। उसे वह जवाब चाहिए जैसा वह था। अगर अगले साल छूट का नियम बदल जाए, तो क्या पिछले साल का इनवॉइस अचानक अलग रकम दिखाने लगे? बिल्कुल नहीं। इसलिए सवाल यह नहीं है कि “क्या Salesforce इसे कैलकुलेट कर सकता है?” सवाल है “यह मौजूदा कैलकुलेशन है या ऐतिहासिक तथ्य?” ऐतिहासिक तथ्य स्टोर किए जाते हैं।

संबंध वाले फ़ील्ड

Lookup, Master-Detail और External Lookup संबंध भी फ़ील्ड हैं, और यहीं आपके मॉडल की लकीरें असली बनती हैं। lookup ढीली कड़ी है; master-detail child के जीवन, स्वामित्व और सिक्योरिटी को parent से बाँध देता है; external lookup मॉड्यूल 4 के किसी एक्सटर्नल ऑब्जेक्ट तक पहुँचता है, उसके External ID पर मिलान करके। इनमें से चुनना इतना बड़ा निर्णय है कि उसे अपना एक मॉड्यूल मिला है।

Checkbox

Checkbox सबसे सीधा फ़ील्ड है: सही या गलत, टिक या बिना टिक। रिकॉर्ड के बारे में हाँ/ना वाले तथ्य के लिए यह एकदम सही है: Is Active, Install Required, Signed For। जब आप इसे बनाते हैं, Salesforce आपसे इसका डिफ़ॉल्ट मान चुनवाता है, टिक या बिना टिक, और यह एक असली निर्णय है: हर नया रिकॉर्ड इसी से शुरू होता है, उन रिकॉर्ड समेत जिन्हें कोई इंटीग्रेशन यह फ़ील्ड भेजे बिना बनाता है। रिपोर्ट और list views इसे True और False के रूप में फ़िल्टर करते हैं; import टूल और साप्ताहिक export इसे 1 और 0 के रूप में दिखाते हैं।

एक जाल जो जानना चाहिए। रिकॉर्ड पर फ़ील्ड के दो मान होते हैं, लेकिन उसके आसपास के ऑटोमेशन में तीसरा भी हो सकता है। एक flow में, checkbox का ऐसा variable जो कभी सेट ही नहीं हुआ, null होता है, false नहीं, और उसे रिकॉर्ड में सेव करना फ़ेल हो जाता है (Trailblazer Community (opens in a new tab); Salesforce known issue W-11208535 (opens in a new tab) भी देखें)। एक समझदारी भरा डिफ़ॉल्ट चुनें, और अपने flows और कोड से null को सोच-समझकर संभलवाएँ।

Number, Percent और Currency

Number एक वास्तविक संख्या स्टोर करता है, और शुरू के शून्य हटा देता है, ठीक इसीलिए 001247 जैसा fleet नंबर Number नहीं है। Salesforce number फ़ील्ड को आधे को शून्य से दूर राउंड करता है: 12.345 बनता है 12.35, और −12.345 बनता है −12.35। और merge fields में, यह यूज़र के locale के हिसाब से राउंड करता है, फ़ील्ड पर आपके तय किए दशमलव स्थानों के हिसाब से नहीं।

Percent एक दशमलव स्टोर करता है और प्रतिशत दिखाता है: 0.10 डालें और आपको 10% दिखेगा। 15 दशमलव स्थानों के बाद मान अपनी सटीकता खो देते हैं।

Currency पैसे के लिए फ़ॉर्मेट होता है, और कई करेंसी वाले org में यह अपना करेंसी कोड साथ रखता है और विनिमय दरें (exchange rates) इस्तेमाल कर सकता है; advanced currency management (opens in a new tab) के साथ, opportunities तारीख वाली (dated) विनिमय दरें इस्तेमाल कर सकती हैं, यानी उस अवधि की दर जिसमें सौदा बंद हुआ। सिर्फ़ opportunities और उनके आसपास की चीज़ें (products, schedules, splits और उनकी रिपोर्ट) dated दरें इस्तेमाल करती हैं; दूसरे ऑब्जेक्ट के currency फ़ील्ड एक ही स्थिर दर रखते हैं। राउंडिंग पर नज़र रखें: बिना दशमलव स्थानों के, Salesforce बस काट देता है (23.5 बनता है 23); एक या ज़्यादा के साथ, यह आधे को शून्य से दूर राउंड करता है।

Date, Date/Time और Time

तीन टाइप, तीन अलग मतलब। Date एक दिन है: एक कॉन्ट्रैक्ट किसी तारीख को खत्म होता है। Date/Time एक पल है: डिलीवरी उस सुबह 9:42 पर पहुँची। Time दिन का एक समय है, बिना किसी तारीख के: स्टोर हर दिन 7:00 बजे खुलता है।

जाल पल में है। Salesforce date/time मानों को GMT (UTC) में स्टोर करता है। यूज़र जो समय टाइप करता है, वह उसके time zone में पढ़ा जाता है, बदला जाता है, और स्टोर होता है; जब कोई उसे पढ़ता है, तो वह फिर से पढ़ने वाले के time zone में बदला जाता है। ज़्यादातर समय यही आप चाहते हैं। लेकिन यह रहा वह उदाहरण जो मैं क्लास में देता हूँ: Los Angeles में एक कोऑर्डिनेटर रविवार देर रात, Pacific समय के हिसाब से रात 10 बजे, एक डिलीवरी दर्ज करता है। अंदर Salesforce ने सोमवार सुबह, GMT के हिसाब से सुबह 5 बजे, स्टोर किया। किसी दूसरे time zone में दिन के हिसाब से समूह बनाने वाली रिपोर्ट, या कच्चा मान पढ़ने वाला कोई इंटीग्रेशन, उस रविवार की डिलीवरी को सोमवार पर रख सकता है। “जिस दिन यह हुआ” इस पर निर्भर करता है कि आप किसकी घड़ी से पूछते हैं। यूज़र के time zone पर नज़र रखें, और तय करें कि बिज़नेस का मतलब किससे है।

और इनकी तुलना करते समय सावधान रहें। अंदर से, एक date/time एक बड़ी संख्या है: Apex इसे 1 जनवरी 1970, 00:00:00 GMT से अब तक के मिलीसेकंड की संख्या के रूप में पढ़ता है (Datetime Class (opens in a new tab))। यह एक सटीक पल है, दिन नहीं। इसलिए यह पूछना कि दो date/time बराबर (==) हैं या नहीं, लगभग कभी वह नहीं करता जो आप चाहते हैं: 9:42:00 और 9:42:01 बराबर नहीं हैं, और न ही “सोमवार” और सोमवार का कोई भी पल। इसके बजाय, एक रेंज माँगें: शुरुआत के बराबर या उसके बाद (>=) और अंत के बराबर या उससे पहले (<=)। “सोमवार की हर डिलीवरी” मतलब हर वह डिलीवरी जो सोमवार 00:00 के >= और सोमवार 23:59:59 के <= हो, उस time zone में जो आपने तय किया कि बिज़नेस का मतलब है।

और एक मज़ेदार बात: Salesforce कोई भी तारीख स्टोर नहीं कर सकता। मान्य तारीखें 1 जनवरी 1700 से 31 दिसंबर 4000 तक हैं, और Salesforce dates और date/times के लिए यही रेंज देता है (Data Import Dates (opens in a new tab))। किनारे भी GMT के पल हैं, इसलिए Pacific समय वाले यूज़र के लिए सबसे पहला मान्य मान 31 दिसंबर 1699 को शाम 4 बजे है। हो सकता है आपकी historical society की स्थापना की तारीख अंदर न आ पाए। और पुरानी “कोई अंतिम तारीख नहीं” वाली चाल, 31 दिसंबर 9999, अस्वीकार हो जाती है; अगर आपको दूर भविष्य का कोई placeholder चाहिए, तो वह साल 4000 या उससे पहले का होना चाहिए।

Email, Phone और URL

ये फ़ॉर्मेट वाले फ़ील्ड हैं, और ये सिर्फ़ अक्षर स्टोर करने से ज़्यादा करते हैं। Email में ज़्यादा से ज़्यादा 80 अक्षर होते हैं और सही फ़ॉर्मेट के लिए इसकी जाँच होती है; contacts और leads पर, इस पर क्लिक करने से उस पते पर ईमेल लिखना शुरू हो जाता है। Phone में ज़्यादा से ज़्यादा 40 अक्षर होते हैं, यह फ़ोन नंबर की तरह फ़ॉर्मेट होता है, और org से फ़ोन सिस्टम जुड़ा हो तो click-to-dial बन जाता है। URL में ज़्यादा से ज़्यादा 255 अक्षर होते हैं और यह एक लिंक की तरह खुलता है। यह प्लेटफ़ॉर्म आपको मुफ़्त में व्यवहार दे रहा है, इसीलिए मैं फ़ोन नंबर कभी सादे text फ़ील्ड में स्टोर नहीं करूँगा।

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

Geolocation और Address

Geolocation में एक अक्षांश (latitude) और एक देशांतर (longitude) होता है। अंदर, Location__c नाम का फ़ील्ड असल में दो मान है जिन्हें आप अलग-अलग पढ़ और सेट कर सकते हैं, Location__Latitude__s और Location__Longitude__s। और आप इस पर query कर सकते हैं: SOQL के DISTANCE और GEOLOCATION functions किसी दायरे के अंदर के रिकॉर्ड ढूँढते हैं, या उन्हें दूरी के हिसाब से क्रम में लगाते हैं। “इस ट्रक से 25 मील के अंदर की हर खुली डिलीवरी” एक query है: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab))। Address में पूरा पता होता है, सड़क, शहर, राज्य या प्रांत, पिन कोड और देश, और यूज़र किसी पते को सर्च करके उसके हिस्से अपने-आप भरवा सकते हैं।

दोनों कंपाउंड फ़ील्ड हैं: स्क्रीन पर एक फ़ील्ड, अंदर कई। और ये आपके ऑब्जेक्ट की सीमा में एक फ़ील्ड से ज़्यादा गिने जाते हैं: एक Geolocation तीन कस्टम फ़ील्ड के बराबर गिना जाता है, और एक Address नौ के बराबर। जो ऑब्जेक्ट पहले से भरा हुआ है, उस पर यह मायने रखता है।

Picklist और Multi-Select

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

मान कहाँ रहते हैं, यह भी एक निर्णय है। जब कोई सूची एक बार, एक फ़ील्ड पर इस्तेमाल होती है, तो मानों को फ़ील्ड पर ही रखें, ऑब्जेक्ट पर; Salesforce डिफ़ॉल्ट रूप से यही करता है। लेकिन जब मानों का वही सेट कई जगह दिखने लगे, account पर, डिलीवरी पर और वेयरहाउस पर एक Region, तो कॉपियों के अलग-अलग भटकने से पहले उसे ग्लोबल वैल्यू सेट में बदल दें। एक ग्लोबल वैल्यू सेट उन सबके लिए एक सूची रखता है, ज़्यादा से ज़्यादा 1,000 मान, सक्रिय और निष्क्रिय मिलाकर (Picklist Limitations (opens in a new tab))। Setup का अपना विवरण बताता है कि यह क्यों मायने रखता है: value set इस तरह प्रतिबंधित है कि यूज़र API के ज़रिए बिना मंज़ूरी वाले मान नहीं जोड़ सकते (“is restricted so users can’t add unapproved values through the API”)। एक सूची, एक मालिक, और कोई इंटीग्रेशन चुपके से नई वर्तनी नहीं घुसा सकता।

यही आखिरी बात प्रतिबंधित (restricted) और अप्रतिबंधित (unrestricted) का फ़र्क है। प्रतिबंधित पिकलिस्ट पर, सिर्फ़ वे मान चलते हैं जो एडमिन ने तय किए, कहीं से भी: कोई यूज़र, import या इंटीग्रेशन जो कुछ और भेजे, उसे एक error मिलती है, “bad value for restricted picklist field”, और रिकॉर्ड सेव नहीं होता। अप्रतिबंधित पिकलिस्ट पर, यूज़र अब भी स्क्रीन पर सूची से ही चुनते हैं, लेकिन API, imports और ऑटोमेशन कोई भी मान भेज सकते हैं, और Salesforce उसे सेव कर लेता है और एक निष्क्रिय मान के रूप में जोड़ देता है (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab))। इसी तरह किसी org में “Delivered”, “delivered” और “Dlvrd” आ जाते हैं। ग्लोबल वैल्यू सेट हमेशा प्रतिबंधित होते हैं। मेरा डिफ़ॉल्ट प्रतिबंधित है; अप्रतिबंधित एक सोचा-समझा चुनाव है, उस स्थिति के लिए जब मानों का असली मालिक कोई दूसरा सिस्टम हो, और तब किसी को निष्क्रिय मानों की सफ़ाई की ज़िम्मेदारी लेनी होती है।

Setup, Picklist Value Sets: एक नया ग्लोबल वैल्यू सेट (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में

Multi-select पिकलिस्ट यूज़र को कई मान चुनने देती है, जो अर्धविराम (semicolon) से अलग करके एक साथ स्टोर होते हैं। स्क्रीन पर सुविधाजनक, बाकी हर जगह असुविधाजनक: इस पर फ़िल्टर, रिपोर्ट और इंटीग्रेशन करना मुश्किल है, और इसे roll-up summary के फ़िल्टर में इस्तेमाल नहीं किया जा सकता। एक रिकॉर्ड के कई मान का आमतौर पर मतलब होता है अध्याय 2 का सबक: कोई child ऑब्जेक्ट बाहर निकलने की कोशिश कर रहा है।

एक पिकलिस्ट में आपके तय किए मानों से एक मान ज़्यादा भी होता है: खाली। कोई रिकॉर्ड बिना कुछ चुने पड़ा रह सकता है, और यह लोगों को पकड़ लेता है। किसी formula या वैलिडेशन रूल में आप पिकलिस्ट को सिर्फ़ ISBLANK से नहीं जाँच सकते; आप ISBLANK(TEXT(Field__c)) लिखते हैं, या ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab))। इसलिए हर पिकलिस्ट के लिए तय करें कि “कोई मान नहीं” का मतलब क्या है: क्या इसकी इजाज़त है, और ऐसा होने पर इसका मतलब क्या है? फिर अपने formulas, वैलिडेशन रूल और फ़िल्टर से इसे संभलवाएँ।

और कभी-कभी कोई एट्रिब्यूट असल में एक entity होता है। कोई डिस्ट्रिब्यूशन सेंटर की पिकलिस्ट माँगता है। नौ हैं। आसान। फिर हमें पता चलता है कि हर एक का एक पता, एक मैनेजर, खुलने का समय, क्षमता, एक region और ट्रक हैं। यह पिकलिस्ट नहीं है; यह एक चीज़ है। किसी entity को सिर्फ़ इसलिए पिकलिस्ट न बनाएँ कि अभी वे ज़्यादा नहीं हैं। पहले साल में यह बढ़िया लगता है और पाँचवें साल में भयानक। (अध्याय 2 के मॉड्यूल 5 में मेरे अनुभव के नियम हैं कि कोई सूची कब अपना ऑब्जेक्ट पाने की हकदार होती है।)

Text परिवार

मैं text को दो तरह का पढ़ाता हूँ, और दोनों के बीच की रेखा 255 अक्षर है।

255 तक: रिकॉर्ड के साथ स्टोर। Text में ज़्यादा से ज़्यादा 255 अक्षर होते हैं, और आप इसे लगभग हर जगह इस्तेमाल कर सकते हैं: formulas, फ़िल्टर, रिपोर्ट, list views में, unique फ़ील्ड या External ID के रूप में, और यह इंडेक्स हो सकता है। Text Area में भी 255 होते हैं, अलग-अलग लाइनों में, जैसे एक छोटा नोट।

255 से ऊपर: reference से स्टोर। Text Area (Long) में ज़्यादा से ज़्यादा 131,072 अक्षर होते हैं, और Text Area (Rich) में उतने ही, फ़ॉर्मेटिंग, लिंक और इमेज के साथ। मैं इन्हें एक तरफ़ अलग स्टोर हुआ मानता हूँ, जिसमें रिकॉर्ड एक pointer रखता है, और ये वैसा ही व्यवहार करते हैं: कोई इंडेक्स नहीं, इसलिए आप इन्हें unique या External ID नहीं बना सकते; आप SOQL WHERE clause में इन पर फ़िल्टर नहीं कर सकते (SOQL WHERE (opens in a new tab)); formulas इन्हें इस्तेमाल नहीं कर सकते (Formula Field Limits and Restrictions (opens in a new tab)); और रिपोर्ट कस्टम वाले के सिर्फ़ पहले 254 अक्षर दिखाती हैं, और रिपोर्ट फ़िल्टर सिर्फ़ लगभग पहले 255 में खोजते हैं (Filter Restrictions for Text Area (Long) Fields (opens in a new tab))। rich text फ़ील्ड में अपलोड की गई हर इमेज ज़्यादा से ज़्यादा 1 MB की हो सकती है, और वे file storage में गिनी जाती हैं, जबकि टेक्स्ट data storage में (Rich Text Area Field Considerations (opens in a new tab))। इसलिए अगर किसी को भी इस मान पर सर्च, sort, मिलान या रिपोर्ट करनी है, तो इसे 255 से नीचे रखें और Text फ़ील्ड ही रखें।

Text (Encrypted) ज़्यादा से ज़्यादा 175 अक्षर एन्क्रिप्टेड रूप में स्टोर करता है, Classic Encryption के ज़रिए। अगर आपका org Shield Platform Encryption इस्तेमाल करता है, तो आप इसके बजाय एक सामान्य Text फ़ील्ड को एन्क्रिप्ट करते हैं, और बहुत-से दूसरे टाइप भी इसी तरह एन्क्रिप्ट हो सकते हैं।

हर फ़ील्ड को एक description दें

मेरा मानक: हर फ़ील्ड को एक description मिलता है। मैं यह लंबे समय से मानता आया हूँ, और AI के इस दौर में यह पहले से कहीं ज़्यादा मायने रखता है: आपके org को पढ़ने वाला हर AI टूल और एजेंट किसी फ़ील्ड का मतलब समझने के लिए descriptions पढ़ता है। खाली description एक अंदाज़ा है जो लगने ही वाला है। Customer_Status__c का मतलब क्या है? इसका मालिक कौन है? यह कहाँ से आता है? क्या यूज़र इसे बदल सकते हैं, या आज रात ERP इसे overwrite कर देगा? छह महीने में मुझे याद नहीं रहेगा, और तीन साल में org संभालने वाले एडमिन को तब तक पता नहीं होगा जब तक हमने उसे बताया न हो। लेबल दस्तावेज़ नहीं है, और API नाम भी नहीं।

भारी रूप से साझा ऑब्जेक्ट (Account, Contact, Opportunity) पर मैं खास फ़ील्ड के लिए नामकरण के prefix भी इस्तेमाल करता हूँ, ताकि उनका स्रोत और उद्देश्य नाम में ही दिखे: उदाहरण के लिए, ERP के स्वामित्व वाली हर चीज़ एक ही prefix से शुरू होती है। मैं बारह शब्दों वाले API नाम नहीं चाहता। मैं चाहता हूँ कि मॉडल खुद को समझाए।

जो मायने रखता है, उसे वर्गीकृत करें: टैक्सोनॉमी फ़ील्ड

Salesforce हर फ़ील्ड को वर्गीकरण के मेटाडेटा का एक सेट देता है। मैं इन्हें टैक्सोनॉमी फ़ील्ड कहता हूँ। आप डेटा का मालिक दर्ज कर सकते हैं; field usage (Active, DeprecateCandidate, Hidden); data sensitivity level (Public, Internal, Confidential, Restricted, MissionCritical); और compliance categorization: PII, HIPAA, GDPR, PCI, CCPA और दूसरे। ये स्टैंडर्ड फ़ील्ड पर भी उतना ही काम करते हैं जितना कस्टम पर (Data Classification Metadata Fields (opens in a new tab))।

झंझट क्यों? क्योंकि प्रोसेस इन्हें पढ़ सकते हैं। किसी फ़ील्ड को GDPR फ़्लैग करें और एक प्रोसेस किसी रिकॉर्ड के हर GDPR फ़ील्ड को ढूँढकर उसे मास्क कर सकता है या हटा सकता है। और जब Salesforce की trust layer किसी large language model को prompt भेजती है, तो वह संवेदनशील फ़ील्ड को मास्क करने के लिए ठीक यही वर्गीकरण इस्तेमाल कर सकती है: वह बाहर जाते समय किसी ग्राहक का नाम, मान लीजिए “Maria Lopez”, एक placeholder से बदल देती है, मॉडल कभी नाम नहीं देखता, और अंदर आते समय जवाब में नाम वापस रख दिया जाता है (Einstein Trust Layer (opens in a new tab))।

एक अपडेट। Salesforce अब बताता है कि LLMs के लिए pattern-based और field-based masking एजेंट के लिए बंद है: masking वह संदर्भ छीन सकती है जिसकी एजेंट को जवाब देने के लिए ज़रूरत है (Data Masking Limitations in Agentforce (opens in a new tab))। दूसरे generative AI फ़ीचर के लिए वर्गीकरण अब भी masking चलाता है, लेकिन निजी डेटा को एजेंट से दूर रखने के लिए इस पर भरोसा न करें; यह access और डिज़ाइन का निर्णय है (अध्याय 12)।

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

परीक्षा से आगे: AI क्या बदलता है। फ़ील्ड का खराब दस्तावेज़ीकरण पहले अगले एडमिन को सज़ा देता था। अब यह schema पढ़ने वाले हर AI टूल और एजेंट को गुमराह करता है: क्या Flag2__c संवेदनशील है, आधिकारिक है, अब भी इस्तेमाल होता है? AI किसी भी टीम से तेज़ी से फ़ील्ड बनाता भी है, इसलिए नाम, descriptions और वर्गीकरण आर्किटेक्चर का हिस्सा हैं, घर की साफ़-सफ़ाई नहीं।

हर फ़ील्ड एक प्रतिबद्धता है

एक बार कोई फ़ील्ड बाहर आकर डेटा इकट्ठा करने लगे, तो हर चीज़ उस पर टिकने लगती है। स्क्रीन उसे दिखाती हैं, flows उसके आधार पर रास्ता बदलते हैं, वैलिडेशन रूल उसे जाँचते हैं, रिपोर्ट उसके हिसाब से समूह बनाती हैं, इंटीग्रेशन उसे भेजते और पढ़ते हैं, और अब AI टूल उस पर तर्क करते हैं। इनमें से हर एक फ़ील्ड के बारे में धारणाएँ बनाता है: उसका टाइप, उसकी लंबाई, क्या वह कभी खाली होता है, और उसके मानों का मतलब क्या है। बाद में फ़ील्ड बदलें, तो आपको पहले उन सभी धारणाओं को ढूँढना होगा। किसी पिकलिस्ट मान का नाम बदलना, text फ़ील्ड को छोटा करना, या Text फ़ील्ड को पिकलिस्ट में बदलना छोटा बदलाव लगता है, और यह किसी दूसरी कंपनी के सिस्टम में एक इंटीग्रेशन तोड़ सकता है। इसीलिए फ़ील्ड एक प्रतिबद्धता है।

Click to enlarge

मैं नहीं चाहता कि आप इस मॉड्यूल से फ़ील्ड बनाने से डरकर निकलें। Salesforce को आगे बढ़ाए जाने के लिए ही बनाया गया है; इसका इस्तेमाल करें। मैं चाहता हूँ कि सवाल “मुझे कौन-सा फ़ील्ड टाइप चुनना चाहिए?” से बदलकर “इस डेटा का मतलब क्या है, और हम किस व्यवहार के लिए प्रतिबद्ध हो रहे हैं?” बन जाए। टाइप, required, unique, External ID, पिकलिस्ट, formula, description, वर्गीकरण: ये सब मिलकर अध्याय 2 के लॉजिकल मॉडल की भौतिक अभिव्यक्ति हैं।

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

• फ़ील्ड टाइप चुनने से पहले मान का मतलब क्या है, और क्या यह एक एट्रिब्यूट है, एक पहचानकर्ता, एक नियंत्रित शब्दावली या असल में एक और entity।
• कोई मान एक मौजूदा कैलकुलेशन है जिसे निकाला जा सकता है, या एक ऐतिहासिक तथ्य जिसे स्टोर करना ज़रूरी है।
• हर पहचानकर्ता का मालिक कौन-सा सिस्टम है, और क्या उसकी यूनिकनेस बिज़नेस का एक असली वादा है।
• कोई required मान असल में कब पता चलता है, और उन रिकॉर्ड और इंटीग्रेशन का क्या होता है जिनके पास वह नहीं है।
• फ़ील्ड को कौन-सा description, नामकरण और वर्गीकरण चाहिए, ताकि लोग, प्रोसेस और AI उसे सुरक्षित रूप से इस्तेमाल कर सकें।

और जानें

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) और Data Masking Limitations in Agentforce (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Help, Picklist Limitations (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया)।