ארכיטקטורת הנתונים של 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)

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

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

מדריך לימוד לפרק 3 בקורס Data Architect. קראו קודם את עשר היחידות; הדף הזה עוזר לכם לבדוק מה נקלט.

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

זה הפרק שבו המודל פוגש את הפלטפורמה, והוא נושא חלק גדול מהמבחן. הוא מזין את שני החלקים הגדולים ביותר, Data Modeling and Database Design ו-Salesforce Data Management, כל אחד מהם רבע מהמבחן. המספרים של הפלטפורמה משתנים: רשימת הבדיקה נותנת את אלה שהיחידות מצטטות, עם התאריך שבו הם נבדקו. למדו בשביל מה כל מגבלה קיימת, ובדקו את המספר העדכני לפני שאתם מסתמכים עליו.

לקראת המבחן

סמנו אותם תוך כדי. כל אחד מקשר למקום שבו הוא נלמד.

DM-1: תכנון מודל הנתונים על הפלטפורמה

• אני יודע ש-Salesforce היא פלטפורמה מונעת מטא-דאטה ומרובת דיירים (multitenant): אובייקט הוא מטא-דאטה, לא טבלה חדשה, וכל אובייקט מקבל את ממשקי ה-API שלו ברגע שהוא קיים. (המטא-דאטה היא תוכנית הבנייה, ה-API שלכם הגיע עם האובייקט)
• אני יודע ש-governor limits (מגבלות הפלטפורמה) קיימות כדי שדייר אחד לא יוכל להשתלט על משאבים משותפים. (אי אפשר להשתלט על המעלית)
• אני יודע לקרוא את מודלי הנתונים הסטנדרטיים: המרת ליד לחשבון, איש קשר והזדמנות; Opportunity Product מצביע על Price Book Entry, שמצביע על Product2; ובצד השירות פנייה, נכס ו-Entitlement. (מודל המכירות, מודל השירות)
• אני יודע מה המסך New Custom Object מחליט: שם רשומה מסוג Text או Auto Number; Object Classification (כש-sharing, Bulk API ו-Streaming API מופעלים זה אובייקט Enterprise Application, כשהם כבויים אובייקט Light Application); ו-Allow Search, כבוי כברירת מחדל. (המסך New Custom Object)
• אני יודע לקרוא שם API: לאובייקטים ולשדות סטנדרטיים אין קידומת או סיומת; אובייקטים ושדות מותאמים אישית מסתיימים ב-__c; חבילה מנוהלת מוסיפה את קידומת ה-namespace שלה (abc__); ושדה שאתם מוסיפים לאובייקט של חבילה מקבל __c אבל אף פעם לא את הקידומת של הספק. (קידומות וסיומות)
• אני יודע להפעיל את מבחן ההתאמה הנקייה על אובייקט סטנדרטי, ואני יודע מתי המשמעות או המשקל מצביעים על אובייקט מותאם אישית. (מבחן ההתאמה הנקייה)
• אני יודע בשביל מה נכס (Asset) וחשבונות אישיים קיימים, שחשבון אישי תופס בערך פי שניים אחסון מחשבון עסקי, ושברגע שחשבונות אישיים מופעלים אי אפשר לכבות אותם. (נכס הוא דוגמה טובה, חשבונות אישיים, מתי האדם הוא החשבון?)
• אני בוחר סוג שדה לפי ההתנהגות שאני צריך (מספר צי הוא לא Number), ואני יודע ש-date/time מאוחסן ב-GMT ומוצג באזור הזמן של כל קורא, ולכן משווים אותו בטווחים, לא בשוויון. (מספר הוא לא תמיד מספר, Date, Date/Time ו-Time)
• אני יודע שטקסט מגיע בשני סוגים: עד 255 תווים על הרשומה (אפשר לאנדקס אותו, ולהשתמש בו כייחודי או כ-External ID), ו-Long או Rich text מעבר לזה, בלי אינדקס, בלי סינון ב-WHERE ובלי נוסחאות. (משפחת הטקסט)
• אני יודע מתי להשתמש בשם (Name) מסוג auto number, ושהוא לא מזהה הרשומה. (האם אדם צריך לזהות את זה?)
• אני יודע איך External ID מאפשר לאינטגרציה לעשות upsert, ולטעון רשומות ילד לפי ה-External ID של ההורה שלהן. (External IDs)
• אני יודע מתי ערך צריך להיות נגזר בנוסחה, ומתי הוא עובדה היסטורית שחייבת להיות מאוחסנת. (מאוחסן או נגזר?)
• אני יודע את ההבדל בין אובייקט צומת לוגי (רעיון המידול: אובייקט שמחבר שני אובייקטים אחרים בקשר רבים-לרבים, עם מאפיינים משלו) לבין אובייקט הצומת של Salesforce (Salesforce Junction Object) (אובייקט מותאם אישית עם שני קשרי master-detail), ושל-Salesforce מתכוונת לשני. (שני הורים לרוחב)
• אני מכיר את הקשר ההיררכי: lookup מיוחד שקיים רק באובייקט User, כמו השדה הסטנדרטי Manager, שלא יכול לחזור לאותו משתמש במישרין או בעקיפין, והוא לא היררכיית התפקידים. (היררכי)
• אני יודע את ההבדל בין lookup לבין master-detail: בעלות, שיתוף, הורה חובה, מחיקה מדורגת, שדות סיכום מצטבר. (Lookup, Master-Detail)
• אני יודע שאי אפשר ליצור master-detail על אובייקט שכבר יש בו נתונים (יוצרים lookup, ממלאים אותו, ממירים), שאפשר לחזור ממנו ל-lookup רק כשאין roll-ups על ה-master, ושצריך Allow reparenting כדי להעביר ילד. (האם הילד יכול להחליף הורים?)
• אני מכיר את הצורה של הפלטפורמה ל-master-detail: עד שלוש רמות detail מותאמות אישית לעומק (lookup יכול לשבור את השרשרת בכל מקום), ושני הורי master-detail לרוחב. באובייקט הצומת של Salesforce, ה-master-detail שנוצר ראשון הוא הראשי (בעלים, מראה, division), השני הוא המשני, והגישה דורשת את שני ההורים: המגביל ביותר מנצח. (שלוש רמות עומק, שני הורים לרוחב)
• אני מכיר את שלוש האפשרויות של lookup כשההורה נמחק: לנקות את השדה (ברירת המחדל), לחסום את המחיקה, או מחיקה מדורגת, שכבויה עד ש-Salesforce מפעילה אותה ועוקפת את השיתוף. (Lookup)
• אני יודע שקשר עצמי חייב להיות lookup, ומכיר את שני המובנים: Parent Account של חשבון ו-Parent Case של פנייה. (קשרים עצמיים)
• אני יודע שחישוב מחדש של roll-up יכול לקחת זמן, ש-roll-up לא יכול להשתמש בנוסחה עם NOW(), TODAY() או הפניה בין אובייקטים, ושלא לבחור master-detail רק כדי לקבל roll-up: שדה מאוחסן שנשמר עדכני על ידי flow או trigger הוא החלופה. (Roll-ups שימושיים, אבל הם לא בחינם)
• אני מכיר את מגבלות הקשרים שהיחידה מצטטת: שני master-details לאובייקט; 40 שדות קשר כברירת מחדל (50 לכל היותר); 25 roll-ups כברירת מחדל (40 לכל היותר). (גם לקשרים יש מגבלות)

