גם שדות הם ארכיטקטורה

🌐 זמין גם ב-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)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 6 מתוך 10 בפרק ארכיטקטורת הנתונים של Salesforce, הפרק השלישי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: בחרו את האובייקט הנכון · הבא: לקשרים יש השלכות

השאלה שהיחידה הזו עונה עליה: איך Salesforce צריכה לייצג פיזית כל פיסת נתונים?

יצירת שדה לוקחת בערך דקה. New Field, בוחרים סוג, נותנים שם, Next, Next, Save. בדיוק בגלל זה לא מתייחסים לשדות כארכיטקטורה.

היכנסו ל-org שקיים כבר עשר שנים ופתחו את Account. חמש מאות שדות. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. שלושה מספרי לקוח שונים. תיבת סימון שאף אחד לא ימחק כי אף אחד לא יודע איזו אינטגרציה עוד משתמשת בה. יצירת השדה לקחה דקה. לחיות איתו לוקח שנים. אז הרעיון של היחידה הזו פשוט: שדה הוא החלטה ארכיטקטונית. לא תמיד גדולה, אבל כל שדה מקודד משהו על המשמעות, ההתנהגות, הזיהוי או האיכות של הנתונים, וכמו אובייקטים, קל להוסיף שדות וקשה באופן מפתיע להוריד אותם.

מה הנתונים האלה באמת אומרים?

בפרק 2 נתנו לישויות שלנו מאפיינים: למשלוח יש חלון זמן מתוכנן, למשאית יש VIN. עכשיו אנחנו מממשים אותם, וכאן אנשים קופצים ישר ל”שדה טקסט”. חכו. לפני הסוג, אני רוצה לדעת מה הנתונים אומרים. האם זה מספר, או מזהה שבמקרה יש בו ספרות? תאריך, או רגע בזמן? טקסט חופשי, או אחד מתוך קבוצה מאושרת? מוזן על ידי אדם, או בבעלות מערכת אחרת? האם הוא יכול להשתנות? האם הוא חייב להיות ייחודי? האם הוא יכול להיות חסר? האם בכלל צריך לאחסן אותו, או לחשב? אלה לא שאלות של Setup. אלה שאלות של ארכיטקטורת נתונים, וסוג השדה מגיע אחרי שעונים עליהן.

מספר הוא לא תמיד מספר

Steve Trucking נותנת לכל משאית מספר צי, נגיד 001247. שדה Number? כנראה שלא. האם אנחנו מחברים מספרי צי? האם משאית 1247 פחות משאית 1246 זו משאית אחת? זה מזהה שבמקרה מכיל ספרות, ושדה Number אפילו היה מוריד את האפסים המובילים. אותו דבר לגבי מיקודים, קודי מוצר, מספרי חשבון ומספרי מעקב. איך הערך נראה לא אומר לכם מה הוא אומר. בחרו את הסוג לפי ההתנהגות שאתם צריכים, לא לפי איך שנתוני הדוגמה נראים.

האם אדם צריך לזהות את זה?

כל אובייקט מותאם אישית מקבל שדה Name, וההחלטה הראשונה היא טקסט או auto number. אני שואל: האם אדם צריך לזהות את הדבר הזה? אנשים מכירים שותף קמעונאי לפי שם ומשאית לפי מספר הצי שלה. אבל מניפסט שהמערכת מייצרת כל לילה? אף אחד לא אמור להקליד “מניפסט 10-02 מספר 3” רק כי Salesforce דרשה Name. תנו לו auto number. רק אל תבלבלו בין ה-Name שנוצר לבין הזיהוי של הרשומה: ה-auto number עוזר למשתמשים, מזהה ה-Salesforce מזהה את הרשומה, ומספר המניפסט של השותף הקמעונאי עצמו עשוי לזהות את אותו דבר בין מערכות. שלושה תפקידים שונים.

מסך הפרטים

בוחרים סוג, לוחצים Next, ו-Setup מבקש את הפרטים. זה המסך שבו רוב ההחלטות ביחידה הזו באמת מתקבלות, בדרך כלל בחיפזון.

