דלגו לתוכן
HPI — High Tech Professions Institute

פיתוח ואוטומציה

Flow או Apex — החלטה מנומקת, לא הרגל.

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

מפת יכולות

מה נכלל ובאיזה סדר

המפה מציגה את שכבות העבודה בשירות זה, מהתשתית ועד היכולות שהמשתמשים רואים.

פיתוח ואוטומציה — Capability Map

  1. Flow

    אוטומציה הצהרתית עם מבנה ברור, שמות עקביים ותיעוד.

  2. Apex

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

  3. LWC

    ממשקים ייעודיים שמקצרים עבודה יומיומית.

  4. Platform Events

    הפרדת מערכות באמצעות אירועים במקום קריאות ישירות.

  5. בדיקות ואיכות

    כיסוי בדיקות משמעותי ולא פורמלי, וסקירת קוד.

  6. בקרת גרסאות

    Sandboxes, שחרור מבוקר ותיעוד שינויים.

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

הרקע

מה באמת מכריע כאן

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

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

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

תחומי עבודה

מה אנחנו עושים בפועל

Flow

אוטומציה הצהרתית עם מבנה ברור, שמות עקביים ותיעוד.

Apex

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

LWC

ממשקים ייעודיים שמקצרים עבודה יומיומית.

Platform Events

הפרדת מערכות באמצעות אירועים במקום קריאות ישירות.

בדיקות ואיכות

כיסוי בדיקות משמעותי ולא פורמלי, וסקירת קוד.

בקרת גרסאות

Sandboxes, שחרור מבוקר ותיעוד שינויים.

מטריצת החלטה

ההחלטות שקובעות את התוצאה

עדכון שדות ותנאים

הצהרתי
Flow
קוד
מה מכריע
פשטות ותחזוקה

לוגיקה עם חריגים רבים

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

נפח רשומות גבוה

הצהרתי
עלול להיתקל במגבלות
קוד
Apex מותאם
מה מכריע
היקף העיבוד

ממשק ייעודי

הצהרתי
דף סטנדרטי
קוד
LWC
מה מכריע
מורכבות האינטראקציה

פרסום לכמה מערכות

הצהרתי
קריאות ישירות
קוד
Platform Events
מה מכריע
מספר הצרכנים וסבילות לכשל

אופן העבודה

שלבי הביצוע

  1. 01

    מיפוי אוטומציות קיימות

    מה רץ על כל אובייקט ובאיזה סדר.

  2. 02

    הכרעת גישה

    הצהרתי או קוד, עם נימוק מתועד.

  3. 03

    בנייה

    סטנדרט שמות, מודולריות ומניעת כפילות.

  4. 04

    בדיקות

    תרחישים חיוביים ושליליים, לא רק כיסוי.

  5. 05

    שחרור

    Sandbox, סקירה וחלון שחרור מוגדר.

  6. 06

    ניקוי

    הסרת אוטומציות מיותרות והפחתת חוב.

שאלות נפוצות

שאלות שחוזרות

האם Flow תמיד עדיף על Apex?
לא. Flow עדיף כשההיגיון פשוט וברור, כי הוא זול לתחזוקה ונגיש גם ל-Admin. כשיש לוגיקה מורכבת, נפחים גבוהים או צורך בשליטה מדויקת בסדר הפעולות, Apex עם בדיקות הוא הבחירה הבטוחה יותר.
כמה אוטומציות מותר על אובייקט אחד?
המספר פחות חשוב מהשקיפות. הבעיה מתחילה כשאין מי שיודע מה רץ ובאיזה סדר. סטנדרט מסודר ותיעוד חשובים יותר מכלל נוקשה.
מה נחשב חוב טכני בהקשר הזה?
אוטומציות כפולות, קוד ללא בדיקות, שדות שאינם בשימוש, הרשאות רחבות מדי ולוגיקה שאין לה בעלים. כל אלה מגדילים את הסיכון בכל שינוי עתידי.
האם צריך כלי DevOps?
כשיש יותר ממפתח אחד או קצב שחרור קבוע — כן. בסביבה קטנה, תהליך Sandbox מסודר ותיעוד עשויים להספיק בשלב הראשון.

השלב הבא

בחינת שכבת האוטומציה

נמפה את מה שרץ היום, נזהה כפילויות ונגדיר סטנדרט שאפשר לתחזק.