DM-2: מודל שמכבד את השיתוף וגדל בקנה מידה

• אני יודע שלילד ב-master-detail אין בעלים ואין טבלת שיתוף משלו: הגישה הולכת אחרי ה-master. (הבעלות מצטרפת לנסיעה)
• אני מכיר את parent-child skew: ההנחיה של Salesforce היא לא יותר מבערך 10,000 ילדים להורה אחד. (שאלת 10,000 הילדים)
• אני מכיר את ownership skew (משתמש אחד שהוא הבעלים של יותר מ-10,000 רשומות של אובייקט) ואת ההנחיה: לפזר את הבעלות, או להשאיר את המשתמש הזה מחוץ להיררכיית התפקידים או לבד בראשה, ומחוץ לקבוצות ציבוריות שכללי שיתוף משתמשים בהן. (בעלות יכולה להפוך לבעיית קנה מידה)
• אני מכיר את טבלת השיתוף: אובייקט השיתוף של אובייקט מותאם אישית הוא Object__Share; לאובייקט detail אין כזה, הגישה שלו מגיעה מה-master; והחלפת בעלים מסירה שיתופים ידניים אבל משאירה שיתוף Apex עם סיבה משלו. (טבלת השיתוף)
• אני יודע להחליט מי הבעלים של רשומות שאינטגרציות וסוכנים יוצרים, לפי השאלה אם הבעלות מניעה את השיתוף. (מי הבעלים של רשומות שמערכות יוצרות?)

