בעלות ומחזור חיים

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

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

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

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

השאלה שהיחידה הזו עונה עליה: מי הבעלים של הרשומה, ומה קורה לה לאורך כל חייה?

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

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

אדמינים רואים Owner ברשומה וקוראים אותו כתווית: Bart הבעלים של החשבון הזה, Lisa הבעלים של הפנייה ההיא. זה יכול לומר את זה. אבל ב-Salesforce, בעלות היא גם מנגנון של הפלטפורמה. באובייקטים שיש להם בעלים, הבעלים קובע מי יכול לראות את הרשומה דרך היררכיית התפקידים, כללי שיתוף, תורים והעברת בעלות. אז כשאני שואל “מי הבעלים של הרשומה הזו?” אני לא שואל של מי השם שמופיע בעמוד. אני שואל איזו התנהגות של אבטחה ושל מחזור חיים אנחנו מצמידים אליה. הבעלים יכול להיות משתמש, או בחלק מהאובייקטים, ביניהם אובייקטים מותאמים אישית, פניות ולידים, תור, ובכל מקרה הבעלים מקבל גישה מלאה לרשומה (Understanding Sharing (opens in a new tab)).

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

טבלת השיתוף: איפה שבעלות הופכת לגישה

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

רוב השיתוף של רשומה נשמר באובייקט שיתוף (share object) קשור, הגרסה של Salesforce לרשימת בקרת גישה (Understanding Sharing (opens in a new tab)). ל-Account יש AccountShare, ל-Contact יש ContactShare, ואובייקט מותאם אישית מקבל אחד משלו: ל-Truck__c יש Truck__Share (Sharing a Record Using Apex (opens in a new tab)). כל שורה בו אומרת ארבעה דברים:

• איזו רשומה: מזהה ההורה.
• מי: משתמש, או קבוצה (קבוצה ציבורית, הקבוצה של תפקיד, טריטוריה).
• כמה: Read, Edit, או All (גישה מלאה).
• למה: סיבת השורה (row cause). Owner לבעלים, Rule לכלל שיתוף, Manual לשיתוף ידני, Team, הסיבות המשתמעות ש-Salesforce מוסיפה בין חשבון לילדים שלו, וסיבות שמפתח מגדיר עבור שיתוף ב-Apex.

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

אבל לא הכול נמצא בה. ברירת המחדל הארגונית (organization-wide default) היא לא שורה. גם היררכיית התפקידים לא מאוחסנת שם: הגישה של האנשים שמעל הבעלים מחושבת כשצריך אותה. ו-View All, Modify All, View All Data ו-Modify All Data מדלגים לגמרי על טבלת השיתוף (Sharing a Record Using Apex (opens in a new tab)). כמו שאני אומר בכיתה: סמנו View All ועקפתם את טבלת השיתוף.

Salesforce גם משתפת חלק מהרשומות בשבילכם, בגלל האופן שבו הן קשורות. זה שיתוף משתמע (implicit sharing), והוא עובד בין חשבון לילדים שלו. אם אתם יכולים לראות איש קשר, פנייה או הזדמנות, אתם יכולים גם לקרוא את החשבון שהם שייכים לו. ובעלי החשבון מקבלים גישה לאנשי הקשר, לפניות ולהזדמנויות של החשבון, ברמה שנקבעת לפי התפקיד של הבעלים (Implicit Sharing (opens in a new tab)). בגרסאות האחרונות Salesforce מחשבת חלק מהגישה הזו לילדים כשצריך אותה במקום לאחסן אותה כשורות, אז אל תופתעו כששאילתה על טבלת השיתוף לא מראה אותה. אני רק נותן לכם רמז כאן; הפרטים נמצאים בקשרים ושיתוף מובנה.

עוד חריג אחד, למצב שבו יש לכם הרבה משתמשים חיצוניים. משתמשי קהילה בנפח גבוה (high-volume community users), רישיונות Customer Community שנבנו לאלפים עד מיליוני לקוחות, הם בלי תפקיד, לא יכולים להיות בקבוצות ציבוריות, ואי אפשר לתת להם רשומות דרך כללי שיתוף או שיתופים ידניים (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). עבורם, טבלת השיתוף היא לא התשובה: הם מגיעים לרשומות דרך sharing sets, שמתאימים את החשבון או איש הקשר של רשומה לאלה של המשתמש עצמו. זו אחת הסיבות שהרישיונות האלה מתאימים לקנה מידה גדול. הקורס Sharing and Visibility מכסה את זה בשיתוף עם משתמשים חיצוניים.

