התשובה הקצרה

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

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

טבלת ההחלטה

מימושמתי מתאיםמי מתחזקמחיר האפשרות
Standard Actionשליפה, עדכון שדה, פתיחת Case, סיכום רשומהמנהל פלטפורמהגמישות מוגבלת לכללים עסקיים
Flowכללים עסקיים משתנים, כמה שלבים, ולידציהAdmin או בעל תהליךביצועים בנפח גבוה, טיפול מוגבל בשגיאות
Apexלוגיקה מורכבת, עיבוד מסיבי, שליטה בשגיאותמפתח בלבדכל שינוי דורש מחזור פריסה ובדיקות
External Services / APIמקור האמת מחוץ ל-Salesforceצוות אינטגרציהתלות בזמינות, Latency וגרסאות של צד שלישי

הכלל הראשון: תיאור לפני מימוש

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

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

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

מתי Flow ומתי Apex

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

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

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

פעולות מול מערכות חיצוניות

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

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

Latency הוא שיקול חוויה ולא רק שיקול טכני. קריאה שנמשכת כמה שניות מקובלת בערוץ צ'אט אם הסוכן אומר שהוא בודק; קריאה שנמשכת יותר מכך דורשת מסלול אסינכרוני - הסוכן מאשר קבלה ומעדכן כשהתשובה מגיעה.

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

הרשאות ברמת הפעולה

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

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

מתי לפצל פעולה

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

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

תכנון נקודות העצירה בין החלקים מפורט בHuman-in-the-Loop ב-Agentforce.

תרחיש: ארגון שעבר מ-Apex בחזרה ל-Flow

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

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

הלקח לא היה ש-Apex גרוע, אלא שבשלב שבו הכללים עדיין מתגבשים, עלות השינוי חשובה יותר מעלות הבנייה הראשונית.

סיכונים ופעולות מניעה

סיכוןאיך הוא מתגלהפעולת מניעה
תיאור פעולה מעורפלהסוכן מפעיל את הפעולה הלא נכונהתיאור עם "מתי כן" ו"מתי לא" ופרמטרים מוגדרים
ניסיון חוזר בעיוורוןרשומות או חיובים כפוליםמפתח ייחודי לבקשה או ויתור על Retry
הרשאה רחבה לסוכןפעולה רגישה נגישה לכל משתמשהרשאה נפרדת לכל Action ולידציה בתוך הפעולה
כל הלוגיקה ב-Apexכל שינוי עסקי הופך לפרויקט פיתוחFlow לכללים משתנים, Apex למורכבות אמיתית
פעולה שעושה שלושה דבריםכשל באמצע משאיר מצב לא עקביפיצול לפי שיקול דעת ולפי הרשאה

מדדים ל-Actions

מדדמה הוא מגלהתדירות
Action success rateאחוז הפעלות שהסתיימו בהצלחהשבועי
Wrong action rateאחוז המקרים שבהם נבחרה פעולה לא נכונהבכל גרסה
Latency חציוני לפעולההאם החוויה נשארת סבירהשבועי
שיעור כשלי אינטגרציהיציבות מערכות היעדשבועי
זמן תיקון ממוצעהאם המימוש שנבחר מאפשר שינוי מהירחודשי

כאשר נדרש ליווי בתכנון שכבת ה-Actions והתאמתה לארכיטקטורה הקיימת, שירות Agentforce ו-AI הוא המסלול המעשי להמשך.

Checklist לכל Action

  • ☐ נכתב תיאור עם "מה", "מתי כן" ו"מתי לא"
  • ☐ הפרמטרים מינימליים ומטיפוס מוגדר
  • ☐ נבחר המימוש הגבוה ביותר שמספיק לצורך
  • ☐ הוגדרה הרשאה נפרדת לפעולה
  • ☐ הוולידציה יושבת בתוך הפעולה ולא רק בהוראות
  • ☐ נקבע האם הפעולה אידמפוטנטית ומה מדיניות ה-Retry
  • ☐ הוגדרו זמן המתנה מרבי והודעת כשל למשתמש
  • ☐ פעולות מרובות שיקול דעת פוצלו
  • ☐ קיים תרחיש בדיקה לכשל ולא רק להצלחה