New Custom Field, שלב 2: הפרטים (צילום מסך, 2026-10-12). בגודל מלא

שתי תיבות נראות דומות ועושות עבודות שונות. Description מיועד לאנשים שמתחזקים את ה-org, ועכשיו גם לכלי ה-AI שקוראים אותו: מה השדה אומר, למי הוא שייך, מאיפה הוא מגיע. Help Text מיועד למשתמש שמול המסך: מה להקליד כאן. מלאו את שניהם. אחר כך מגיעים Required, Unique ו-External ID, ולכל אחד מהם מגיע חלק משלו. מתחתם, Default Value יכול להיות נוסחה, כך שרשומה חדשה יכולה להתחיל עם ערך הגיוני במקום ריק.

Required היא החלטה גדולה יותר ממה שהיא נראית

יש תיבת סימון קטנה באשף השדות שנקראת Required (חובה), וכמו שראינו בפרק 1, היא יכולה להיות פצצה מתקתקת. יש לכם אובייקט כבר חמש שנים ושני מיליון רשומות, ועכשיו מישהו מחליט ששדה חדש חייב תמיד לקבל ערך. מה עם שני מיליון הרשומות שקדמו לו? האינטגרציות שלא שולחות אותו? האוטומציה שיוצרת את הרשומה לפני שהערך ידוע? התהליך שבו הערך מופיע רק שלושה שלבים אחר כך?

“חובה” נשמע כמו החלטה של איכות נתונים, ולפעמים זה באמת כך. אבל מתי ערך הופך לידוע זה חלק מהתהליך העסקי. אז אל תסמנו Required כי מישהו אומר “אנחנו תמיד רוצים את זה”. שאלו מתי זה ידוע, מי מספק את זה, ומה קורה כשזה לא. נמקם את זה על סולם העקביות המלא ביחידה 7.

גם לייחודי יש משמעות

אם אני מסמן שדה כייחודי, אני אומר משהו על העסק: לא “זה בדרך כלל לא חוזר”, אלא “לשתי רשומות לעולם לא יכול להיות הערך הזה”. זו אמירה חזקה. והמסך מכריח אתכם להחליט עוד דבר: האם “ABC” ו-”abc” הם אותו ערך או ערכים שונים? חוסר רגישות לאותיות רישיות היא ברירת המחדל הבטוחה יותר לכל מה שאדם מקליד. כלל המפתח מפרק 2, ייחודי, לא משתנה, חסר משמעות, אף פעם לא PII, חל כאן. אם מישהו אומר לי שכתובת הדוא”ל של עובד היא ייחודית, אני מתחיל לשאול: האם היא יכולה להשתנות, האם מישהו יכול לעזוב ולחזור, האם אפשר למחזר כתובות, מה קורה אחרי רכישה? דוא”ל יכול להיות שימושי, אפילו ייחודי היום. זה לא הופך אותו למזהה טוב.

External IDs: זיהוי מעבר לגבול

כאן External IDs מצדיקים את קיומם. המסך מתאר את זה היטב: השדה הופך ל”מזהה הרשומה הייחודי ממערכת חיצונית”. ב-ERP יש לקוח 873492; ב-Salesforce יש מזהה רשומה משלה. כשה-ERP שולח עדכון, איך יודעים לאיזו רשומה הוא שייך? סמנו שדה כ-External ID ואינטגרציה יכולה לבצע עליו upsert: ליצור את הרשומה אם היא לא קיימת, לעדכן אותה אם היא קיימת (Upsert a Record Using an External ID (opens in a new tab)). וכשטוענים רשומות ילד, אפשר להצביע על ההורה לפי ה-External ID שלו במקום לשאול קודם על מזהה ה-Salesforce. אני אוהב לומר שאתם נותנים ל-Salesforce לעשות את ה-lookup בשבילכם. חזק מאוד.

