कस्टम ऑब्जेक्ट

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

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

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

पिछले मॉड्यूल में हमने देखा कि Salesforce ने पहले से क्या बना रखा है। कभी-कभी उसके पास वह नहीं होता जो आपको चाहिए। Steve Trucking ट्रक चलाती है, और कोई स्टैंडर्ड Truck ऑब्जेक्ट नहीं है। तो आप एक बनाते हैं: एक कस्टम ऑब्जेक्ट।

इस मॉड्यूल में मैं चाहता हूँ कि आप यह देखें। कस्टम ऑब्जेक्ट, मॉड्यूल 1 की बाकी हर चीज़ की तरह, मेटाडेटा में बनता है, और जिस पल वह मौजूद होता है, उसके साथ स्टैंडर्ड क्षमताओं का एक सेट आ जाता है। यह कोई खाली टेबल नहीं है। और उसे बनाने के लिए आप जो स्क्रीन भरते हैं, वह आपसे आर्किटेक्चर के सवाल पूछ रही होती है, चाहे आप ध्यान दें या न दें।

New Custom Object स्क्रीन

Setup → Object Manager → Create → Custom Object पर जाएँ, और आपको एक लंबा फ़ॉर्म मिलता है। ज़्यादातर लोग पहले दो बॉक्स भरते हैं और Save पर क्लिक कर देते हैं। चलिए धीरे चलें और इसे पढ़ें।

Label और Plural Label। “Truck” और “Trucks”। यूज़र यही देखते हैं, टैब, पेज लेआउट और रिपोर्ट में। इन्हें आप बाद में बिना ज़्यादा तकलीफ़ के बदल सकते हैं।

Object Name। यह अलग है: यह API नाम है, वह नाम जिसे कोड, इंटीग्रेशन, रिपोर्ट और अब एजेंट इस्तेमाल करते हैं। “Truck” टाइप करें और Salesforce इसे Truck__c बना देता है। इसे बाद में बदलने का मतलब है हर उस चीज़ को ढूँढना जो इसका हवाला देती है, यानी फिर से अध्याय 1 की पलटने की कसौटी (Reversibility Test)। इसे पहली बार में ही सही रखें।

Description। इसे भरें। हर बार। मॉड्यूल 1 में मैंने कहा था कि मेटाडेटा अब सजावट नहीं रहा: अगला एडमिन इसे पढ़ता है, और वह हर AI टूल भी जो आपके org को समझने की कोशिश करता है। खाली description वाला कस्टम ऑब्जेक्ट बिना लेबल का एक डिब्बा है।

Record Name। हर कस्टम ऑब्जेक्ट में एक Name फ़ील्ड होता है, और यहीं आप तय करते हैं कि वह क्या होगा। एक Text नाम, जैसे “Truck 117”, या एक Auto Number, जैसे T-000184, जिसे Salesforce आपके लिए भरता है। उस स्क्रीन की चेतावनी पढ़ें: अगर आप API के ज़रिए बड़ी संख्या में रिकॉर्ड डालने वाले हैं, तो Salesforce आपसे Text इस्तेमाल करने को कहता है। यह प्लेटफ़ॉर्म आपको एक भी रिकॉर्ड बनाने से पहले ही स्केल के बारे में कुछ बता रहा है।