DM-4: big objects מול אובייקטים סטנדרטיים ומותאמים אישית

• אני מכיר את שלושת הבתים של נתונים: על הליבה (sObjects, בעבודה יומיומית), בהפניה (מערכת אחרת היא מקור האמת: האובייקטים החיצוניים של Salesforce Connect, __x, או קריאות מותאמות), ובארכיון (על הליבה ב-big objects, __b, או מחוץ לליבה במחסן נתונים). (על הליבה ומחוץ לליבה)
• אני יודע שאובייקטים חיצוניים מבצעים קריאה יוצאת בכל פעם שנוגעים בהם, ולכן זמן התגובה והזמינות של מערכת המקור חשובים. (בהפניה)
• אני מכיר את big objects: נפחים עצומים, שאילתות דרך האינדקס שלהם בהתאמה מדויקת או בטווח, בלי ממשק משתמש או דיווח סטנדרטיים, רק הרשאות אובייקט ושדה, בלי אוטומציה. (בארכיון)
• אני יודע שרוב הרשומות נספרות כבערך 2 KB של אחסון נתונים בלי קשר לשדות, ושקבצים נמדדים בנפרד באחסון הקבצים. (שתי עמודות או מאתיים, קבצים וקבצים מצורפים)

SDM-1: רישיונות והאובייקטים שאנשים יכולים להשתמש בהם

• אני מכיר את שלושת הרישיונות הפנימיים, Sales Cloud, Service Cloud ו-Platform, ומה כל אחד יכול להשתמש בו. (שלושה רישיונות פנימיים)
• אני יודע שרישיונות הם חלק ממודל הנתונים: משתמשי Salesforce Platform לא מקבלים לידים, קמפיינים, הזדמנויות או תחזיות, ומשתמשי Customer Community לא יכולים להשתמש בהזדמנות. (ועכשיו תנו לי לסבך הכול: רישוי)
• אני מכיר את דרגות הרישיונות החיצוניים: Customer Community, Customer Community Plus (דוחות, לוחות מחוונים, שיתוף סטנדרטי), Partner Community (אובייקטי מכירות); ושאי אפשר להשתמש ב-Partner Community עם חשבונות אישיים. (האצטדיון)
• אני מכיר רישוי לפי חבר (member-based) מול רישוי לפי כניסה (login-based), ואיזו אוכלוסייה מתאימה לכל אחד. (איך הם משלמים משנה את התכנון)
• אני יודע שחלק מרישיונות הפלטפורמה מגבילים משתמשים לאפליקציה אחת עם עד עשרה אובייקטים מותאמים אישית, ומכיר את דפוס סוגי הרשומה לעבודה בתוך המגבלה. (כשהרישיון מעצב את המודל)
• אני יודע שהרישיון Salesforce Integration מיועד למשתמשים של מערכת-למערכת, שעובדים רק דרך API. (אנשים הם כבר לא המשתמשים היחידים)
• אני יודע שדיווח SLA דורש entitlements ו-milestones, שדורשים רישיונות Service. (ועכשיו תנו לי לסבך הכול: רישוי)

SDM-2: שמירה על עקביות הנתונים

