התשובה הקצרה

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

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

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

טעות שחוזרת בהרבה ארגונים: יוצרים Custom Object חדש לכל דרישה שמגיעה מהעסק, בלי לבדוק אם אפשר להשתמש בשדה נוסף על אובייקט קיים או ב-Record Type. התוצאה אחרי שנתיים-שלוש היא Org עם 80-120 אובייקטים מותאמים אישית, חלקם כפולים במשמעות, בלי תיעוד למה כל אחד נוצר.

העיקרון המנחה הוא לשאול לפני יצירת כל אובייקט: מי הבעלים העסקי, מה מקור האמת (Salesforce או מערכת חיצונית), ומה קורה כשרשומה נמחקת או משתכפלת. חברות שמנהלות קטלוג מוצרים מורכב, למשל, נוטות ליצור Object נפרד לכל קטגוריה במקום להשתמש ב-Record Types על Product2 - וזה מייצר עומס תחזוקה מיותר בכל שדרוג.

טבלה שימושית לבדיקת בשלות מודל הנתונים:

רכיבשאלת בדיקהסימן אזהרה
אובייקטים מותאמיםהאם יש Object דומה קיים שאפשר להרחיב?שני אובייקטים עם אותם שדות בעיקרם
שדותהאם השדה משמש ליותר מתהליך אחד?יותר מ-800 שדות על אובייקט מרכזי
קשריםהאם Master-Detail או Lookup נבחר בכוונה?Master-Detail שנבחר "כברירת מחדל"
External IDהאם לכל אובייקט המסונכרן יש מפתח ייחודי?סנכרון לפי שם או תאריך בלבד

Sharing והרשאות: השכבה שנשברת בשקט

מודל הרשאות רופף לא מתגלה מיד - הוא מתגלה כשמישהו רואה נתון שהוא לא אמור לראות, או כשדוח מנהלים מציג פחות שורות מהצפוי כי Sharing Rule חוסמת גישה. הבחירה בין Role Hierarchy, Organization-Wide Defaults, Sharing Rules ו-Permission Sets צריכה להיגזר ממבנה הארגון בפועל, לא מהמבנה ההיררכי הרשמי בתרשים הארגוני.

אנטי-פטרן שכיח: הענקת "View All" או "Modify All" ברמת פרופיל כדי "לפתור" תקלת הרשאות בלחץ זמן, בלי לחזור אחר כך ולצמצם. זה עובד בטווח הקצר ויוצר חשיפת מידע רחבה בטווח הארוך - במיוחד ברגולציה כמו פיננסים או בריאות. Permission Set Groups מאפשרות לבנות הרשאות מודולריות שניתן להוסיף ולהסיר בלי לגעת בפרופיל הבסיסי, וזו הדרך הבטוחה יותר להתמודד עם ארגון שגדל.

Criteria-Based Sharing Rules על אובייקטים עם מיליוני רשומות דורשות בדיקת עומס לפני Production - יש מקרים שבהם חוק Sharing שנראה תמים גורם ל-Recalculation שאורך שעות ותוקע תהליכי לילה.

אוטומציה: Flow מול Apex

השאלה "Flow או Apex" היא לא שאלה של טעם אלא של מורכבות, נפח וטווח חיים. Flow קריא יותר לצוות תפעולי, נבנה ומתוחזק מהר, ומתאים ללוגיקה עסקית שמשתנה. Apex נדרש כשיש Bulk Processing על אלפי רשומות בטרנזקציה אחת, כשצריך שליטה מדויקת בסדר ריצה מול Triggers אחרים, או כשנדרשת בדיקה אוטומטית (Test Coverage) לצורך רגולציה או Change Management פורמלי.

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

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

אינטגרציות: מ-Point-to-Point לשכבה מנוהלת

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

המעבר לשכבת Middleware (MuleSoft, או שכבת Integration Layer מותאמת) לא חייב להיות פרויקט ענק - אפשר להתחיל מהחיבור הכי שברירי או הכי יקר לתחזוקה ולעבור בהדרגה. עקרונות שכדאי לאמץ בכל אינטגרציה חדשה: Idempotency (קריאה כפולה לא יוצרת רשומה כפולה), External ID לזיהוי ודאי, ולוג שמאפשר לשחזר בדיוק מה קרה בכל קריאה. הרחבה על דפוסי אינטגרציה מופיעה בחיבור Salesforce ל-ERP ובדפוסי אינטגרציה Salesforce.

Org Strategy: Single Org, Multi-Org או Business Unit Segmentation

