תכננו את המודל הפיזי ב-Salesforce

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

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

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

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

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

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

פרוסה אחת, לא כל החברה. טעות שאני רואה ארכיטקטים עושים היא לנסות לפתור את כל הארגון בתרשים אחד. אני רוצה משהו שאפשר לחשוב עליו: שותף קמעונאי (Retail Partner) שולח מניפסט (Manifest), Steve Trucking מספקת את מה שכתוב בו, ואנחנו שומרים את מה שאנחנו צריכים על כל משלוח. ואז מקבלים את ההחלטות הפיזיות אחת אחת. התכנון המלא הוא נקודת הביקורת של חלק 1.

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

פרק 2 עשה את העבודה המושגית: שותף קמעונאי, נמען (Recipient), מניפסט, משלוח (Delivery), פריט משלוח (Delivery Item), סוג העצירה, צוות (Crew), משאית (Truck), מרכז הפצה (Distribution Center), תמונות. נתנו שמות לקשרים ושאלנו מה הם אומרים. לא אחזור על זה. השאלה עכשיו היא איך המושגים האלה חיים ב-Salesforce. עובדה אחת מהתדריך חשובה מיד: Steve Trucking כבר מריצה Field Service לפגישות, לצוותים ולאפליקציה הניידת.

שותף קמעונאי: אל תמציאו חשבון

שותף קמעונאי הוא חברה ש-Steve Trucking עובדת בשבילה. ל-Salesforce כבר יש אובייקט שתוכנן לחברות: חשבון (Account). התאמה נקייה. אז אין Retail_Partner__c רק כי העסק אומר “שותף”. זה חשבון, עם סוג רשומה Retail Partner שמבדיל אותו מארגונים אחרים, ואיתו מגיעים חוזים, פניות, אנשי קשר (Contacts) של מנהלי ה-DC, וגישה לפורטל לאנשי הקשר האלה. החלטה קלה. לא כולן כאלה.

מספר ההזמנה של השותף הוא לא המזהה שלנו

כל שותף קמעונאי שולח הפניות משלו. הזמנה של שותף אחד נראית כמו 8843119, של אחר כמו A-984732. המספרים האלה חשובים, אבל של מי הם? של השותף. ל-Salesforce יש מזהה רשומה משלה, ולשותף יש את ההפניה שבה הוא משתמש כשהוא מדבר איתנו. שניהם יכולים להתקיים; זה ה”דבר אחד, כמה מזהים” מפרק 2.

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

משלוח: הביטו אל ספינת האם

כאן מפתה ליצור Delivery__c. העסק אמר “משלוח”, אז אנחנו צריכים אובייקט Delivery. זה בדיוק מה שאני לא רוצה שתעשו קודם. הביטו אל ספינת האם, כמו שעשינו ביחידה 2. מה כבר יש ל-Salesforce לעבודה שמתבצעת במיקום מסוים, עם מחזור חיים, פריטים, תזמון וצוות בשטח? הזמנת העבודה (Work Order) של Field Service: Salesforce מתארת אותה כעבודת שירות שטח שיש לבצע עבור לקוח (WorkOrder (opens in a new tab)). הביקור המתוזמן וחלון הזמן שלו הם פגישת השירות (Service Appointment), ואותה הסדרנות מתזמנת ואותה רואה הצוות באפליקציה.

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

Click to enlarge

שלב 1 מתוך 4: ספינת האם. כל כרטיס הוא המושג העסקי, ומתחתיו האובייקט שלו ב-Salesforce.

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

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

פריטי משלוח: לכו בעקבות המודל

ברגע שמשלוח הוא הזמנת עבודה, הסתכלו על שאר המודל הזה לפני שאתם ממציאים משהו. פריט בהזמנת עבודה (Work Order Line Item) הוא משימת משנה בהזמנת עבודה (WorkOrderLineItem (opens in a new tab)): המקרר, ההתקנה, פינוי הישן. אז פריט משלוח → פריט בהזמנת עבודה. שימו לב שההחלטה הראשונה עיצבה את השנייה. אנחנו לא בוחרים אובייקט לכל ישות בנפרד. אמצו מודל, והבינו את כל השאר שבו לפני שאתם בונים סביבו מבנים מותאמים אישית.

איזה סוג עצירה זו?

ב-Steve Trucking עצירה היא משלוח בלבד, משלוח עם התקנה, או משלוח עם פינוי, ולכל סוג יש משך זמן משלו, כישורי צוות משלו ורשימת בדיקה משלו להתקנה. בפרק 2 החלטנו שזו ישות, לא תווית. ל-Field Service כבר יש כזו: סוג עבודה (Work Type), תבנית לסוג עבודה שאפשר להחיל על הזמנות עבודה ועל פריטים בהן (WorkType (opens in a new tab)). אז סוג עצירה → סוג עבודה. שוב, לא כי קיים משהו שנקרא Work Type, אלא כי המושג וההתנהגות מתיישרים.