Salesforce Setup, New Custom Object: Record Name सेक्शन, अपनी चेतावनी के साथ (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में

Optional Features। Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups। डिफ़ॉल्ट रूप से बंद। हर एक ऐसी क्षमता है जिसे आप इस ऑब्जेक्ट के लिए चालू कर रहे हैं; सोच-समझकर तय करें।

Object Classification। Allow Sharing, Allow Bulk API Access, Allow Streaming API Access, सब डिफ़ॉल्ट रूप से चालू। स्क्रीन साफ़-साफ़ कहती है: ये चालू हों तो ऑब्जेक्ट एक Enterprise Application ऑब्जेक्ट है; बंद हों तो एक Light Application ऑब्जेक्ट। ये नाम Salesforce के app-subscription लाइसेंस से मेल खाते हैं: एक Lightning Platform Light App में रिकॉर्ड-स्तर की शेयरिंग नहीं होती और वह Bulk API या Streaming API इस्तेमाल नहीं कर सकता, जबकि एक Enterprise App कर सकता है। मेरी सलाह: इन्हें चालू ही रहने दें, जब तक आपको ठीक-ठीक पता न हो कि क्यों नहीं। जिस ऑब्जेक्ट में आप बाद में बड़ी मात्रा में डेटा लोड करेंगे, उस पर Bulk API access बंद कर दीजिए, और आपको पता चल जाएगा कि यह क्यों मायने रखता था।

Deployment Status और Search। “In Development” बनाते समय ऑब्जेक्ट को यूज़र से छिपाए रखता है; “Deployed” उसे लाइव कर देता है। और Allow Search डिफ़ॉल्ट रूप से बंद होता है, इसलिए जब तक आप इसे चालू नहीं करते, यूज़र ये रिकॉर्ड global search में नहीं पाएँगे। यह बात हर बार लोगों को पकड़ लेती है।

डिफ़ॉल्ट सेटिंग: तीनों API सेटिंग चालू, Deployed, और Allow Search बंद (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में

Save पर क्लिक करें, और Object Manager आपको ऑब्जेक्ट दिखाता है: API नाम Truck__c, Custom पर टिक, लेबल, deployment status। लेकिन बाईं ओर नीचे देखें: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access। वह सूची मॉड्यूल 1 को आँखों के सामने ले आती है। ऑब्जेक्ट सिर्फ़ स्टोरेज नहीं है; यह वह जगह है जिससे यह सारा व्यवहार जुड़ा होता है।

Object Manager, Truck: API नाम Truck__c, Custom, और वह सब कुछ जो एक ऑब्जेक्ट से जुड़ा होता है (स्क्रीनशॉट, 2026-10-12)। पूरे आकार में

वे फ़ील्ड जो आपने नहीं बनाए

किसी बिल्कुल नए कस्टम ऑब्जेक्ट पर Fields & Relationships खोलें, और उसमें पहले से फ़ील्ड होते हैं। हर कस्टम ऑब्जेक्ट को एक स्टैंडर्ड सेट मिलता है:

• Name, वह रिकॉर्ड नाम जो आपने अभी चुना, जो पेज लेआउट, related lists, lookups और सर्च नतीजों में इस्तेमाल होता है।
• Owner, वह यूज़र या queue जिसका रिकॉर्ड पर स्वामित्व है।
• Created By और Last Modified By, वे यूज़र जिन्होंने रिकॉर्ड बनाया और आखिरी बार बदला।
• Currency, अगर multi-currency चालू है, और Division, अगर आपका org divisions इस्तेमाल करता है।

और अंदर, मॉड्यूल 1 वाला रिकॉर्ड ID, और बनने और बदलने की तारीखें। Data Loader से कुछ रिकॉर्ड export करें और आपको ये सब दिख जाएँगे।

इनमें से एक गायब हो सकता है। अपने कस्टम ऑब्जेक्ट को किसी master-detail संबंध का detail हिस्सा बनाइए, और Owner फ़ील्ड चला जाता है: स्वामित्व इसके बजाय master रिकॉर्ड से आता है। यह जितना सुनाई देता है, उससे बड़ी बात है, और हम मॉड्यूल 7 और 8 में इस पर लौटेंगे।

Prefix और suffix: आप क्या देख रहे हैं

पिछले मॉड्यूल में मैंने कहा था कि स्टैंडर्ड ऑब्जेक्ट का न कोई prefix होता है, न कोई suffix। बाकी सबका होता है, और जब आप इन्हें पढ़ना सीख जाते हैं, तो फ़ील्ड की सूची आपको ठीक-ठीक बता देती है कि आप क्या देख रहे हैं।

यह कैसा दिखता है	यह क्या है
Account, Case	एक स्टैंडर्ड ऑब्जेक्ट या फ़ील्ड: न prefix, न suffix
Truck__c	एक कस्टम ऑब्जेक्ट, या एक कस्टम फ़ील्ड, जैसे Unit_Number__c
abc__Inspection__c	किसी managed package का कस्टम ऑब्जेक्ट: abc वेंडर का namespace है
Delivery_History__b	एक big object (मॉड्यूल 4)
Shipment__x	एक एक्सटर्नल ऑब्जेक्ट: डेटा किसी दूसरे सिस्टम में रहता है (मॉड्यूल 4)
Allergies__pc	person account पर एक कस्टम Contact फ़ील्ड (मॉड्यूल 2)
Truck__r	किसी कस्टम lookup के पीछे का संबंध, जब आप query में उसका पीछा करते हैं

कुछ बातों पर ध्यान दें।

अब तक यह एक सूची है। मैं इसे ऐसे पढ़ाता हूँ: परतों के रूप में। ऑब्जेक्ट तीन तरह के होते हैं, स्टैंडर्ड, कस्टम और managed package, और हर एक पर एक जैसे तरह के फ़ील्ड हो सकते हैं: वे स्टैंडर्ड फ़ील्ड जिनके साथ वह आया, और वे कस्टम फ़ील्ड जो किसी ने जोड़े।

स्टैंडर्ड ऑब्जेक्ट। Account का न कोई prefix है, न suffix, और न ही उसके स्टैंडर्ड फ़ील्ड का: Name, Industry, OwnerId। आप ज़्यादातर स्टैंडर्ड ऑब्जेक्ट में कस्टम फ़ील्ड जोड़ सकते हैं, और आप जो भी जोड़ते हैं, वह __c पर खत्म होता है: Region__c (Custom Fields (opens in a new tab))। यही suffix आपको सुरक्षित रखता है। Salesforce अपनी रिलीज़ में Account में नए स्टैंडर्ड फ़ील्ड जोड़ता है, और क्योंकि आपके फ़ील्ड हमेशा __c पर खत्म होते हैं और उसके कभी नहीं, इसलिए कोई भविष्य का स्टैंडर्ड फ़ील्ड आपके किसी मौजूदा फ़ील्ड से कभी नहीं टकरा सकता।

कस्टम ऑब्जेक्ट। आपका अपना ऑब्जेक्ट __c पर खत्म होता है, Truck__c (Custom Objects (opens in a new tab)), और उस पर आपके डाले हुए कस्टम फ़ील्ड भी: Unit_Number__c। लेकिन जिन फ़ील्ड के साथ वह पैदा हुआ, यानी पिछले सेक्शन वाले, वे स्टैंडर्ड फ़ील्ड हैं: Name, OwnerId, CreatedDate, बिना suffix के। तो अपने खुद के ऑब्जेक्ट पर भी suffix आपको बताता है कि हर फ़ील्ड किसने बनाया।

Managed package ऑब्जेक्ट। जब आप AppExchange से कोई managed package इंस्टॉल करते हैं, तो उसके ऑब्जेक्ट और फ़ील्ड वेंडर के namespace prefix के साथ आते हैं: abc__Inspection__c, और abc__Result__c जैसे फ़ील्ड। वह prefix वेंडर के लिए यूनिक होता है, और बदलता नहीं (Namespace Prefix (opens in a new tab))। Salesforce के अपने शब्दों में, हर कंपोनेंट को यूनिक बनाने के लिए उसमें prefix जोड़ा जाता है: name__c बन जाता है prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab))। इसलिए दो वेंडर दोनों Invoice__c नाम का ऑब्जेक्ट दे सकते हैं और न आपस में टकराएँगे, न आपसे। package के ऑब्जेक्ट में अब भी उनके स्टैंडर्ड फ़ील्ड होते हैं, Name और OwnerId, बिना prefix के। एक package स्टैंडर्ड ऑब्जेक्ट में अपने prefix वाले फ़ील्ड भी जोड़ सकता है, जैसे Account पर abc__Score__c। और आप package के ऑब्जेक्ट में अपने कस्टम फ़ील्ड जोड़ सकते हैं: abc__Inspection__c पर Depot__c आपका __c suffix लेता है, लेकिन वेंडर का prefix कभी नहीं, क्योंकि उसे आपने बनाया है, उन्होंने नहीं (Known Issue: unmanaged custom field on a managed package object (opens in a new tab))।