זו אחת ההחלטות היקרות ביותר לשינוי בדיעבד. Single Org עם Business Unit Segmentation (שימוש ב-Record Types, Sharing ו-Permission Sets להפרדה לוגית) מתאים לרוב הארגונים, כי הוא שומר על מקור אמת אחד ומדדי דיווח מאוחדים. Multi-Org נכון כשיחידות עסקיות דורשות מודלי הרשאה סותרים באופן מהותי, כשיש מיזוג או רכישה שמביאה Org קיים, או כשעומס הרשאות בפועל פוגע בביצועים.

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

DevOps ו-Scalability: איך שומרים על יכולת שינוי

ארגון שמפתח ישירות ב-Production, בלי Sandbox מסודר ובלי כלי CI/CD (כמו Copado, Gearset או SFDX), מגיע במהרה למצב שבו כל שינוי מסוכן. תהליך DevOps תקין כולל לפחות Sandbox לפיתוח, Sandbox לבדיקות, בקרת גרסאות ל-Metadata, ותהליך Deployment אוטומטי עם בדיקות רגרסיה.

טבלת החלטות ארכיטקטוניות מרכזיות וההשלכות שלהן לטווח ארוך:

החלטהיתרון מיידיהשלכה בעוד 2-3 שנים
Custom Object לכל דרישהפתרון מהיר לצורך נקודתיOrg עם עשרות אובייקטים כפולים, קשה לתחזק
הרשאות "View All" זמניותפותר תקלה תוך דקותחשיפת מידע רחבה שקשה לאתר ולסגור
Flow שקורא ל-Flowפיתוח מהיר בלי קודשרשראות שקשה לעקוב אחריהן ולבדוק
אינטגרציה Point-to-Point נוספתחיבור מהיר בין שתי מערכותרשת חיבורים שכל שינוי שובר משהו אחר
פיתוח ישיר ב-Productionחוסך זמן הקמת תהליךסיכון גבוה לכל שינוי, קושי בשחזור
Single Org בלי הפרדה לוגיתדיווח מאוחד מהיום הראשוןקושי בהוספת יחידה עסקית עם צרכים שונים

תרחיש ארגוני לדוגמה

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

הצוות הארכיטקטוני ביצע מיפוי מלא: זיהה 23 אובייקטים ללא Owner ברור, שש שרשראות Flow חופפות, ושתי אינטגרציות שיצרו רשומות כפולות בגלל היעדר External ID עקבי. הפתרון לא היה בנייה מחדש, אלא תיעוד הדרגתי, איחוד לוגיקת Sharing תחת Permission Set Groups, ומעבר אינטגרציות קריטיות לשכבת Middleware אחת. תוך שני רבעונים ירד זמן הוספת יחידה עסקית חדשה מכמה חודשים לכשישה שבועות.

אנטי-פטרנים נפוצים בארגונים גדלים

  • Custom Object לכל בקשה - יוצרים אובייקט חדש בלי לבדוק אם קיים כבר דומה
  • הרשאות רחבות "זמניות" - ניתנות תחת לחץ ולעולם לא מצומצמות בחזרה
  • Flow-in-Flow ללא מיפוי - שרשראות אוטומציה שאין להן תרשים ריצה מרכזי
  • Point-to-Point ללא Governance - כל חיבור חדש נבנה בנפרד בלי סטנדרט משותף
  • פיתוח ב-Production - שינויים ישירים בלי Sandbox, בדיקות או Version Control
  • היעדר External ID - סנכרון לפי שם או אימייל שיוצר רשומות כפולות

Checklist לבדיקת בשלות ארכיטקטונית

  • ☐ לכל אובייקט מותאם אישית יש Owner עסקי מתועד
  • ☐ מודל ה-Sharing נבדק תחת עומס נתונים ריאלי
  • ☐ קיימת מפה מרכזית של כל שרשראות ה-Automation
  • ☐ לכל אינטגרציה יש External ID, Retry ולוג שגיאות
  • ☐ קיים תהליך Sandbox-to-Production מסודר עם בדיקות רגרסיה
  • ☐ הוחלט מפורשות בין Single Org ל-Multi-Org עם נימוק כתוב
  • ☐ Governor Limits נבדקים מול תחזית הצמיחה לשלוש שנים

כאשר ארכיטקטורת Salesforce דורשת ליווי מקצועי ולא רק מסגרת עבודה עצמאית, זהו התחום של שירות ארכיטקטורת CRM.

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