שימו לב שהמספר של ה-ERP לא הופך למזהה של רשומת ה-Salesforce. הוא מאפיין, ורשומה יכולה לשאת כמה כאלה: מזהה לקוח ב-ERP, מזהה legacy, מזהה של שותף. זה בסדר. ישות עסקית אחת יכולה להיות מוכרת אחרת בכמה מערכות. השאלה הארכיטקטונית היא איזו מערכת היא הבעלים של כל מזהה, ואיזו הבטחה הוא נותן: סמנו אותו כייחודי רק אם העסק באמת מבטיח את זה.

סוג שדה אחר סוג שדה

עכשיו הסוגים עצמם. פתחו New Field בכל אובייקט ו-Setup מראה לכם את כל הרשימה, מקובצת כמו שאעבור עליה: השדות ש-Salesforce מחשבת בשבילכם, שדות הקשר, ואחר כך סוגי הנתונים.

Setup, New Custom Field, שלב 1: סוגי הנתונים (צילום מסך, 2026-10-12). בגודל מלא

הנה כל הרשימה במבט אחד, עם הדבר האחד שהייתי רוצה שתזכרו על כל אחד.

קבוצה	סוג	לזכור
מחושבים	Auto Number	עד 30 תווים, 20 מהם קידומת או סיומת; תווית לאנשים, לא המזהה של הרשומה
	Formula	מחושב כשקוראים אותו, לא מאוחסן; 3,900 תווים
	Roll-Up Summary	ספירה, סכום, מינימום או מקסימום של רשומות ה-detail; ב-master-detail בלבד
קשרים	Lookup, Master-Detail, External Lookup	יחידה 7
נתונים	Checkbox	אמת או שקר, עם ברירת מחדל שאתם בוחרים; null עדיין יכול להופיע ב-flows
	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 מהם שמורים לקידומת או לסיומת. רק זכרו מפרק 2: זו תווית לאנשים, לא המזהה של הרשומה, והמספרים לא תמיד רציפים לחלוטין.

שדות Formula מחשבים ערך משדות אחרים. הם חזקים, והם מחושבים כשקוראים את הרשומה, לא כששומרים אותה, כך שאין שום דבר מאוחסן שיכול להתיישן. אתם בוחרים מה הנוסחה מחזירה: checkbox, currency, date, date/time, number, percent, text או time.

New Custom Field, נוסחה: בחירת סוג ההחזרה (צילום מסך, 2026-10-12). בגודל מלא

ואז כותבים את הנוסחה עצמה, עם שדות, אופרטורים ופונקציות, ובודקים את התחביר שלה. שימו לב לכפתור Use Formula Assistant: ה-AI של Salesforce יעזור לכם עכשיו לכתוב את הנוסחה. השתמשו בו, ואז קראו מה הוא כתב. הנוסחה שלכם, לא של העוזר.

עורך הנוסחאות, עם ה-Formula Assistant (צילום מסך, 2026-10-12). בגודל מלא נוסחה יכולה להיות באורך של עד 3,900 תווים, והיא לא יכולה לעבור 15,000 בתים בשמירה או בהידור; נוסחה ארוכה אפשר לפצל לכמה שדות נוסחה שמפנים זה לזה. אי אפשר להשתמש בהן בשדות long text area, בשדות מוצפנים ובשדות Description.

שדות Roll-Up Summary יושבים על ה-master וסופרים, מסכמים, או לוקחים את המינימום או המקסימום של רשומות ה-detail שלו. הם עובדים רק לאורך קשר master-detail, וזו אחת הסיבות הגדולות לבחור ב-master-detail מלכתחילה. נחזור אליהם, ולמגבלות שלהם, ביחידה 7.

מאוחסן או נגזר?

האם בכלל צריך לאחסן את הערך הזה? אם יש לי כמות ומחיר ליחידה, האם מישהו, או אוטומציה כלשהי, צריכים לתחזק סכום כולל? אולי נוסחה צריכה לגזור אותו: מקור אחד לחישוב, שמחושב מחדש כשקוראים אותו, כך שמשנים את הכמות והתשובה באה בעקבותיה. לנוסחאות יש מגבלות משלהן (גודל שמירה ואורך תצוגה; Formula Field Limits and Restrictions (opens in a new tab)), ונוסחאות מורכבות נעשות קשות לתחזוקה.