Click to enlarge

कोई भी API नाम पढ़िए और आप जान जाते हैं कि उसे किसने बनाया। कोई suffix नहीं: Salesforce। बिना prefix के __c: आपका org। आगे abc__: वेंडर। हर बार जब आप किसी बदलाव की योजना बनाते हैं, यह मायने रखता है। जो आपका है, उसे आप बदल सकते हैं। जो Salesforce का है, उसे आप कॉन्फ़िगर करते हैं और आगे बढ़ाते हैं। जो वेंडर का है, वह ज़्यादातर बंद है: कुछ चीज़ें, जैसे पेज लेआउट और help text, आप बदल सकते हैं, लेकिन package का ज़्यादातर हिस्सा, और हर API नाम, वेंडर का है, और उनके अपग्रेड उनके बदलाव लाते हैं (Editable Properties After Package Promotion or Installation (opens in a new tab))।

Unmanaged package में ऐसा नहीं होता। कोई unmanaged package इंस्टॉल करें, और उसके ऑब्जेक्ट आपके org में ऐसे आ जाते हैं जैसे आपने खुद बनाए हों, बिना prefix के। अगर वह एक Truck__c लाता है और आपके पास पहले से एक है, तो नामों का टकराव हो गया। इंस्टॉल करने से पहले जाँच लें।

