התשובה הקצרה

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

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

הכלל הראשון: להתחיל מהאובייקטים הסטנדרטיים

Account, Contact, Lead, Opportunity, Case ו-Product נושאים איתם יכולות שלא מגיעות בחינם לאובייקט מותאם: תהליכי מכירה, Forecasting, Entitlements, Omni-Channel, אפליקציית מובייל, ואינטגרציה מובנית עם מוצרים אחרים בפלטפורמה.

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

מתי כן נדרש אובייקט מותאם

מצבהאם Custom Objectנימוק
חוזה/מנוי עם מחזור חיים משלוכןסטטוסים, חידוש, בעלות ודיווח נפרדים
נכס מותקן אצל לקוחכן (או Asset סטנדרטי)ישות עצמאית עם היסטוריית שירות
"לקוח פוטנציאלי" נוסףלאזהו Lead או Account עם Record Type
מחלקה בארגוןלאנתון על משתמש, לא ישות
שורות תמחור מורכבותתלוילבדוק Quote Line או CPQ לפני בנייה

נרמול מול שיטוח: ההכרעה שמשפיעה על דיווח

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

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

הרשאות הן חלק מהמודל, לא שלב אחריו

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

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

הרחבה בנושא מקורות המידע וסמכות העדכון נמצאת בSource of Truth בארגון, ובנושא ניהול ישויות ליבה בMaster Data Management.

תרחיש: חברת תוכנה שבנתה מודל סביב המחלקות

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

הבנייה מחדש התבססה על Opportunity אחד עם Record Types לתהליכים השונים. אותה הבחנה עסקית נשמרה - מסלולי מכירה שונים, שדות שונים, Page Layouts שונים - אבל ברמת התצורה ולא ברמת המבנה. שינוי ארגוני הבא ידרוש שינוי Record Type, לא מיגרציה.

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

ביצועים ונפח - מה באמת משנה

בעיות ביצועים במודל נתונים מגיעות בעיקר משלושה מקומות: Data Skew (הורה יחיד עם עשרות אלפי ילדים, למשל Account "לקוחות פרטיים"), נוסחאות מקוננות שמחשבות בזמן אמת על פני קשרים, ושיתוף מבוסס Apex Sharing שנוצר בהיקף גדול. כל השלושה ניתנים לזיהוי בשלב התכנון אם שואלים כמה רשומות צפויות תחת כל הורה.

סיכונים נפוצים ופעולות מניעה

סיכוןכיצד הוא נראה בפועלפעולת מניעה
Custom Object מיותריכולות מדף נבנות מחדש ידניתבדיקת Standard Object לפני כל אובייקט חדש
Master-Detail מוקדם מדימחיקות שרשרת ומבנה שלא ניתן לשינוילהתחיל ב-Lookup אם אין צורך ב-Roll-Up
מודל שמשקף ארגוןכל שינוי ארגוני הופך למיגרציהRecord Types במקום אובייקטים
Data Skewנעילות ואטיות בעדכונים המונייםפיזור הורים, בדיקת נפח בתכנון
הרשאות כמחשבה מאוחרתפתרונות עקיפים ונראות רחבה מדימטריצת גישה לכל אובייקט בתכנון

כיצד מודדים הצלחה

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

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

Checklist לפני הקפאת המודל

  • ☐ לכל אובייקט מותאם קיים נימוק במשפט אחד
  • ☐ נבדק Standard Object חלופי לכל ישות
  • ☐ סוג הקשר נבחר במפורש עם נימוק ל-Master-Detail
  • ☐ נפח צפוי לכל הורה נאמד (בדיקת Skew)
  • ☐ מטריצת גישה: בעלים, קורא, משנה, היררכיה
  • ☐ נבדק שכל דוח מרכזי ניתן לבנייה במודל
  • ☐ שדות משוכפלים מתעדכנים אוטומטית בלבד
  • ☐ שינויים ארגוניים צפויים מטופלים בתצורה
  • ☐ קיים ERD מעודכן ומתועד
  • ☐ נקבע מי מאשר שינוי מבנה בהמשך

מקורות מקצועיים