Click to enlarge

שלב 2 מתוך 4: לכו בעקבות המודל. הפריטים ו-Work Type מגיעים יחד עם הזמנת העבודה.

מניפסט: עכשיו אני רוצה אובייקט מותאם אישית

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

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

Click to enlarge

שלב 3 מתוך 4: האובייקט המותאם אישית היחיד, במקום שבו שום אובייקט סטנדרטי לא מתאים.

תמונות: זה ש-Salesforce יכולה לאחסן את זה לא אומר שהיא צריכה

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

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

שדות: הפכו את המשמעות לגלויה

הזמנת העבודה צריכה שדות: ההפניה של השותף, חלון המשלוח, זמן המשלוח בפועל, סטטוס, הערות כמו “קוד לשער” או “כלב בחצר”. לא אהפוך את זה לקטלוג שדות; יחידה 6 עשתה את זה. העבירו כל שדה דרך השאלות: מה הוא אומר, מי הבעלים שלו, האם הוא משתנה, האם הוא מזהה, אוצר מילים מבוקר, מאוחסן או נגזר, רגיש. ההפניה של השותף היא ה-External ID, אז הייחודיות שלה היא חלק מחוזה האינטגרציה, לא סתם תיבת סימון. זמן המשלוח בפועל הוא רגע, אז Date/Time. הסטטוס מניע התנהגות, אז רשימה מבוקרת, אף פעם לא טקסט חופשי. והערות משלוח על הבית של אדם הן מידע אישי, אז הן מסווגות. כל שדה מוביל חזרה למשמעות.

קשרים: אל תחברו סתם את הקופסאות

חשבון להזמנת עבודה, הזמנת עבודה לפריטים שלה, מניפסט להזמנת עבודה, סוג עבודה שמתאר את העצירה. ואז השאלות של יחידה 7 לכל קו: האם הילד יכול להתקיים לבד, מי הבעלים שלו, האם הגישה עוברת בירושה, האם הוא יכול לזוז, מה קורה במחיקה, כמה ילדים יכולים להיערם? כל הזמנות העבודה תחת קומץ חשבונות של שותפים קמעונאיים פירושן מאות אלפי ילדים להורה: שאלת skew שנענה עליה בחלק 2. ובקשרים הסטנדרטיים של Field Service, בדקו איך Salesforce כבר בנתה אותם במקום להניח שהם תואמים את מה שאנחנו היינו מתכננים. כשאתם מאמצים מודל סטנדרטי, אתם מאמצים את ההחלטות ש-Salesforce קיבלה בתוכו. הבינו אותן לפני שאתם בונים מעליהן.

הבעלות והנמען: אל תתנו לברירת המחדל להחליט

שתי החלטות שברירת מחדל הייתה שמחה לקבל בשבילנו.

מי הבעלים של משלוח? ענינו על זה ביחידה 8, וזה עובר ישירות להזמנת העבודה: הבעלות לא קובעת כאן את הגישה של אף אחד, אז משתמש האינטגרציה הוא הבעלים של הזמנות העבודה שהוא יוצר. סדרנים רואים את אלה של מרכז ההפצה שלהם, צוותים רואים את אלה של המסלולים שלהם, וכל שותף קמעונאי רואה את שלו דרך הפורטל, הכול דרך שיתוף, לא דרך בעלות. למשתמש האינטגרציה אין תפקיד, והוא נשאר מחוץ לקבוצות הציבוריות שכללי השיתוף שלנו משתמשים בהן, כי ב-3,300 ביום הוא עובר את 10,000 הרשומות בתוך שלושה ימים. ואנחנו כותבים מה קורה אם המשתמש הזה יוחלף אי פעם.

מה הוא הנמען? איש קשר? חשבון אישי? משהו שנשמר רק על המשלוח? זה תלוי בשאלה אם בכלל יש ל-Steve Trucking קשר עם האנשים האלה (הם הלקוחות של השותפים הקמעונאיים), אם שותף אחד יוכל אי פעם לראות את הנמענים של אחר, כמה זמן מותר לשמור את המידע האישי שלהם, ובקנה המידה: בערך מיליון נמענים חדשים בשנה. עוד אין לנו את כל זה, וזה בסדר. לפעמים התשובה הנכונה היא אנחנו עוד לא יודעים מספיק. כתבו את השאלה ולכו להשיג את המידע; אל תקברו את חוסר הוודאות באובייקט מותאם אישית. נענה עליה בנקודת הביקורת של חלק 1, אחרי שפרקים 4 עד 6 ייתנו לנו את התמונה של הארגון ושל נתוני האב.

