שמירה על עקביות הנתונים

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

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

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

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

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

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

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

שלב ראשון: סוג השדה ואוצר המילים

כלל העקביות הראשון הוא זה מיחידה 6: בחרו את הסוג הנכון. תאריך הוא Date, רגע הוא Date/Time, כסף הוא Currency. זו עקביות עוד לפני שמישהו כותב כלל.

הפכו את הסטטוס של משלוח לשדה טקסט ותקבלו Delivered, delivered, DELIVERED, Complete, Done ו-Dropped off, ומישהו יצטרך להבין אם השישה האלה אומרים אותו דבר. או הגדירו את אוצר המילים פעם אחת: Delivered, ערך אחד, משמעות אחת. הפכו אותו לרשימת בחירה מוגבלת כדי שתדחה כל דבר שלא ברשימה, גם דרך ה-API, ולקבוצת ערכים גלובלית כשכמה שדות חולקים את הרשימה (ביחידה 6 יש את הפרטים).

אבל אל תשתמשו ברשימת בחירה רק כדי למנוע מאנשים להקליד. האם זה באמת ערך, או ישות אחרת? תשעה מרכזי הפצה עם שם לכל אחד יכולים להיראות כמו רשימת בחירה; תשעה עם כתובות, מנהלים, קיבולת ומשאיות הם רשומות. הכלל צריך לחזק את המודל, לא לפצות על מודל גרוע. ואם זה באמת אוצר מילים מבוקר, שלטו בו בשדה. אל תאפשרו כאוס ואז תבנו flow שיהפוך את AZ, Arizona, Ariz ו-Phoenix area לערך שרציתם מלכתחילה.

שלב שני: חובה וייחודי

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

אבל ברגע שהפלטפורמה אוכפת כלל, לא אכפת לה שלתהליך שלכם יש חריג ביום שלישי אחר הצהריים. אני משתמש בדוגמה הזו בכיתה כבר שנים. אובייקט קיים כבר זמן מה, עם הרבה רשומות. מישהו מוסיף שדה ומסמן Required. הוא בודק יצירת רשומה: עובד נהדר. ואז מוצאי שבת, פריסה, הבדיקות רצות, ו-test class ישן יוצר את האובייקט בלי השדה החדש. בום. או שמישהו עורך רשומה ישנה מלפני שהשדה היה קיים. או שהאינטגרציה שולחת את אותו payload שהיא שולחת כבר חמש שנים. בום. “אבל לא שינינו את השדה הזה.” לפלטפורמה לא אכפת: שיניתם את החוזה של מה זו רשומה תקינה. כלל חדש לא משפיע רק על נתונים חדשים; הוא משנה את מה שאפשר לעשות עם הנתונים הישנים.

שלב שלישי: כללי אימות

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

יש להם גם שיניים. זה הכוח שלהם וזה המחיר שלהם.

בעיית הרשומות הישנות

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

אז כלל אימות לא צריך לומר רק מה חייב להיות נכון. הוא צריך לומר מתי לאכוף את זה. פונקציות כמו ISNEW() ו-ISCHANGED() מאפשרות להגביל כלל לרשומות חדשות, או לשמירות שבהן השדות הרלוונטיים באמת משתנים (Validation Rule Considerations (opens in a new tab)).

אבל רשומה לא משתנה רק כשאדם עורך אותה, והרבה מהסיבות לא בשליטתכם. האינטגרציה מעדכנת את הסטטוס בלילה. Flow מטביע תאריך. מנהל מעביר טריטוריה והבעלים מתחלף בעשרת אלפים רשומות. מישהו עורך פריט משלוח, ה-roll-up על המשלוח מחושב מחדש, וזה שומר את המשלוח, כך שכלל האימות של המשלוח יורה על משתמש שמעולם לא נגע בו (Roll-Up Summary Field (opens in a new tab) מזהיר ששגיאות אימות יכולות להופיע ב-detail או ב-master). כל אחת מהשמירות האלה פוגשת את הכלל החדש שלכם. אז לכל כלל חדש, שאלו: האם הכלל הזה צריך לחול על השמירה ההיא?

אלה האפשרויות, ואתם שוזרים אותן לתוך הכלל:

