אובייקטים מותאמים אישית
זמין גם ב-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)
יחידה 3 מתוך 10 בפרק ארכיטקטורת הנתונים של Salesforce, הפרק השלישי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: הביטו אל ספינת האם: מודלי הנתונים הסטנדרטיים · הבא: איפה הנתונים האלה חיים?
השאלה שהיחידה הזו עונה עליה: כש-Salesforce לא כוללת את מה שצריך, מה אתם בעצם מקבלים כשאתם בונים אובייקט משלכם?
ביחידה הקודמת הסתכלנו על מה ש-Salesforce כבר בנתה. לפעמים אין בה את מה שאתם צריכים. Steve Trucking מפעילה משאיות, ואין אובייקט Truck סטנדרטי. אז בונים אחד: אובייקט מותאם אישית.
הנה מה שאני רוצה שתראו ביחידה הזו. אובייקט מותאם אישית נוצר במטא-דאטה, כמו כל השאר ביחידה 1, וברגע שהוא קיים הוא מגיע עם סט של פונקציונליות סטנדרטית. הוא לא טבלה ריקה. והמסך שאתם ממלאים כדי ליצור אותו שואל אתכם שאלות ארכיטקטורה, בין אם אתם שמים לב ובין אם לא.
המסך New Custom Object
Section titled “המסך New Custom Object ”היכנסו ל-Setup → Object Manager → Create → Custom Object ותקבלו טופס ארוך אחד. רוב האנשים ממלאים את שתי התיבות הראשונות ולוחצים Save. בואו נאט ונקרא אותו.
Label ו-Plural Label. “Truck” ו-”Trucks”. את אלה המשתמשים רואים, בלשוניות, ב-page layouts ובדוחות. אפשר לשנות אותם בהמשך בלי הרבה כאב.
Object Name. זה שונה: זה שם ה-API, השם שקוד, אינטגרציות, דוחות ועכשיו גם סוכנים משתמשים בו. הקלידו “Truck” ו-Salesforce הופכת אותו ל-Truck__c. לשנות אותו בהמשך פירושו למצוא את כל מה שמפנה אליו, וזה שוב מבחן ההפיכות מפרק 1. תעשו את זה נכון בפעם הראשונה.
Description. מלאו את זה. כל פעם. ביחידה 1 אמרתי שמטא-דאטה היא כבר לא קישוט: האדמין הבא קורא את זה, וכך גם כל כלי AI שמנסה להבין את ה-org שלכם. אובייקט מותאם אישית עם תיאור ריק הוא קופסה בלי תווית.
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. השמות האלה מתיישרים עם רישיונות ה-app-subscription של Salesforce: ל-Lightning Platform Light App אין שיתוף ברמת הרשומה והוא לא יכול להשתמש ב-Bulk API או ב-Streaming API, ו-Enterprise App כן יכול. העצה שלי: השאירו אותם מופעלים, אלא אם אתם יודעים בדיוק למה לא. כבו את הגישה ל-Bulk API באובייקט שבהמשך תטענו אליו כמויות גדולות, ותגלו למה זה היה חשוב.
Deployment Status ו-Search. “In Development” מסתיר את האובייקט מהמשתמשים בזמן שאתם בונים אותו; “Deployed” מעלה אותו לאוויר. ו-Allow Search כבוי כברירת מחדל, כך שמשתמשים לא ימצאו את הרשומות האלה בחיפוש הגלובלי עד שתפעילו אותו. זה תופס אנשים כל פעם מחדש.
ברירות המחדל: שלוש הגדרות ה-API מופעלות, Deployed, ו-Allow Search כבוי (צילום מסך, 2026-10-12). בגודל מלא
לחצו Save, ו-Object Manager מראה לכם את האובייקט: שם API Truck__c, סימון ב-Custom, התוויות, סטטוס הפריסה. אבל תסתכלו לאורך הצד השמאלי: 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). בגודל מלא
השדות שלא יצרתם
Section titled “השדות שלא יצרתם ”פתחו את Fields & Relationships באובייקט מותאם אישית חדש לגמרי, ויש בו כבר שדות. כל אובייקט מותאם אישית מקבל סט סטנדרטי:
- Name, שם הרשומה שבחרתם זה עתה, שמשמש ב-page layouts, ברשימות קשורות, ב-lookups ובתוצאות חיפוש.
- Owner, המשתמש או התור שהרשומה בבעלותם.
- Created By ו-Last Modified By, המשתמשים שיצרו אותה ושינו אותה לאחרונה.
- Currency, אם ריבוי מטבעות מופעל, ו-Division, אם ה-org שלכם משתמש בחטיבות.
ומתחת לפני השטח, מזהה הרשומה מיחידה 1, ותאריכי היצירה והשינוי. ייצאו כמה רשומות עם Data Loader ותראו את כולם.
אחד מהם יכול להיעלם. הפכו את האובייקט המותאם אישית שלכם לצד ה-detail בקשר master-detail, ו-שדה ה-Owner נעלם: הבעלות מגיעה במקום זאת מרשומת ה-master. זה עניין גדול יותר ממה שזה נשמע, ונחזור לזה ביחידות 7 ו-8.
קידומות וסיומות: על מה אתם מסתכלים
Section titled “קידומות וסיומות: על מה אתם מסתכלים ”ביחידה הקודמת אמרתי שלאובייקטים סטנדרטיים אין קידומת ואין סיומת. לכל השאר יש, וברגע שאתם יודעים לקרוא אותן, רשימת שדות אומרת לכם בדיוק על מה אתם מסתכלים.
| איך זה נראה | מה זה |
|---|---|
Account, Case | אובייקט או שדה סטנדרטי: בלי קידומת, בלי סיומת |
Truck__c | אובייקט מותאם אישית, או שדה מותאם אישית, כמו Unit_Number__c |
abc__Inspection__c | אובייקט מותאם אישית מ-managed package (חבילה מנוהלת): abc הוא ה-namespace של הספק |
Delivery_History__b | big object (יחידה 4) |
Shipment__x | אובייקט חיצוני: הנתונים חיים במערכת אחרת (יחידה 4) |
Allergies__pc | שדה איש קשר מותאם אישית ב-חשבון אישי (יחידה 2) |
Truck__r | הקשר שמאחורי lookup מותאם אישית, כשעוקבים אחריו בשאילתה |
כמה דברים שכדאי לשים לב אליהם.
עד כאן זו רשימה. הנה איך אני מלמד את זה: בשכבות. יש שלושה סוגי אובייקטים, סטנדרטי, מותאם אישית ו-managed package, ולכל אחד מהם יכולים להיות אותם סוגי שדות: השדות הסטנדרטיים שהוא הגיע איתם, והשדות המותאמים אישית שמישהו הוסיף.
אובייקטים סטנדרטיים. ל-Account אין קידומת ואין סיומת, וגם לשדות הסטנדרטיים שלו אין: Name, Industry, OwnerId. אפשר להוסיף שדות מותאמים אישית לרוב האובייקטים הסטנדרטיים, וכל אחד שתוסיפו מסתיים ב-__c: Region__c (Custom Fields (opens in a new tab)). הסיומת הזו היא מה ששומר עליכם. Salesforce מוסיפה שדות סטנדרטיים חדשים ל-Account בגרסאות שלה, ומכיוון שהשדות שלכם תמיד מסתיימים ב-__c ושלה אף פעם לא, שדה סטנדרטי עתידי לא יוכל אף פעם להתנגש בשדה שכבר יש לכם.
אובייקטים מותאמים אישית. האובייקט שלכם מסתיים ב-__c, Truck__c (Custom Objects (opens in a new tab)), וכך גם השדות המותאמים אישית שאתם שמים עליו: Unit_Number__c. אבל השדות שהוא נולד איתם, אלה מהחלק הקודם, הם שדות סטנדרטיים: Name, OwnerId, CreatedDate, בלי סיומת. כך שגם באובייקט שלכם, הסיומת אומרת לכם מי יצר כל שדה.
אובייקטים של managed package. כשמתקינים managed package מ-AppExchange, האובייקטים והשדות שלו מגיעים עם קידומת ה-namespace של הספק: abc__Inspection__c, ושדות כמו abc__Result__c. הקידומת הזו ייחודית לספק, והיא לא משתנה (Namespace Prefix (opens in a new tab)). במילים של Salesforce עצמה, הקידומת מתווספת לכל רכיב כדי להפוך אותו לייחודי: name__c הופך ל-prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab)). כך ששני ספקים יכולים לשלוח שניהם אובייקט בשם Invoice__c ולעולם לא להתנגש זה בזה, או בכם. לאובייקטים של החבילה עדיין יש את השדות הסטנדרטיים שלהם, Name ו-OwnerId, בלי קידומת. חבילה יכולה גם להוסיף שדות משלה עם קידומת לאובייקטים סטנדרטיים, כמו abc__Score__c ב-Account. ואתם יכולים להוסיף שדות מותאמים אישית משלכם לאובייקטים של חבילה: Depot__c ב-abc__Inspection__c מקבל את הסיומת __c שלכם, אבל אף פעם לא את הקידומת של הספק, כי אתם יצרתם אותו, לא הם (Known Issue: unmanaged custom field on a managed package object (opens in a new tab)).
קראו כל שם API ותדעו מי יצר אותו. בלי סיומת: Salesforce. __c בלי קידומת: ה-org שלכם. abc__ מלפנים: הספק. זה חשוב בכל פעם שאתם מתכננים שינוי. מה ששלכם, אתם יכולים לשנות. מה ששל Salesforce, אתם מגדירים ומרחיבים. מה ששל הספק נעול ברובו: כמה דברים, כמו page layouts וטקסט עזרה, אתם יכולים לערוך, אבל רוב החבילה, וכל שם API, שייכים לספק, והשדרוגים שלו מביאים את השינויים שלו (Editable Properties After Package Promotion or Installation (opens in a new tab)).
לחבילות unmanaged אין קידומת. התקינו חבילת unmanaged, והאובייקטים שלה נוחתים ב-org שלכם כאילו בניתם אותם בעצמכם, בלי קידומת. אם היא מביאה Truck__c וכבר יש לכם אחד, יש לכם התנגשות שמות. בדקו לפני שאתם מתקינים.
בנו רק את מה שאין ב-Salesforce
Section titled “בנו רק את מה שאין ב-Salesforce ”ליצור אובייקט מותאם אישית זה קל; בדיוק בגלל זה אני חושב שאנחנו יוצרים יותר מדי כאלה. המסך New Custom Object ייצור לכם בשמחה Customer__c ב-org שכבר יש בו Account. אז לפני שאתם לוחצים, שאלו את השאלה מהיחידה הקודמת: האם לספינת האם כבר יש את זה? אם כן, השתמשו בזה. אם לא, בנו את זה, ומלאו את כל המסך כמו ארכיטקטים.
היחידה הבאה שואלת שאלה מוקדמת עוד יותר: האם הנתונים האלה בכלל צריכים להיות ב-Salesforce?
מה הארכיטקט מחליט כאן
Section titled “מה הארכיטקט מחליט כאן ”- האם ל-Salesforce כבר יש אובייקט סטנדרטי לזה, לפני שבונים אובייקט מותאם אישית.
- שם ה-API, שנבחר פעם אחת, ותיאור שנכתב לאנשים ולמכונות.
- שם הרשומה: Text או Auto Number, עם הכמות הצפויה בראש.
- אילו תכונות אופציונליות, גישת API וחיפוש להפעיל, בכוונה.
- מה הסיומות ב-org אומרות לכם: מותאם אישית, managed, big, חיצוני, חשבון אישי.
- האם חבילה שאתם עומדים להתקין עלולה להתנגש במה שבניתם.
להרחבה
Section titled “להרחבה ”- Custom Objects (opens in a new tab) ו-Custom Fields (opens in a new tab), Object Reference (באנגלית, נבדק ב-2026-10-13): “השמות של אובייקטים מותאמים אישית כוללים סיומת של שני קווים תחתונים ואחריהם ‘c’ קטנה”; אותו דבר לשדות מותאמים אישית; וטבלת האובייקטים הסטנדרטיים שתומכים בשדות מותאמים אישית.
- AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (באנגלית, נבדק ב-2026-10-13): קידומת namespace הופכת כל רכיב ארוז לייחודי; “name__c הופך ל-prefix__name__c”.
- Namespace Prefix (opens in a new tab), Apex Developer Guide (באנגלית, נבדק ב-2026-10-13): קידומות namespace שומרות את שמות האובייקטים והשדות של managed packages נפרדים מאלה של orgs אחרים.
- Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (באנגלית, נבדק ב-2026-10-13): אילו מאפיינים של רכיבי חבילה יכולים לערוך המפתח, המנוי, שניהם או אף אחד מהם.
- Custom Object Standard Fields (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-12): השדות הסטנדרטיים שכל אובייקט מותאם אישית מקבל (Name, Owner, Created By, Last Modified By, Currency, Division), ולמה Owner מוסר בצד ה-detail של קשר master-detail.
- Standard User Licenses (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-12): Lightning Platform Light App “לא יכול להשתמש ב-Bulk API או ב-Streaming API”; Enterprise App “תומך בשיתוף ברמת הרשומה, יכול להשתמש ב-Bulk API וב-Streaming API.”