אבל לפעמים העסק לא רוצה את התשובה של היום. הוא רוצה את התשובה כפי שהייתה. אם כלל ההנחה משתנה בשנה הבאה, האם החשבונית של השנה שעברה צריכה פתאום להציג סכום אחר? ברור שלא. אז השאלה היא לא “האם Salesforce יכולה לחשב את זה?” היא “האם זה חישוב עדכני או עובדה היסטורית?” עובדות היסטוריות מאחסנים.

שדות הקשר

קשרי Lookup, Master-Detail ו-External Lookup הם גם שדות, ושם הקווים של המודל שלכם הופכים לאמיתיים. ה-lookup הוא הקישור הרופף; master-detail קושר את החיים, הבעלות והאבטחה של הילד להורה; ה-external lookup מגיע לאובייקט חיצוני מיחידה 4, בהתאמה לפי ה-External ID שלו. הבחירה ביניהם היא החלטה גדולה מספיק כדי לקבל יחידה משלה.

Checkbox

Checkbox (תיבת סימון) הוא השדה הפשוט ביותר שיש: אמת או שקר, מסומן או לא מסומן. הוא מושלם לעובדה של כן/לא על הרשומה: Is Active, Install Required, Signed For. כשיוצרים אחד, Salesforce מכריחה אתכם לבחור את ערך ברירת המחדל שלו, מסומן או לא מסומן, וזו החלטה אמיתית: זה מה שכל רשומה חדשה מתחילה איתו, כולל רשומות שאינטגרציה יוצרת בלי לשלוח את השדה. דוחות ו-list views מסננים אותו כ-True ו-False; כלי הייבוא והייצוא השבועי מציגים אותו כ-1 ו-0.

מלכודת אחת שכדאי להכיר. לשדה ברשומה יש שני ערכים, אבל לאוטומציה סביבו יכול להיות שלישי. ב-flow, משתנה checkbox שאף פעם לא הוגדר הוא null, לא false, ושמירה שלו לרשומה נכשלת (Trailblazer Community (opens in a new tab); ראו גם את הבעיה הידועה של Salesforce W-11208535 (opens in a new tab)). בחרו ברירת מחדל הגיונית, וגרמו ל-flows ולקוד שלכם לטפל ב-null בכוונה.

Number, Percent ו-Currency

Number מאחסן מספר ממשי, ומוחק אפסים מובילים, וזו בדיוק הסיבה שמספר צי כמו 001247 הוא לא Number. Salesforce מעגלת שדות מספר חצי הרחק מאפס: 12.345 הופך ל-12.35, ו-−12.345 הופך ל-−12.35. ובשדות מיזוג (merge fields), היא מעגלת לפי ה-locale של המשתמש, לא לפי מספר הספרות אחרי הנקודה שהגדרתם בשדה.

Percent מאחסן מספר עשרוני ומציג אחוז: מזינים 0.10 ורואים 10%. ערכים מאבדים דיוק אחרי 15 ספרות אחרי הנקודה.

Currency מעוצב לכסף, וב-org עם כמה מטבעות הוא נושא את קוד המטבע שלו ויכול להשתמש בשערי חליפין; עם advanced currency management (opens in a new tab), הזדמנויות יכולות להשתמש בשערי חליפין מתוארכים, השער של התקופה שבה העסקה נסגרה. רק הזדמנויות והדברים סביבן (מוצרים, לוחות זמנים, פיצולים והדוחות שלהם) משתמשים בשערים מתוארכים; שדות מטבע באובייקטים אחרים שומרים על השער הסטטי היחיד. שימו לב לעיגול: בלי ספרות אחרי הנקודה, Salesforce פשוט קוטעת (23.5 הופך ל-23); עם ספרה אחת או יותר, היא מעגלת חצי הרחק מאפס.

