בחרו את האובייקט הנכון

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

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

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

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

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

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

אתם בפגישת דרישות ומישהו אומר: “אנחנו צריכים לעקוב אחרי המפיצים שלנו.” אובייקט מותאם אישית חדש: Distributor. סיימנו. אלא שאני רוצה שהארכיטקט ישאל קודם שאלה אחרת: מה זה מפיץ? זו חברה. ל-Salesforce כבר יש דרך די טובה לייצג חברה. קוראים לה חשבון (Account). זה לא אומר שהתשובה היא תמיד חשבון. אבל אם אני צריך להסביר למה חברה היא לא חשבון, אני רוצה סיבה טובה יותר מ”העסק קורא להם מפיצים”.

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

התחילו מהמשמעות

גם כשמשהו ראוי להיות אובייקט, הוא לא אוטומטית ראוי להיות אובייקט מותאם אישית. שאלו מה הדבר באמת מייצג. עסק או ארגון מכל סוג? התחילו בחשבון. אדם שעובד עם הארגון הזה? איש קשר (Contact). משהו שלקוח מחזיק או קנה? נכס (Asset). משהו שאתם מנסים למכור? עכשיו הזדמנות (Opportunity) נכנסת לשיחה.

בגלל זה הבטנו קודם אל ספינת האם, ביחידה 2. המודלים האלה לא מתאימים לכל עסק, אבל לא כדאי להתעלם מהם רק כי לבנות משהו משלנו מרגיש נקי יותר. לפני New Custom Object, שאלו איך Salesforce ממדלת את המושג הזה, מה נבנה סביב המודל הזה, וממה תוותרו אם תחליפו אותו.

מבחן ההתאמה הנקייה

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

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

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

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

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

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

אותו דבר עם תת-בעיות בפנייה. אם כל תת-בעיה היא באמת פנייה, שנציג מטפל בה, עם סטטוס ורמת שירות משלה, קננו אותן עם ה-Parent Case מיחידה 2. אבל אם זה רק פריט ברשימת תיוג שאף אחד לא מטפל בו כפנייה, פנייה מלאה סוחבת הרבה שהיא לעולם לא תשתמש בו, וילד מותאם אישית פשוט עשוי לשקול פחות. לא כי מותאם אישית נקי יותר. כי המשמעות שונה, או שהמשקל לא נכון.

אובייקטים סטנדרטיים מגיעים עם מטען

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

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

נכס הוא דוגמה טובה

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

חשבונות אישיים: מתי האדם הוא החשבון?

ביחידה 2 פגשנו חשבונות אישיים: חשבון ואיש קשר ברשומה אחת, ללקוחות שהם אנשים פרטיים. עכשיו ההחלטה.

העמדה שלי: ב-B2C, קשה להסתדר בלעדיהם. כל כך הרבה מגיע מהקופסה עם חשבונות ואנשי קשר, שהעלות והתקורה שוות את זה. ויש עלות: בערך פי שניים מהאחסון של חשבון עסקי, מתג שאי אפשר לכבות, וחלק מהרישיונות החיצוניים לא יכולים להשתמש בהם. אי אפשר להשתמש ב-Partner Community עם חשבונות אישיים (Experience Cloud User Licenses (opens in a new tab)). אז השאלה היא לא “האם יש לנו אנשים במסד הנתונים?” בכל org יש אנשים. השאלה היא “האם האדם הוא באמת החשבון בעסק הזה?” זה שאיש קשר הוא אדם לא הופך אותו לחשבון אישי. הקשר העסקי הוא שקובע.

Click to enlarge

ועכשיו תנו לי לסבך הכול: רישוי

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

שלושה רישיונות פנימיים

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

Sales Cloud (היום Agentforce Sales). למשתמשים האלה יש את רישיון המשתמש המלא של Salesforce: אובייקטי CRM סטנדרטיים, וכל אפליקציה סטנדרטית או מותאמת אישית. כלומר לידים, הזדמנויות ותחזיות מעבר לחשבונות ואנשי קשר, ואפילו פניות: נציג מכירות יכול לראות את הפניות הפתוחות של לקוח לפני שיחה. ליצירה ולהפעלה של קמפיינים צריך עוד חלק, רישיון התכונה Marketing User.