• תמיד, בכל שמירה. נכון כשהכלל באמת עוסק ברשומה והנתונים הישנים עוברים אותו. אבל דעו מה “כל שמירה” אומר: משימת batch שרק מחליפה את הבעלים, או כל עריכה קטנה של כל שדה בכל מקום ברשומה, צריכות לעבור אותו גם.
• רק לרשומות חדשות, עם ISNEW(). הכלל בודק את הרשומה פעם אחת, כשהיא נוצרת, ואף פעם לא שוב. העבר נשאר כפי שהיה, אבל גם העתיד: עריכה מאוחרת יותר יכולה לגרום לרשומה חדשה לשבור את הכלל ואף אחד לא יעצור את זה. אם זה חשוב, שלבו את זה עם האפשרות הבאה.
• רק כשהשדות שהוא עוסק בהם משתנים, עם ISCHANGED(). עריכת מספר הטלפון לא מעירה את כלל זמן המסירה.
• לא עבור כותבים מסוימים. הרשאה מותאמת אישית (custom permission), שנבדקת בנוסחה כ-$Permission, מאפשרת למשתמש האינטגרציה או למיגרציית נתונים לעבור בזמן שאנשים עדיין פוגשים את הכלל (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). תנו אותה בכוונה ולמעטים.
• מתאריך מסוים והלאה, בהשוואה של CreatedDate ליום שבו הכלל עלה לאוויר, כש”חדש” אומר “מאז שהתחלנו לאכוף את זה”. בניגוד ל-ISNEW(), זה ממשיך לבדוק את הרשומות האלה בכל שמירה מאוחרת יותר, כך שאותה אזהרה חלה: שינוי קטן, כמו עדכון בעלים ב-batch, יכול להיכשל על רשומה שסטתה.

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

אל תשכתבו את ההיסטוריה כדי לרצות את הכלל

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

אימות בממשק הוא לא אימות נתונים

הפכו שדה לחובה ב-page layout ומשתמשים לא יכולים לשמור בלעדיו. ואז האינטגרציה הלילית מכניסה 50,000 רשומות. האם היא השתמשה בעמוד שלכם? לא. גם לא הטעינה ההמונית, לקוח ה-API או הסוכן. דרישה בממשק מגינה על המסך הזה, לא על הנתונים. אפשר לעקוף באותה צורה גם אימות שדות ב-dynamic forms. אז שאלו: מאיפה הנתונים האלה יכולים להיכנס? Lightning, הפורטל, מובייל, האינטגרציה, ה-API, טעינה המונית, Flow, Apex, סוכן. ככל שיש יותר דלתות, כך אני סומך פחות על כלל ששומר רק על אחת מהן.

שלב רביעי: כללי כפילויות

עכשיו אנחנו עוברים מעקביות בתוך רשומה לעקביות בין רשומות. Acme Corporation, ACME Corp, Acme Inc.: ארבעה לקוחות או אחד? אף כלל שדה לא יכול לענות על זה. כללי התאמה (matching rules) מגדירים איך משווים רשומות; כללי כפילויות (duplicate rules) מחליטים מה קורה כשנמצאת כפילות סבירה: לאפשר עם אזהרה, לחסום, או לדווח. אפשר לקבוע עד חמישה כללי כפילויות פעילים לאובייקט ועד שלושה כללי התאמה בכל אחד, ומפתחות התאמה מצמצמים כל השוואה ל-100 הכפילויות הסבירות ביותר (Things to Know About Duplicate Rules (opens in a new tab)).

המחיר שלהם הוא חיכוך. אם כל חשבון שנציג יוצר אומר Possible duplicate found, לפעמים זה בדיוק מה שרוצים, ולפעמים אנשים לומדים ללחוץ הלאה בלי לקרוא. רשומות לגיטימיות יכולות להיראות דומות, ואינטגרציה עשויה להזדקק להתנהגות שונה מזו של אדם. והאזהרה היא של Salesforce עצמה: ההתראה שלה ורשימת הכפילויות האפשריות שלה עלולות לא להשתלב במסך מותאם אישית שבניתם, וכשהשמירה היא headless (בלי ממשק), אינטגרציה, טעינת נתונים, סוכן, אין בכלל מסך להציג אותה עליו. אז החליטו איך כפילות צפה בכל נתיב: אזהרה לאדם, שמירה חסומה ושגיאה ל-API, או האפשרות Report ו-duplicate record sets שמישהו יבדוק מאוחר יותר. ארכיטקטורה טובה היא לא אכיפה מקסימלית; היא האכיפה הנכונה.