Date, Date/Time ו-Time

שלושה סוגים, שלוש משמעויות שונות. Date הוא יום: חוזה פג בתאריך מסוים. Date/Time הוא רגע: המשלוח הגיע ב-9:42 באותו בוקר. Time הוא שעה ביום בלי תאריך בכלל: החנות נפתחת ב-7:00, כל יום.

המלכודת היא הרגע. Salesforce מאחסנת ערכי date/time ב-GMT (UTC). השעה שמשתמש מקליד נקראת באזור הזמן שלו, מומרת ומאוחסנת; כשמישהו קורא אותה, היא מומרת שוב לאזור הזמן של הקורא. רוב הזמן זה בדיוק מה שרוצים. אבל הנה הדוגמה שאני נותן בכיתה: רכז בלוס אנג’לס רושם משלוח מאוחר במוצאי יום ראשון, ב-22:00 לפי שעון האוקיינוס השקט. מתחת לפני השטח, Salesforce אחסנה יום שני בבוקר, 05:00 GMT. דוח שמקובץ לפי יום באזור זמן אחר, או אינטגרציה שקוראת את הערך הגולמי, יכולים לשים את משלוח יום ראשון ביום שני. “היום שבו זה קרה” תלוי בשעון של מי ששואלים. שימו לב לאזורי הזמן של המשתמשים, והחליטו לאיזה מהם העסק מתכוון.

והיזהרו כשמשווים ביניהם. מתחת לפני השטח, 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, באזור הזמן שהחלטתם שהעסק מתכוון אליו.

ועוד אחד משעשע: Salesforce לא יכולה לאחסן כל תאריך. תאריכים חוקיים נעים בין 1 בינואר 1700 ל-31 בדצמבר 4000, ו-Salesforce נותנת אותו טווח לתאריכים ול-date/times (Data Import Dates (opens in a new tab)). אפילו הקצוות הם רגעים ב-GMT, כך שעבור משתמש בשעון האוקיינוס השקט הערך החוקי המוקדם ביותר הוא 16:00 ב-31 בדצמבר 1699. ייתכן שתאריך הייסוד של האגודה ההיסטורית שלכם לא ייכנס. וטריק “אין תאריך סיום” הקלאסי, 31 בדצמבר 9999, נדחה; אם אתם צריכים ממלא מקום בעתיד הרחוק, הוא חייב להיות בשנת 4000 או לפניה.

Email, Phone ו-URL

אלה השדות המעוצבים, והם עושים יותר מלאחסן תווים. Email מחזיק עד 80 תווים ונבדק שהוא בפורמט תקין; באנשי קשר ובלידים, לחיצה עליו פותחת דוא”ל לכתובת הזו. Phone מחזיק עד 40 תווים, מעוצב כמספר טלפון, והופך ל-click-to-dial (חיוג בלחיצה) כשמחוברת ל-org מערכת טלפוניה. URL מחזיק עד 255 תווים ונפתח כקישור. זו הפלטפורמה שנותנת לכם התנהגות בחינם, ולכן לעולם לא הייתי מאחסן מספר טלפון בשדה טקסט רגיל.

גם אינטגרציות נבדקות. ערך שלא תואם את הפורמט של השדה, כמו כתובת דוא”ל לא תקינה, נכשל באימות, ו-הרשומה כולה נדחית, לא רק השדה הזה. אז כשהנתונים במערכת המקור מבולגנים, נקו אותם לפני שהם מגיעים, או תכננו מראש מה קורה עם הרשומות שלא ייטענו.

Geolocation ו-Address

Geolocation מחזיק קו רוחב וקו אורך. מתחת לפני השטח, שדה בשם Location__c הוא בעצם שני ערכים שאפשר לקרוא ולהגדיר כל אחד בנפרד, Location__Latitude__s ו-Location__Longitude__s. ואפשר לשאול עליו: הפונקציות DISTANCE ו-GEOLOCATION של SOQL מוצאות רשומות בתוך רדיוס, או ממיינות אותן לפי המרחק. “כל משלוח פתוח בטווח 25 מייל מהמשאית הזו” היא שאילתה אחת: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Address מחזיק כתובת שלמה, רחוב, עיר, מדינה או מחוז, מיקוד וארץ, ומשתמשים יכולים לחפש כתובת ולקבל את החלקים ממולאים.