עקביות: הגנו על המודל בשכבה הנכונה

הסולם של יחידה 9 חל כאן: ההפניה של השותף היא External ID, ייחודי, כך שמניפסט שנשלח שוב עושה upsert במקום ליצור כפילות; הסטטוס הוא רשימה מוגבלת; זמן המשלוח בפועל הוא חובה רק כשהסטטוס אומר Delivered; עצירת התקנה לא יכולה להיסגר בלי רשימת הבדיקה והתמונות שלה. לא flow ענק אחד. כל כלל על השלב שלו בסולם.

איפה כל חלק חי

עוד מעבר אחד על הפרוסה, עם השאלה של יחידה 4: איפה כל פיסת נתונים חיה? במצגת שלי בכיתה זו שקופית אחת, הלוגי מול הפיזי: הישויות הלוגיות מפרק 2, ואיפה כל אחת נוחתת פיזית: על הליבה, כ-sObject (__c אם הוא מותאם אישית) או כ-big object (__b), או מחוץ לליבה, כאובייקט חיצוני (__x) או כנתונים שאף פעם לא נכנסים ל-Salesforce בכלל.

• על הליבה, בעבודה יומיומית: החשבון, הזמנות העבודה והפריטים שלהן, פגישות השירות, סוגי העבודה, Manifest__c.
• על הליבה, בארכיון: משלוחים בני יותר משלוש שנים עוברים ל-Delivery History, big object, עדיין שם בשביל תביעות, במחסן שבחצר.
• בהפניה: פרטי ההזמנה של השותף הקמעונאי נשארים במערכת של השותף; אנחנו שומרים את ההפניה של השותף כ-External ID, ומגיעים לשאר דרך אובייקט חיצוני או דרך האינטגרציה כשמישהו צריך.
• מחוץ לליבה: התמונות, באחסון שנבנה למיליוני תמונות, עם קישור מהזמנת העבודה.

זה המודל הפיזי: לא רק איזה אובייקט, אלא איזה בית.

עכשיו הסתכלו על הפרוסה כולה

• שותף קמעונאי → חשבון, עם סוג רשומה Retail Partner; מנהלי ה-DC כאנשי קשר.
• משלוח → הזמנת עבודה של Field Service, שמתוזמנת דרך פגישת שירות.
• פריט משלוח → פריט בהזמנת עבודה.
• סוג עצירה → סוג עבודה.
• מניפסט → האובייקט המותאם אישית Manifest__c.
• הפניית השותף → External ID בהזמנת העבודה, ייחודי לכל שותף.
• תמונות → מאוחסנות מחוץ לליבה; Salesforce שומרת את ההפניה ואת דגל השלמות.
• היסטוריית משלוחים → מועברת לארכיון ב-big object אחרי שלוש שנים.
• בעלות → משתמש האינטגרציה, עם גישה דרך שיתוף (יחידה 8).
• נמען → פתוח, לנקודת הביקורת של חלק 1.

Click to enlarge

שלב 4 מתוך 4: הפרוסה כולה, על הליבה, בארכיון ומחוץ לליבה. כל קו הוא lookup: Salesforce בנתה את Field Service על קשרי lookup, ואנחנו מאמצים את ההחלטות שלה יחד איתו.

התרשים הוא לא הארכיטקטורה

אני יכול לתת לכם את התרשים הזה, וזה לא מספיק. הארכיטקטורה היא הנימוק שמאחוריו. למה חשבון? חברה בהתאמה נקייה. למה הזמנת עבודה ולא Delivery__c? המשלוח מתנהג כמו עבודת שטח, ו-Field Service כבר קיים. למה מניפסט מותאם אישית? אין לו בית סטנדרטי נקי. למה התמונות הן לא פשוט Files? נפח וכלכלת אחסון. למה External ID? מערכת אחרת צריכה מזהה יציב מעבר לגבול. למה משתמש האינטגרציה הוא הבעלים של הזמנות העבודה? הבעלות לא קובעת כאן גישה, וזה שומר על מסלול הביקורת הוגן. למה הנמען עדיין פתוח? עוד לא ענינו על מספיק שאלות. הקווים הם התוצר; ההחלטות הן שיצרו אותם.

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

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

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

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

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

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

להרחבה

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) ו-WorkType (opens in a new tab) (באנגלית, נבדק ב-2026-10-02).
• התדריך של Steve Trucking.