וזכרו את יחידה 7: לאובייקט detail אין אובייקט שיתוף בכלל. הגישה אליו מגיעה מאובייקט השיתוף של ה-master ומה-Sharing Setting בשדה ה-master-detail.

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

ידע למבחן. אובייקט השיתוף של אובייקט מותאם אישית נקרא Object__Share, כמו Truck__Share. לאובייקט detail אין אובייקט שיתוף: הגישה אליו מגיעה מה-master. וכשהבעלים של רשומה מתחלף, השיתופים הידניים שלה מוסרים, בזמן ששיתוף ב-Apex עם סיבה שהמפתח הגדיר נשאר.

כאן מודל הנתונים מעביר את המקל למודל האבטחה, ואת השאר אני מלמד בקורס Sharing and Visibility Architect: 22 הדרכים של Steve לשתף רשומה, Org-Wide Defaults, בעלות, תורים והיררכיית התפקידים, קשרים ושיתוף מובנה לשיתופים המשתמעים, ו-שיתוף מתוכנת וקוד מאובטח לסיבות שיתוף ב-Apex. בקורס הזה, פרק 12 מחבר את הכול עבור בני אדם, אפליקציות וסוכנים.

לפעמים הבעלות עוברת בירושה

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

מי הבעלים של רשומות שמערכות יוצרות?

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

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

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

בעלות יכולה להפוך לבעיית קנה מידה

גם ההתפלגות חשובה. עשרה מיליון רשומות שמפוזרות בין אלפי בעלים זו צורה אחת. עשרה מיליון רשומות בבעלות משתמש אחד זו צורה שונה מאוד. Salesforce קוראת לזה ownership data skew (הטיית בעלות) כשמשתמש יחיד הוא הבעלים של יותר מ-10,000 רשומות של אובייקט (Ownership Data Skew (opens in a new tab)). זה קורה בדרך כלל כשמישהו מחנה הכול על משתמש או תור אחד: כל הלידים שלא שובצו על משתמש ממלא מקום, כל רשומת אינטגרציה על משתמש האינטגרציה. זה לא מזיק עד שהמשתמש הזה זז בהיררכיית התפקידים, או נכנס או יוצא מקבוצה שכלל שיתוף תלוי בה. ואז Salesforce צריכה לעדכן מספר עצום של רשומות שיתוף, ומקבלים חישובים מחדש שרצים הרבה זמן.

ההנחיה מעשית. פזרו את הבעלות בין יותר משתמשים איפה שאפשר. אם משתמש אחד חייב להיות הבעלים של הרבה, השאירו אותו מחוץ להיררכיית התפקידים; אם הוא צריך תפקיד, שימו אותו בתפקיד משלו בראש ואל תזיזו אותו, והשאירו אותו מחוץ לקבוצות ציבוריות שכללי שיתוף משתמשים בהן (Ownership Data Skew (opens in a new tab)). אותה חשיבה חלה על ההורה עם יותר מדי ילדים מהיחידה הקודמת, parent-child skew.

אז ההתפלגות היא חלק מהמודל הפיזי. אל תשאלו רק כמה רשומות; שאלו איך הן מתפלגות. זו עוד גרסה של “מספר האפסים”: לא רק כמה אפסים, אלא איפה האפסים מרוכזים. חלק 2 נכנס לעומק ה-skew; כאן אני רוצה שתראו אותו מגיע. הקורס Sharing and Visibility חוזר אליו בשיתוף בקנה מידה.

“בעלי ברירת המחדל” הופכים לארכיטקטורה

הנה דפוס שאני רואה כל הזמן. אף אחד לא יודע מי צריך להיות הבעלים של משהו, אז מישהו אומר: “פשוט תקצו את כולן למשתמש האינטגרציה”, או “צרו משתמש גנרי בשם System”. אולי זה נכון. אבל אל תעשו את זה בטעות. לברירת מחדל זמנית יש נטייה להפוך לקבועה: שנתיים אחר כך כל רשומה שייכת ל-integration@company.com, אף אחד לא זוכר למה, ולשנות את זה זה פרויקט. זה מבחן ההפיכות מפרק 1: לפני שאתם נותנים מיליון רשומות לבעלים אחד, שאלו מה יידרש כדי לשנות את זה בהמשך.