שניהם שדות מורכבים (compound fields): שדה אחד על המסך, כמה מתחת לפני השטח. והם עולים יותר משדה אחד מול המגבלה של האובייקט שלכם: Geolocation נספר כשלושה שדות מותאמים אישית, ו-Address נספר כתשעה. באובייקט שכבר צפוף, זה משנה.

Picklist ו-Multi-Select

רשימת בחירה (picklist) שולטת במה שמשתמשים יכולים להזין: ערך אחד מתוך רשימה שאתם מגדירים. סטטוס? כנראה רשימת בחירה. אבל הערכים הם מטא-דאטה, ו-אדמין צריך להוסיף או לשנות אותם. אז אני עדיין שואל למי שייכים הערכים, באיזו תדירות הם משתנים, האם כמה אובייקטים צריכים את אותה רשימה, האם לערכים יש מידע משלהם, והאם מערכת אחרת היא הבעלים של אוצר המילים.

גם המקום שבו הערכים חיים הוא החלטה. כשרשימה משמשת פעם אחת, בשדה אחד, השאירו את הערכים על השדה עצמו, באובייקט; זה מה ש-Salesforce עושה כברירת מחדל. אבל כשאותה קבוצת ערכים מתחילה להופיע בכמה מקומות, אזור (Region) בחשבון, במשלוח ובמחסן, קדמו אותה לקבוצת ערכים גלובלית לפני שהעותקים מתרחקים זה מזה. קבוצת ערכים גלובלית (global value set) שומרת רשימה אחת לכולם, עד 1,000 ערכים, פעילים ולא פעילים ביחד (Picklist Limitations (opens in a new tab)). התיאור של Setup עצמו אומר למה זה חשוב: קבוצת הערכים “מוגבלת, כך שמשתמשים לא יכולים להוסיף ערכים לא מאושרים דרך ה-API.” רשימה אחת, בעלים אחד, ואף אינטגרציה לא מגניבה פנימה איות חדש.

הנקודה האחרונה הזו היא ההבדל בין restricted (מוגבלת) ל-unrestricted (לא מוגבלת). ברשימת בחירה מוגבלת, רק הערכים שאדמין הגדיר מותרים, מכל מקום: משתמש, ייבוא או אינטגרציה ששולחים משהו אחר מקבלים שגיאה, “bad value for restricted picklist field”, והרשומה לא נשמרת. ברשימת בחירה לא מוגבלת, משתמשים עדיין בוחרים מהרשימה על המסך, אבל ה-API, ייבואים ואוטומציה יכולים לשלוח כל ערך, ו-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 picklist) מאפשרת למשתמש לבחור כמה ערכים, שמאוחסנים יחד ומופרדים בנקודה-פסיק. נוח על המסך, מסורבל בכל מקום אחר: קשה יותר לסנן, להפיק דוחות ולבנות אינטגרציה עליה, ואי אפשר להשתמש בה במסנן של roll-up summary. כמה ערכים לרשומה אחת בדרך כלל אומרים את השיעור מפרק 2: יש אובייקט ילד שמנסה לצאת החוצה.

לרשימת בחירה יש גם ערך אחד יותר מאלה שהגדרתם: ריק. רשומה יכולה לשבת בלי שום דבר נבחר, וזה תופס אנשים. בנוסחה או בכלל אימות אי אפשר לבדוק רשימת בחירה עם ISBLANK לבד; כותבים ISBLANK(TEXT(Field__c)), או ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). אז החליטו מה “אין ערך” אומר לכל רשימת בחירה: האם זה מותר, ומה זה אומר כשזה קורה? ואז גרמו לנוסחאות, לכללי האימות ולמסננים שלכם לטפל בזה.