• אני יודע למקם כלל על השלב הנכון בסולם העקביות: סוג שדה ואוצר מילים, חובה וייחודי, כללי אימות, כללי כפילויות, אוטומציה. (שמירה על עקביות הנתונים)
• אני יודע שרשימת בחירה מוגבלת דוחה ערכים שלא ברשימה, גם דרך ה-API, וקבוצת ערכים גלובלית משתפת רשימה אחת בין שדות (עד 1,000 ערכים). (שלב ראשון)
• אני יודע שדרישה ב-page layout מגנה רק על המסך הזה, לא על הנתונים, ושכללי אימות רצים בכל שמירה. (אימות בממשק הוא לא אימות נתונים, שלב שלישי)
• אני יודע לתחום כלל אימות עם ISNEW() ו-ISCHANGED(), הרשאה מותאמת אישית או תאריך עלייה לאוויר, ולדעת אילו שמירות (כולל כאלה שאני לא שולט בהן, כמו החלפת בעלים באצווה או roll-up) כל בחירה עדיין בודקת. (בעיית הרשומות הישנות)
• אני מכיר כללי התאמה וכללי כפילויות, את המגבלות שהיחידה מצטטת (חמישה כללי כפילויות פעילים לאובייקט, שלושה כללי התאמה לכל אחד), ושהם לא פותרים זיהוי בין מערכות. (שלב רביעי: כללי כפילויות)
• אני יודע שכללי כפילויות לא משווים רשומות שנשמרות באותו רגע, ששמירות דרך API וייבוא נחסמות בלי התראה, ושהשמירה וכל מה שהיא מפעילה מתבטלים יחד כטרנזקציה אחת. (שלב רביעי, הכול או כלום)
• אני יודע ש-Workflow Rules ו-Process Builder כבר לא נתמכים; אוטומציה פירושה Flow או Apex. (שלב חמישי: אוטומציה)

מעבר למבחן

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

• לפלטפורמה יש צורה. תכננו לפלטפורמה שאתם עליה, לא למסד נתונים גנרי.
• הביטו אל ספינת האם. ראו איך Salesforce ממדלת מושג לפני שאתם ממציאים אחד.
• כל אובייקט הוא התחייבות: אחסון, מגבלות, מודל שיתוף, רישיונות ותלויות.
• שאלו איפה הנתונים חיים לפני שאתם בוחרים אובייקט: על הליבה, בהפניה או בארכיון.
• קראו כל שם API ותדעו מי יצר אותו, ומה אתם יכולים לשנות.
• אם אתם לא מעבירים לארכיון היום, האם אי פעם תעבירו?
• בנו אב-טיפוס ל-big objects לפני שאתם מציעים אותם.
• שמות עסקיים שונים לא אומרים אוטומטית אובייקטים שונים.
• שאלו אילו זהויות צריכות את הנתונים: אנשים, לקוחות, שותפים, אינטגרציות וסוכנים.
• כל שדה מקבל תיאור, וסיווג איפה שזה חשוב.
• תארו קודם את ההתנהגות של הקשר; הקונפיגורציה מממשת אותה. אל תעוותו את המודל כדי לקבל יכולת.
• שאלת המחיקה: מה צריך לקרות לילדים אם מישהו מוחק את ההורה?
• בחרו איזו חוליה שוברת את השרשרת: שימו את ה-lookup במקום שבו לילד באמת יש חיים משלו.
• בעלות מהראשי, גישה משניהם: המגביל ביותר מנצח.
• הפרידו בין לא פעיל לבין נעלם, והפכו את תקופת השמירה לכלל עסקי.
• דחפו את הכלל נמוך ככל שהוא שייך באמת, ותנו להיסטוריה לגיטימית מעקף במקום לשכתב אותה.
• התרשים הוא לא הארכיטקטורה. היו מסוגלים לעקוב אחרי כל מבנה חזרה לסיבה עסקית.

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