ובדקו על אילו דלתות כלל כפילויות באמת שומר (Things to Know About Duplicate Rules (opens in a new tab)). דרך ה-API וכלי ייבוא הנתונים, אף אחד לא רואה את האזהרה: כלל שמוגדר להתריע פשוט חוסם את השמירה. יש נתיבים שמדלגים על הכללים לגמרי: Quick Create, הכפתור Undelete, מיזוג ידני, רשומות שנוספו על ידי Lightning Sync או Einstein Activity Capture. ורשומות שנשמרות באותו רגע לא מושוות זו לזו, רק לרשומות שכבר נמצאות ב-Salesforce. טענו קובץ שאותו לקוח מופיע בו פעמיים, ושתי השורות יכולות לעבור. כלל כפילויות הוא רשת טובה. הוא לא מנעול על הדלת.

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

גבול אחד. כללי כפילויות שומרים על org אחד נקי. הם לא פותרים זהות ברמת הארגון. אם ב-Salesforce יש Acme Corporation, ב-ERP יש ACME-10382 ובמערכת החיוב יש לקוח 77193, כלל כפילויות לא יכול להגיד לכם שזו אותה חברה. אלה נתוני אב, פרק 6.

שלב חמישי: אוטומציה

יש כללים שמורכבים מדי לשלבים הנמוכים: הם צריכים רשומות קשורות, מערכת אחרת, רשומות תלויות, תהליך רב-שלבי. זה Flow, Apex, לפעמים לוגיקת אינטגרציה. (לא Workflow Rules או Process Builder; התמיכה בהם הסתיימה.) אוטומציה היא חזקה ויקרה יותר: יותר חלקים נעים, יותר בדיקות, יותר טיפול בשגיאות, יותר דרכים שבהן אוטומציה אחת נתקלת באחרת. וקוד מביא שגיאות משלו. אם סוג השדה יכול לאכוף את זה, אני לא כותב Apex. אם כלל אימות אומר את זה בבהירות, אני לא בונה flow רק כי Flow קיים. אל תפתרו בעיה של שדה עם מנוע תהליכים.

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

עד כאן כל שלב מגן על שמירה אחת. אבל רשומות משתנות יחד: משלוח והפריטים שלו, הזמנה והשורות שלה, flow שמעדכן שלושה אובייקטים. כאן הפלטפורמה נותנת לכם הבטחה חזקה. שמירה וכל מה שהיא מפעילה, ה-triggers, ה-flows, המחלקות שהם קוראים להן, רצים כטרנזקציה אחת: אם חלק כלשהו נכשל, הכול מתגלגל אחורה ושום דבר לא נשמר (Apex Transactions (opens in a new tab)). לא מקבלים חצי משלוח.

עבודה המונית היא החריג שאתם בוחרים. טעינת נתונים או מתודת Database ב-Apex יכולות לאפשר הצלחה חלקית: הרשומות הטובות נשמרות, הרעות חוזרות עם השגיאות שלהן, ומישהו צריך לטפל בהן (DML Statements vs. Database Class Methods (opens in a new tab)). זה לעיתים קרובות נכון לטעינה של מיליון שורות, אבל אז עקביות היא תהליך: מי קורא את קובץ השגיאות, ומה קורה לרשומות שנכשלו?

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

דחפו את הכלל למטה, עד שהוא כבר לא שייך שם

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

לכל שכבה יש מחיר

Click to enlarge

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

לפני שמפעילים

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

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

Steve Trucking: הגנה על המשלוח

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

שימו לב שלא אמרתי “שימו את כולם ב-flow”. כל כלל יושב על השלב שלו. לכל כלל, שאלו: מהי השכבה הנמוכה ביותר שאוכפת את זה נכון בכל נתיב כתיבה שחשוב?

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

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

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

להרחבה

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) ו-Roll-Up Summary Field (opens in a new tab) (באנגלית, נבדק ב-2026-10-13).
• Salesforce Help, Picklist Limitations (opens in a new tab) (באנגלית, נבדק ב-2026-10-02).
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (באנגלית, נבדק ב-2026-10-02).
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (באנגלית, נבדק ב-2026-10-13): המגבלות, הנתיבים שבהם כללים לא רצים, שמירות דרך API וייבוא שנחסמות בלי התראה, שמירות בו-זמניות שלא מושוות.
• Apex Developer Guide, Apex Transactions (opens in a new tab) ו-DML Statements vs. Database Class Methods (opens in a new tab) (באנגלית, נבדק ב-2026-10-13): טרנזקציה אחת מתגלגלת אחורה כיחידה; מתודות Database יכולות לאפשר הצלחה חלקית.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (באנגלית, נבדק ב-2026-10-02).