ולפעמים מאפיין הוא בעצם ישות. מישהו מבקש רשימת בחירה של מרכזי הפצה. יש תשעה. קל. ואז מגלים שלכל אחד יש כתובת, מנהל, שעות פעילות, קיבולת, אזור ומשאיות. זו לא רשימת בחירה; זה דבר. אל תהפכו ישות לרשימת בחירה רק כי עדיין אין הרבה כאלה. זה מרגיש נהדר בשנה הראשונה ונורא בשנה החמישית. (ביחידה 5 בפרק 2 יש את כללי האצבע שלי למתי רשימה מצדיקה אובייקט משלה.)

משפחת הטקסט

אני מלמד טקסט כשני סוגים, והקו ביניהם הוא 255 תווים.

עד 255: מאוחסן עם הרשומה. Text מחזיק עד 255 תווים, ואפשר להשתמש בו כמעט בכל מקום: בנוסחאות, במסננים, בדוחות, ב-list views, כשדה ייחודי או כ-External ID, ואפשר לאנדקס אותו. Text Area מחזיק גם הוא 255, בשורות נפרדות, כמו הערה קצרה.

מעל 255: מאוחסן בהפניה. Text Area (Long) מחזיק עד 131,072 תווים, ו-Text Area (Rich) מחזיק אותו דבר עם עיצוב, קישורים ותמונות. אני חושב עליהם כעל משהו שמאוחסן בצד, כשהרשומה מחזיקה מצביע, והם מתנהגים כך: אין אינדקס, אז אי אפשר להפוך אותם לייחודיים או ל-External ID; אי אפשר לסנן לפיהם בפסוקית WHERE של SOQL (SOQL WHERE (opens in a new tab)); נוסחאות לא יכולות להשתמש בהם (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 כל אחת, והן נספרות באחסון הקבצים, בזמן שהטקסט נספר באחסון הנתונים (Rich Text Area Field Considerations (opens in a new tab)). אז אם מישהו צריך לחפש, למיין, להתאים או להפיק דוחות לפי הערך, השאירו אותו מתחת ל-255 והשאירו אותו שדה Text.

Text (Encrypted) מאחסן עד 175 תווים בצורה מוצפנת, באמצעות Classic Encryption. אם ה-org שלכם משתמש ב-Shield Platform Encryption, מצפינים במקום זאת שדה Text רגיל, ואפשר להצפין כך גם סוגים רבים אחרים.

תנו לכל שדה תיאור

הסטנדרט שלי: כל שדה מקבל תיאור. אני מאמין בזה הרבה זמן, ובתקופת ה-AI זה חשוב יותר מתמיד: כל כלי AI וכל סוכן שקורא את ה-org שלכם קורא את התיאורים כדי להבין מה שדה אומר. תיאור ריק הוא ניחוש שמחכה לקרות. מה אומר Customer_Status__c? למי הוא שייך? מאיפה הוא מגיע? האם משתמשים יכולים לערוך אותו, או שה-ERP ידרוס אותו הלילה? בעוד שישה חודשים אני לא אזכור, ובעוד שלוש שנים האדמין שמתחזק את ה-org לא יידע אלא אם סיפרנו לו. התווית היא לא תיעוד, וגם שם ה-API לא.

באובייקטים משותפים מאוד (Account, Contact, Opportunity) אני משתמש גם בקידומות שמות לשדות ייעודיים, כך שהמקור והמטרה שלהם נראים בשם עצמו: כל מה שה-ERP הוא הבעלים שלו מתחיל באותה קידומת, למשל. אני לא מחפש שמות API של שתים-עשרה מילים. אני רוצה שהמודל יסביר את עצמו.

סווגו את מה שחשוב: שדות הטקסונומיה

Salesforce נותנת לכל שדה סט של מטא-דאטה לסיווג. אני קורא להם שדות הטקסונומיה. אפשר לתעד את בעלי הנתונים (data owner); את השימוש בשדה (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 שולחת prompt למודל שפה גדול, היא יכולה להשתמש בדיוק בסיווג הזה כדי למסך שדות רגישים: היא מחליפה את השם של לקוחה, נגיד “Maria Lopez”, בממלא מקום ביציאה, המודל לא רואה את השם אף פעם, והשם מוחזר לתשובה בכניסה (Einstein Trust Layer (opens in a new tab)).

עדכון. Salesforce מתעדת עכשיו שמיסוך מבוסס דפוסים ומבוסס שדות עבור מודלי שפה גדולים מושבת לסוכנים: מיסוך יכול להסיר את ההקשר שסוכן צריך כדי לענות (Data Masking Limitations in Agentforce (opens in a new tab)). הסיווג עדיין מפעיל מיסוך ביכולות AI גנרטיבי אחרות, אבל אל תסמכו עליו כדי להרחיק נתונים אישיים מסוכן; זו החלטת גישה ותכנון (פרק 12).

העמדה שלי: סיווג חשוב ברגעי מפתח. אל תהפכו אותו לשלושה שבועות של מילוי כל תיבה כי ממשל הנתונים אמר כך. השתמשו בו איפה שזה חשוב: נתונים אישיים, נתונים פיננסיים, נתונים מוסדרים, ושדות שבהם העסק צריך בעלים עם שם. הנקודה היא שרגישות מפסיקה להיות ידע בראש של מישהו והופכת לחלק מהשדה.

מעבר למבחן: מה ה-AI משנה. תיעוד שדות גרוע היה מעניש את האדמין הבא. עכשיו הוא מטעה כל כלי AI וכל סוכן שקוראים את הסכמה: האם Flag2__c רגיש, סמכותי, עדיין בשימוש? ה-AI גם יוצר שדות מהר יותר מכל צוות, אז שמות, תיאורים וסיווג הם חלק מהארכיטקטורה, לא עבודות בית.

כל שדה הוא התחייבות

ברגע ששדה נמצא שם ואוסף נתונים, הכול מתחיל להישען עליו. מסכים מציגים אותו, flows מסתעפים לפיו, כללי אימות בודקים אותו, דוחות מקבצים לפיו, אינטגרציות שולחות וקוראות אותו, ועכשיו כלי AI מסיקים מסקנות לגביו. כל אחד מהם מניח הנחות לגבי השדה: הסוג שלו, האורך שלו, האם הוא אי פעם ריק, ומה הערכים שלו אומרים. שנו את השדה בהמשך ותצטרכו למצוא קודם את כל ההנחות האלה. לשנות שם של ערך ברשימת בחירה, לקצר שדה טקסט, או להפוך שדה Text לרשימת בחירה נשמע כמו שינוי קטן, והוא יכול לשבור אינטגרציה במערכת של חברה אחרת. בגלל זה שדה הוא התחייבות.

Click to enlarge

אני לא רוצה שתצאו מהיחידה הזו מפחדים ליצור שדות. Salesforce בנויה כדי שירחיבו אותה; השתמשו בזה. אני רוצה שהשאלה תשתנה מ”איזה סוג שדה לבחור?” ל-”מה הנתונים האלה אומרים, ולאיזו התנהגות אנחנו מתחייבים?” סוג, חובה, ייחודי, External ID, רשימת בחירה, נוסחה, תיאור, סיווג: יחד הם הביטוי הפיזי של המודל הלוגי מפרק 2.

מה הארכיטקט מחליט כאן

• מה הערך אומר לפני שבוחרים את סוג השדה, והאם הוא מאפיין, מזהה, אוצר מילים מבוקר או בעצם ישות אחרת.
• האם ערך הוא חישוב עדכני שאפשר לגזור או עובדה היסטורית שחייבים לאחסן.
• איזו מערכת היא הבעלים של כל מזהה, והאם הייחודיות שלו היא הבטחה עסקית אמיתית.
• מתי ערך חובה באמת ידוע, ומה קורה לרשומות ולאינטגרציות שאין להן אותו.
• איזה תיאור, שם וסיווג השדה צריך, כדי שאנשים, תהליכים ו-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).