מונח	בשורה אחת
מונע מטא-דאטה (metadata-driven)	אובייקטים ושדות הם הגדרות שהפלטפורמה קוראת בזמן ריצה, לא טבלאות פיזיות חדשות
ריבוי דיירים (multitenancy)	הרבה ארגונים חולקים את התשתית, כל אחד מבודד, כמו דירות בבניין אחד
Governor limits	מגבלות שמונעות מדייר אחד להשתלט על משאבים משותפים
אובייקט חיצוני	נתונים שמוצגים ב-Salesforce דרך Salesforce Connect, ונשלפים מהמקור שלהם בכל נגיעה
Big object	אחסון לנתונים גדולים מאוד שמשתמשים בהם לעיתים רחוקות, עם שאילתות דרך האינדקס שלהם
חשבון אישי	אדם שמיוצג כחשבון, למודלים של עסק-לצרכן
התאמה נקייה	מושג עסקי שתואם את הייעוד המקורי של אובייקט סטנדרטי
External ID	שדה שמחזיק את המזהה של מערכת אחרת, ומשמש ל-upsert ולהתאמה
Upsert	לעדכן את הרשומה אם היא קיימת, וליצור אותה אם לא
Lookup	קשר שבו לילד יש בעלים וחיים משלו
Master-detail	קשר שבו הילד שייך להורה: בעלים ושיתוף בירושה, מחיקה מדורגת, roll-ups
אובייקט צומת לוגי	רעיון המידול: אובייקט שמחבר שני אובייקטים אחרים בקשר רבים-לרבים ונושא מאפיינים משלו, איך שלא ייבנה
אובייקט הצומת של Salesforce (Salesforce Junction Object)	מה ש-Salesforce מתכוונת אליו ב-”junction object”: אובייקט מותאם אישית עם שני קשרי master-detail
master ראשי ומשני	ה-master-detail שנוצר ראשון באובייקט הצומת של Salesforce (בעלים, מראה, division) והשני (היקף דוחות; הופך לראשי אם הראשון מוסר)
קשר היררכי	lookup מיוחד שקיים רק באובייקט User, כמו Manager, ולא יכול לחזור לאותו משתמש
קידומת namespace	הקידומת של הספק על האובייקטים והשדות של חבילה מנוהלת, כמו abc__Inspection__c
טבלת שיתוף	אובייקט השיתוף (AccountShare, Truck__Share) שמחזיק את רוב השיתוף של רשומה, שורה אחת לכל משתמש או קבוצה, עם הסיבה
שדה סיכום מצטבר (roll-up summary)	שדה על ה-master שסופר, מסכם או מוצא את המינימום או המקסימום של רשומות ה-detail שלו
Data skew	יותר מדי רשומות תחת הורה אחד או בעלים אחד, שגורמות לנעילות ולחישובי שיתוף ארוכים
לפי חבר / לפי כניסה	תשלום לכל משתמש חיצוני, או לכל כניסה בכל חודש
סולם העקביות	השכבות שאוכפות כללי נתונים, מסוג השדה ועד אוטומציה
רשימת בחירה מוגבלת	רשימת בחירה שדוחה כל ערך שלא ברשימה שלה, מכל מקור
סיווג נתונים	מטא-דאטה של שדה לבעלים, שימוש, רגישות וקטגוריית ציות

בדקו את עצמכם

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

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

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

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

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

3. תכנון משתמש בהזדמנות, אבל לרוב האנשים שצריכים את הנתונים יש רישיונות Salesforce Platform או Customer Community. מה עכשיו?

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

4. ה-ERP שולח עדכונים לילה-לילה לחשבונות. איך האינטגרציה צריכה למצוא את הרשומה הנכונה בלי לשלוף מזהי Salesforce?

שמרו את מספר הלקוח של ה-ERP בשדה External ID ועשו עליו upsert: לעדכן אם נמצא, ליצור אם לא. גם רשומות ילד יכולות להצביע על ההורה שלהן לפי ה-External ID שלו. קראו שוב את External IDs.

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

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

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

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

7. אתם מוסיפים כלל אימות, ו-20,000 רשומות ישנות מפרות אותו. משתמש עורך מספר טלפון באחת מהן והשמירה נכשלת. מה הכלל היה צריך לעשות?

לומר מתי לאכוף, לא רק מה חייב להיות נכון: לתחום אותו עם ISNEW() או ISCHANGED() על השדות הרלוונטיים, ולתת לרשומות שקדמו לכלל מעקף מכוון במקום לשכתב את ההיסטוריה שלהן. קראו שוב את בעיית הרשומות הישנות.

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

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

9. לשיבוץ צוות (Crew Assignment) יש קשרי master-detail לצוות (שנוצר ראשון) ולמשאית. סדרן יכול לראות את הצוות אבל לא את המשאית. האם הוא יכול לראות את שיבוץ הצוות?

לא. הצוות הוא הראשי, כך שהוא נותן לשיבוץ את הבעלים והמראה שלו, אבל הגישה דורשת את שני ההורים: הסדרן צריך גישה לצוות וגם למשאית, ברמה שה-Sharing Setting של כל שדה master-detail דורש. המגביל ביותר מנצח. קראו שוב את שני הורים לרוחב.

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

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

להרחבה

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-09-25): הרשימה הרשמית של היעדים והמשקלים שלהם. תמיד בדקו את הגרסה העדכנית לפני שאתם קובעים מועד למבחן.
• בסעיף “להרחבה” של כל יחידה מופיע התיעוד של Salesforce שעליו מבוססות העובדות על הפלטפורמה, עם התאריך שבו הוא נבדק.