सिर्फ़ वही बनाएँ जो Salesforce के पास नहीं है

कस्टम ऑब्जेक्ट बनाना आसान है; ठीक इसी वजह से मुझे लगता है कि हम ज़रूरत से ज़्यादा बना लेते हैं। New Custom Object स्क्रीन ऐसे org में भी खुशी-खुशी आपके लिए एक Customer__c बना देगी जिसमें पहले से Account है। इसलिए क्लिक करने से पहले पिछले मॉड्यूल का सवाल पूछें: क्या मदरशिप के पास यह पहले से है? अगर है, तो उसे इस्तेमाल करें। अगर नहीं, तो बनाएँ, और पूरी स्क्रीन एक आर्किटेक्ट की तरह भरें।

अगला मॉड्यूल इससे भी पहले का सवाल पूछता है: क्या यह डेटा Salesforce में होना भी चाहिए?

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

• कस्टम ऑब्जेक्ट बनाने से पहले, क्या Salesforce के पास इसके लिए पहले से कोई स्टैंडर्ड ऑब्जेक्ट है।
• API नाम, जो एक बार चुना जाता है, और एक description जो लोगों और मशीनों दोनों के लिए लिखा गया हो।
• रिकॉर्ड का नाम: Text या Auto Number, अपेक्षित मात्रा को ध्यान में रखकर।
• कौन-से optional features, API access और search चालू करने हैं, सोच-समझकर।
• किसी org में suffix आपको क्या बताते हैं: कस्टम, managed, big, एक्सटर्नल, person account।
• जो package आप इंस्टॉल करने वाले हैं, क्या वह आपकी बनाई चीज़ों से टकरा सकता है।

और जानें

• Custom Objects (opens in a new tab) और Custom Fields (opens in a new tab), Object Reference (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): कस्टम ऑब्जेक्ट के नामों में दो underscore और उसके बाद छोटा “c” suffix के रूप में होता है (“the names of custom objects include a suffix of two underscores followed by a lowercase ‘c’”); कस्टम फ़ील्ड के लिए भी यही; और उन स्टैंडर्ड ऑब्जेक्ट की टेबल जो कस्टम फ़ील्ड सपोर्ट करते हैं।
• AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): namespace prefix हर packaged कंपोनेंट को यूनिक बनाता है; “name__c becomes prefix__name__c”।
• Namespace Prefix (opens in a new tab), Apex Developer Guide (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): namespace prefix managed package के ऑब्जेक्ट और फ़ील्ड के नामों को दूसरे orgs के नामों से अलग रखते हैं।
• Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (अंग्रेज़ी में, 2026-10-13 को जाँचा गया): package के कंपोनेंट की कौन-सी properties डेवलपर, subscriber, दोनों या कोई भी नहीं बदल सकता।
• Custom Object Standard Fields (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): वे स्टैंडर्ड फ़ील्ड जो हर कस्टम ऑब्जेक्ट को मिलते हैं (Name, Owner, Created By, Last Modified By, Currency, Division), और master-detail संबंध के detail हिस्से पर Owner क्यों हटा दिया जाता है।
• Standard User Licenses (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): एक Lightning Platform Light App Bulk API या Streaming API इस्तेमाल नहीं कर सकता (“can’t use the Bulk API or Streaming API”); एक Enterprise App रिकॉर्ड-स्तर की शेयरिंग सपोर्ट करता है और Bulk API व Streaming API इस्तेमाल कर सकता है (“supports record-level sharing, can use the Bulk API and Streaming API.”)।