Service Cloud (היום Agentforce Service). אותו רישיון משתמש של Salesforce, מוגדר לשירות. פניות נמצאות במרכז, ומטופלות ב-Service Console: רישיון התכונה Service Cloud User הוא מה שפותח את Salesforce Console for Service. כאן חיים הסכמי רמת השירות (SLA), דרך ניהול זכאויות ו-milestones, וכאן נכנס Knowledge, שרוב המהדורות קונות כתוספת.

Platform (Salesforce Platform). לאנשים שצריכים את האפליקציות המותאמות אישית שלכם, לא את ה-CRM. הם מקבלים חשבונות, אנשי קשר, דוחות, לוחות מחוונים, מסמכים וכל אפליקציה מותאמת אישית ב-org. מה שהם לא מקבלים: תחזיות, לידים, קמפיינים והזדמנויות. הוא עולה פחות, ובדיוק בגלל זה כל כך הרבה אפליקציות מותאמות אישית גדולות רצות עליו, ובדיוק בגלל זה הוא יכול להפיל את מודל הנתונים שלכם בפח.

	Sales Cloud	Service Cloud	Platform
רישיון משתמש	Salesforce	Salesforce	Salesforce Platform
נבנה בשביל	מכירה	תמיכה בלקוחות	אפליקציות מותאמות אישית
חשבונות, אנשי קשר	כן	כן	כן
לידים, הזדמנויות, תחזיות	כן	כן	לא
פניות	כן, כדי לראות את הפניות של לקוח	במרכז, ב-Service Console	לא
הסכמי רמת שירות	לא	כן, זכאויות ו-milestones	לא
אובייקטים ואפליקציות מותאמים אישית	כן	כן	כן

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

Click to enlarge

כשהרישיון מחליט על האובייקט

הזדמנות היא הנפגעת שנתקלתי בה הכי הרבה. ראיתם את זה בטבלה: משתמשי Platform לא מקבלים אותה (Standard User Licenses (opens in a new tab)), וגם משתמשי Customer Community לא יכולים לעבוד איתה. אז הדרישה נראית כמו הזדמנות, מישהו אומר “בואו נשתמש ב-Opportunity”, ואז אני שואל מי צריך גישה. אם אוכלוסייה גדולה נמצאת על רישיונות Platform או Customer Community, הרישיון הוא כבר לא פרט של רכש. הוא אילוץ ארכיטקטוני, ובדרך כלל הוא דוחף את התכנון לכיוון אובייקט מותאם אישית.

זה עובד גם כלפי מעלה. בכיתה אני שואל: המנכ”ל רוצה לוחות מחוונים יפים; רישיון Sales או Service? משתמש Sales יכול לראות את אובייקטי המכירות ואפילו פניות, אז ללוחות מחוונים של מכירות ולספירת פניות פתוחות, Sales מספיק. אבל ברגע שהמנהל רוצה מדדי SLA (כמה זמן עד שפנייה חורגת מרמת השירות שלה), הנתונים האלה יושבים ב-זכאויות וב-milestones, וניהול זכאויות דורש Agentforce Service, לשעבר Service Cloud (Supported Editions for Service Features (opens in a new tab)). עכשיו אתם משדרגים את הרישיונות של ההנהלה. הקשיבו לדרישה העסקית, ודעו איזה רישיון יושב מתחת לנתונים שהיא צריכה.

האצטדיון

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

אלה הרישיונות החיצוניים, לאנשים מחוץ לחברה: לקוחות ושותפים שמתחברים לאתר Experience Cloud. יש שלושה שאני רוצה שתכירו.

Customer Community: היציע. בנוי למספרים גדולים של משתמשים חיצוניים שצריכים פניות ו-Knowledge: לקוח שבודק מה מצב פניית התמיכה שלו. המושבים עולים בערך חצי, ויכולים ללכת למספרים עצומים של משתמשים. מה מפסידים שם למעלה? דוחות, לוחות מחוונים, ואת טבלת השיתוף: השיתוף מבוסס התפקידים שהדרגות הגבוהות יותר מקבלות. הוא כן עובד עם חשבונות אישיים.