העברת בעלות היא אירוע במחזור החיים

בעלים מתחלפים. נציגים עוזבים, טריטוריות זזות, צוותים מתארגנים מחדש, אזורים מאוזנים מחדש. מה תלוי בבעלים: שיתוף, אוטומציה, דוחות, תורים, הסלמות, אינטגרציות? אם החלפת הבעלים משנה מי יכול לראות את הרשומה, העברת בעלות היא לא ניקיון של אדמין. היא אירוע אבטחה, ובמיליון רשומות היא גם אירוע תפעולי. שימו עין על טבלת השיתוף כשזה קורה: שיתופים ידניים מוסרים כשהבעלים מתחלף, בזמן ששיתוף ב-Apex עם סיבה שהמפתח הגדיר שורד את השינוי (Understanding Sharing (opens in a new tab)). בכיתה אני משתף רשומה עם מישהו, מחליף את הבעלים, והאדם מאבד גישה. הכיתה תמיד מופתעת.

וזכרו שבעלות היא לא אותו דבר כמו גישה. הבעלים הוא לא האדם היחיד שצריך לראות רשומה, ול-Salesforce יש הרבה דרכים להעניק גישה: היררכיית התפקידים, כללי שיתוף, צוותים, טריטוריות, שיתוף ידני ושיתוף תכנותי. הקורס Sharing and Visibility נכנס אליהם לעומק, החל מ22 הדרכים של Steve לשתף רשומה. הנקודה של הארכיטקט פשוטה יותר: אל תשתמשו בבעלות כדי לפתור כל בעיית גישה. אם אתם מזיזים בעלים רק כדי שמישהו יוכל לראות רשומה, כנראה שאתם פותרים את הבעיה הלא נכונה.

היצירה היא רק ההתחלה

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

Click to enlarge

אל תמחקו רק כי משהו ישן

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

תקופת שמירה היא דרישה עסקית

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

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

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

Steve Trucking: מי הבעלים של משלוח?

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

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

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

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

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

מעבר למבחן: מה ה-AI משנה. סוכנים יוצרים ומשנים רשומות במהירות של מכונה. אם סוכן יוצר 100,000 רשומות תחת המשתמש שלו, “נתקן את הבעלים אחר כך” הופך ל-skew, לחישוב מחדש של שיתוף ולפרויקט ניקיון. החליטו על כלל הבעלות של הסוכן לפני שהוא עולה לאוויר, עם אותה שאלה: האם הבעלות חשובה לשיתוף כאן?

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

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

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

להרחבה

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (באנגלית, נבדק ב-2026-10-13): בעלים (משתמש, או תור לאובייקטים מותאמים אישית, פניות ולידים) מקבלים גישה מלאה; רוב השיתוף חי באובייקט שיתוף קשור; היררכיית התפקידים נגזרת בזמן ריצה; שיתופים ידניים מוסרים כשהבעלים מתחלף, שיתוף מנוהל ב-Apex נשמר; ערכי סיבת השורה.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (באנגלית, נבדק ב-2026-10-13): AccountShare, MyCustomObject__Share; לאובייקטי detail אין אובייקט שיתוף; מה אובייקט השיתוף לא עוקב אחריו (OWD, היררכיית התפקידים, View All ו-Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab) (באנגלית, נבדק ב-2026-10-13): גישה בין חשבון לבין אנשי הקשר, הפניות וההזדמנויות שלו.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) ו-Sharing Rule Considerations (opens in a new tab) (באנגלית, נבדק ב-2026-10-13): בלי תפקידים, בלי כללי שיתוף או שיתופים ידניים; sharing sets במקום.
• הקורס Sharing and Visibility Architect: 22 הדרכים של Steve לשתף רשומה, Org-Wide Defaults, בעלות, תורים והיררכיית התפקידים, קשרים ושיתוף מובנה, שיתוף מתוכנת וקוד מאובטח, שיתוף עם משתמשים חיצוניים, שיתוף בקנה מידה.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) ו-Parent-Child Data Skew (opens in a new tab) (באנגלית, נבדק ב-2026-10-02).