Customer Community Plus: בערך באמצע הדרך למטה. Salesforce מתארת אותו כרישיון למשתמשים חיצוניים שצריכים דוחות, לוחות מחוונים ושיתוף סטנדרטי: לקוח שמנהל את הגישה של אנשים אחרים, או צריך לראות את המספרים שלו.

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

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

כשהרישיון מעצב את המודל

לפעמים הרישיון לא רק בוחר את האובייקט; הוא מכופף את כל המודל. חלק מרישיונות הפלטפורמה מגבילים משתמשים לאפליקציה מותאמת אישית אחת של עד עשרה אובייקטים מותאמים אישית (למשל Lightning Platform – One App; Standard User Licenses (opens in a new tab)).

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

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

אנשים הם כבר לא המשתמשים היחידים

עוד שאלת רישוי אחת נעשתה חשובה: מה עם הדברים שהם לא אנשים? לאינטגרציות יש זהויות. לסוכנים יש זהויות. ל-Salesforce יש עכשיו רישיון Salesforce Integration לאינטגרציות בין מערכות: API בלבד, לא לבני אדם, עם חמישה כלולים בכל org מסוג Enterprise, Unlimited ו-Performance Edition (Standard User Licenses (opens in a new tab)). אז אל תשאלו רק אילו משתמשים צריכים גישה. שאלו אילו זהויות צריכות גישה: אדם, לקוח, שותף, אינטגרציה, סוכן. ואז מה כל אחת מהן צריכה לראות ולעשות.

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

Steve Trucking: אחת קלה ואחת קשה

Steve Trucking עובדת עם שותפים קמעונאיים (Retail Partners). מה זה שותף קמעונאי? עסק. קל: חשבון. אני לא יוצר Retail_Partner__c כי מישהו השתמש במילה “שותף”.

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

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

• האם מושג עסקי מתאים בצורה נקייה למטרה שלשמה נועד אובייקט סטנדרטי, או שהמשמעות או המשקל שלו שונים.
• האם תוויות עסקיות שונות הן ישויות שונות או רק תפקידים שונים של אותה ישות.
• האם כל אדם, משתמש חיצוני, אינטגרציה וסוכן שצריכים את הנתונים יכולים להגיע לאובייקט שנבחר תחת הרישיונות המתוכננים.
• איך האוכלוסייה ודפוס הכניסה (member-based או login-based) מעצבים את הרישיון ואת המודל.
• מתי מגבלת רישיון מצדיקה מודל פחות מאופטימלי, ומה הפשרה הזו עולה בדוחות ובהרשאות.

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

להרחבה

• Salesforce Help, Standard User Licenses (opens in a new tab) (באנגלית, נבדק ב-2026-10-02, נבדק שוב ב-2026-10-12): משתמשי Platform לא זכאים לתחזיות, לידים, קמפיינים והזדמנויות; אפליקציה מותאמת אישית אחת של עד 10 אובייקטים מותאמים אישית; חמישה רישיונות Salesforce Integration בכל org מסוג Enterprise Edition.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (באנגלית, נבדק ב-2026-10-02, נבדק שוב ב-2026-10-12): אי אפשר להשתמש ב-Partner Community עם חשבונות אישיים; Customer Community Plus לדוחות, לוחות מחוונים ושיתוף סטנדרטי; כמה כניסות ביום נספרות כאחת.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab) (באנגלית, נבדק ב-2026-10-02, נבדק שוב ב-2026-10-12): הסכמי רמת שירות (ניהול זכאויות) עם Agentforce Service; Knowledge בעלות נוספת ברוב המהדורות.
• Salesforce Help, Available Feature Licenses (opens in a new tab) (באנגלית, נבדק ב-2026-10-12): Service Cloud User, “גישה ל-Salesforce Console for Service”; Marketing User ליצירה ולניהול של קמפיינים.