כלי טריגרים ואוטומציות

טריגר במערכת מפוצל לשני חלקים, ולכן לשני כלים:

• מתי לירות — Set-Trigger יוצר את “ראש” הטריגר: על איזו טבלה, באילו אירועים, תחת אילו תנאים.
• מה לעשות — Set-Trigger-Action מחבר פעולה אחת. יש כמה פעולות? קוראים לכלי כמה פעמים, והן נשמרות כרשימה מסודרת שרצה לפי הסדר.

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

לפני שיוצרים — לקרוא

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

Get-Triggers

הפרמטר	טיפוס	חובה	המשמעות
tableName	String		הטבלה שרוצים את הטריגרים שלה. בלי הפרמטר — מוחזרים כל הטריגרים במערכת

התשובה היא אובייקט עם שני מערכים: triggers ו‑scheduledTriggers.

• עם tableName — triggers הוא מערך של טריגרי data change של הטבלה, כל אחד עם _id (מזהה בסגנון Parse, 10 תווים), name, active, events, onSetFields, criterias, oneachupdate ו‑actions (לכל פעולה type, _id ושדות הפעולה).
• בלי tableName — triggers הוא מערך של { "className": "Sales", "triggers": [ … ] }, קבוצה לכל טבלה שיש לה טריגרים.
• scheduledTriggers — טריגרים מתוזמנים, במבנה שונה: { "_id": "<24 hex>", "className": "Sales", "app": "<appId>", "data": { "name", "active", "criterias", "actions", "schedulerField", "shcedulerHours" } }. שימו לב: shcedulerHours חוזר כמחרוזת ("24"), ו‑actions של טריגר מתוזמן הם ללא _id (מזהים אותם לפי אינדקס — ראו Set-Trigger-Action).
• טבלה שאינה קיימת ⇒ Error: Class X does not exist.

שתי הערות קריאה

1. היעדר active פירושו פעיל. בנתונים שמורים, טריגר בלי המפתח active הוא טריגר שרץ. אל תפרשו היעדר כ“כבוי”.
2. נתקלתם בפרמטר triggerId לשליפת טריגר בודד? הוא אינו בסכימה החיה של הכלי, ושליחתו מתעלמת בשקט — חוזרים כל טריגרי הטבלה. שולפים לפי טבלה ומסננים בצד הקורא לפי _id או name.

מגבלה ידועה — Get-Triggers אינו עובד עם API Key

בחיבור עם X-Parse-API-Key הכלי מחזיר Error: Not Found (עם ובלי tableName), בעוד ש‑Set-Trigger ו‑Set-Trigger-Action עובדים עם אותו מפתח. עד לתיקון: קראו את הטריגרים מ‑REST (GET /parse/schemas/<Table> מחזיר מערך triggers), או חברו את הסוכן הזה עם Master Key. ראו שרת ה‑MCP.

Set-Trigger

יוצר טריגר חדש, או מעדכן קיים כשמעבירים _id. בעדכון שולחים רק את מה שמשתנה — בשני הסוגים: ב‑data change שינוי שם בלבד שומר events, onSetFields, criterias ו‑actions, וב‑scheduled שינוי שם בלבד שומר את schedulerField, shcedulerHours, criterias והפעולות. מול שרת מגרסאות ישנות זה לא נכון ל‑scheduled — ראו הערת ההיסטוריה למטה.

הפרמטר	טיפוס	חובה	המשמעות
tableName	String	✔	הטבלה שעליה הטריגר יושב
type	Enum	✔	data change (על יצירה/עדכון) או scheduled (יחסית לשדה תאריך). ערך אחר נדחה בוולידציה
active	Boolean	✔	הפעלה/כיבוי. פרמטר חובה גם ביצירה — בלעדיו: active: Invalid input: expected boolean, received undefined
name	String		שם הטריגר. בעברית — מומלץ
_id	String		מזהה טריגר קיים. קיים ⇒ עדכון; נעדר ⇒ יצירה
events	Array	לסוג data change	["create"], ["update"] או שניהם. ערך אחר (למשל delete) נדחה בוולידציה
onSetFields	Array<String>	לסוג data change	הטריגר ייבחן רק אם אחד מהשדות האלה השתנה. באירוע create — בחרו שדה שתמיד נקבע. הסכימה מגדירה אותו כחובה לטריגר data change (הוולידציה אמנם לא חוסמת בלעדיו, אבל בלי הרשימה כל עדכון בטבלה נבחן)
criterias	Array		תנאי סינון במבנה F/C/T/V/P — ראו למטה
oneachupdate	Boolean		false (ברירת מחדל) = פעם אחת לכל רשומה · true = בכל עדכון תואם
schedulerField	String	לסוג scheduled	שדה מסוג תאריך שממנו נגזר התזמון
shcedulerHours	Number	לסוג scheduled	כמה שעות לפני ערך התאריך. שלילי = אחרי

onSetFields — לא קישוט, אלא בלם

זה הפרמטר שמונע לולאות. טריגר על Sales שכותב בחזרה ל‑Sales יפעיל את עצמו — אלא אם השדה שהוא כותב אינו ברשימת השדות שהוא מאזין להם. שני שמות שדה שונים = אין לולאה.

הוא גם שיקול ביצועים: בלי onSetFields כל עדכון בטבלה נבחן מול כל התנאים.

מבנה התנאי — F/C/T/V/P

JSON

{
  "F": "SaleStatusId",
  "FText": "סטטוס מכירה",
  "C": "equalTo",
  "T": "Pointer",
  "V": "zrP1MSVBoq",
  "P": { "targetClass": "SaleStatuses", "visibleVal": "הושלמה", "multiple": false },
  "condOr": false
}

המפתח	חובה	המשמעות
F	✔	שם השדה. תומך במסלול Pointer — OwnerId._User.name
C	✔	האופרטור (enum, ראו למטה)
T	✔	טיפוס הערך — String, Number, Pointer, Boolean, Date. מחרוזת חופשית בסכימה (אין enum), ולכן שגיאת כתיב לא נתפסת
V	✔	הערך להשוואה. חובה בסכימה — בלעדיו: criterias.0.V: Invalid input: expected nonoptional. ל‑Pointer — ה‑objectId; ל‑containedIn — מערך
P	ל‑Pointer	{ targetClass ✔, visibleVal, multiple }. targetClass נאכף בוולידציה כשיש P. multiple: true כש‑V הוא מערך
FText		תווית לתצוגה בממשק
condOr		true מכניס את התנאי לקבוצת ה‑OR

האופרטורים

ה‑enum של הסכימה החיה מכיל עשרה אופרטורים בדיוק:

contains · startsWith · equalTo · greaterThan · lessThan · greaterThanOrEqualTo · lessThanOrEqualTo · notEqualTo · containedIn · notContainedIn

מגבלה ידועה — exists / doesNotExist אינם ניתנים ליצירה מ‑MCP

מבנה התנאים הכללי של המערכת כולל גם exists ו‑doesNotExist, והם קיימים בטריגרים שמורים (למשל {"F":"File","C":"exists","T":"PrivateFile"} בטריגר inventoryUpdate של תבנית ה‑vanilla). אבל Set-Trigger דוחה אותם עוד בוולידציה: criterias.0.C: Invalid option: expected one of "contains"|…|"notContainedIn". תנאי “השדה ריק/מלא” נוצר רק בממשק (Databases ← Tables ← הטבלה ← Triggers), או מוחלף בתנאי על ערך ידוע.

AND ו‑OR

• תנאים בלי condOr — כולם חייבים להתקיים (AND).
• תנאים עם condOr: true — מרכיבים קבוצת OR אחת: מספיק שאחד מהם מתקיים.
• תנאי OR בודד חסר משמעות; צריך לפחות שניים.
• שילוב: כל תנאי ה‑AND חייבים להתקיים, וגם לפחות אחד מתנאי ה‑OR.

JSON

"criterias": [
  { "F": "Total", "C": "greaterThan", "T": "Number", "V": 5000 },
  { "F": "SaleStatusId", "C": "equalTo", "T": "Pointer", "V": "zrP1MSVBoq",
    "P": { "targetClass": "SaleStatuses", "visibleVal": "הושלמה" }, "condOr": true },
  { "F": "SaleStatusId", "C": "equalTo", "T": "Pointer", "V": "V0sVNyS45K",
    "P": { "targetClass": "SaleStatuses", "visibleVal": "משא ומתן" }, "condOr": true }
]

תרגום: סכום מעל 5,000 וגם סטטוס אחד מהשניים.

טריגר מתוזמן

JSON

{ "tableName": "Sales", "type": "scheduled", "active": true,
  "name": "תזכורת לפני תאריך סגירה",
  "schedulerField": "ClosingDate",
  "shcedulerHours": 24,
  "criterias": [
    { "F": "IsWon",  "C": "notEqualTo", "T": "Boolean", "V": true },
    { "F": "IsLost", "C": "notEqualTo", "T": "Boolean", "V": true }
  ] }

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

shcedulerHours	המשמעות
720	30 יום לפני התאריך
24	יום לפני
1	שעה לפני
-1	שעה אחרי — זה מה שמשמש ל“בערך על התאריך”
-48	יומיים אחרי
0	בדיוק על התאריך (מתקבל; נשמר כ‑"0")

shcedulerHours — שגיאת כתיב אמיתית בשרת

זה שם הפרמטר האמיתי, על השגיאה שבו. הסכימה החיה מגדירה shcedulerHours.

שליחת schedulerHours המאויית נכון נדחית: הוולידציה מוחקת את המפתח הלא‑מוכר, והשרת מחזיר Error: Scheduler hours is required for scheduled trigger — אותה שגיאה כמו כששוכחים את הפרמטר לגמרי. (השמטת schedulerField מחזירה באותו אופן Error: Scheduler field is required for scheduled trigger.) הטריגר לא נוצר; הסכנה היחידה היא לקרוא את ההודעה ולחפש את הפרמטר בשם הנכון.

הערך 0 עובד

הסכימה אומרת “value can be 0 (run on time) or negative value”, ובפועל shcedulerHours: 0 מתקבל ויוצר טריגר (נשמר כמחרוזת "0"; גם תבנית ה‑vanilla מכילה טריגרים עם "0"). גרסה קודמת של הפלטפורמה דחתה 0 — אם אתם רואים Scheduler hours is required על 0, עברו ל‑1/-1.

היסטוריה — עדכון חלקי של טריגר מתוזמן דרס את כולו

בגרסאות שרת ישנות, Set-Trigger עם _id של טריגר מתוזמן החליף את כל אובייקט ה‑data במה שנשלח: קריאה כמו { "_id": "…", "type": "scheduled", "active": false } — הכיבוי השגרתי — מחקה את schedulerField, shcedulerHours, criterias ואת כל הפעולות, בלי שגיאה. בגרסאות עדכניות עדכון חלקי של השם בלבד שומר את כל שאר ההגדרות — השרת ממזג, כמו ב‑data change. מול שרת ישן, הנוהג הבטוח נשאר: Get-Triggers קודם, ואז שליחת כל השדות.

ערכי החזרה — שני פורמטים שונים למזהה

סוג הטריגר	מה חוזר	מהיכן לוקחים את המזהה
data change	סכימת המחלקה כולה (className, fields, classLevelPermissions) עם מערך triggers	מאתרים לפי name, לוקחים את _id (בסגנון Parse, למשל 9ht1ary5dW)
scheduled	{"value":"69df53414167a73a568f34df"}	ה‑value עצמו (בסגנון MongoDB, 24 תווים)

זה חשוב כי Set-Trigger-Action מקבל את המזהה הזה, וגם מתייחס לפעולות עצמן בשני אופנים שונים לפי סוג הטריגר. גם Set-Trigger-Action מחזיר שני פורמטים: ב‑data change — שוב סכימת המחלקה עם triggers; ב‑scheduled — {"ok":1,"value":{ …הטריגר המלא… }}. טבלה שאינה קיימת ⇒ Error: Table not found.

Set-Trigger-Action

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

הפרמטר	טיפוס	חובה	המשמעות
tableName	String	✔	אותה טבלה של הטריגר
triggerId	String	✔	המזהה שהוחזר מ‑Set-Trigger
triggerType	Enum	✔	data change / scheduled — חייב להתאים לטריגר (אי‑התאמה ⇒ Error: Scheduled trigger not found)
actionType	Enum	✔	אחד מתשעת הסוגים למטה
actionData	Object	ליצירה/עדכון	אובייקט הפעולה, ממופתח לפי סוג הפעולה. חסר ⇒ Error: Action data is required; מפתח שאינו תואם ל‑actionType ⇒ למשל Error: HTTP data is required. שדות החובה של כל סוג נאכפים בוולידציה
actionId	String	לעדכון/מחיקה	בטריגר data change — ה‑_id של הפעולה · בטריגר scheduled — אינדקס כמחרוזת ("0", "1")
deleteAction	Boolean	למחיקה	מוחק את הפעולה

תשעת סוגי הפעולות

actionType	מה קורה	שדות חובה ב‑actionData
email	שולח מייל מחשבון SMTP לפי תבנית	template, emailAccount, emailType, emailTarget, emailSubject, saveToEmailsTable
sms	שולח SMS	from, local, content, toType, to
whatsapp-message	שולח WhatsApp בתבנית מאושרת	toType, to, message, from, template, WATemplateParams
notification	התראה בתוך ה‑CRM למשתמש	userType, user, content
create-object	יוצר רשומה חדשה בטבלה כלשהי	targetClass, fieldsValue
update-object	מעדכן רשומה קשורה (או את עצמה)	targetClass, connection, fieldsValue
http	קורא ל‑webhook עם גוף הרשומה	url, method
server-side-code	מריץ פונקציית צד שרת קיימת	functionName
ai-webhook	קורא ל‑webhook של AI מטבלת AiWebhooks	webhookId, webhookName (המפתח ב‑actionData הוא aiWebhook)

ai-webhook — ערך שהתחלף בין עדכוני שרת

בשמונה מתוך תשעת הסוגים המפתח בתוך actionData זהה למחרוזת actionType: actionType: "create-object" ⇒ actionData: { "create-object": { … } }. היוצא מן הכלל הוא פעולת ה‑AI webhook: בסכימה החיה ה‑enum הוא "ai-webhook" והמפתח ב‑actionData הוא "aiWebhook".

הערך הזה כבר התחלף בין עדכוני שרת: בחלק מגרסאות השרת שני הערכים היו trigger-ai-webhook, ובגרסאות עדכניות הסכימה החיה מחזירה שוב ai-webhook/aiWebhook. לפני שימוש בפעולה בדקו את הערך הנוכחי ב‑tools/list (תיאור Set-Trigger-Action) ואל תסתמכו על השם שמופיע כאן.

שתי הסתייגויות: הכלי אינו מאמת את webhookId (מזהה פיקטיבי מתקבל), וטבלת AiWebhooks אינה קיימת במערכת חדשה — ודאו שהיא קיימת ושהמזהה אמיתי לפני שנשענים על הפעולה.

email

JSON

{ "tableName": "Sales", "triggerId": "9ht1ary5dW", "triggerType": "data change",
  "actionType": "email",
  "actionData": { "email": {
    "emailType": "field",
    "emailTarget": "AccountId.Accounts.Email",
    "emailSubject": "העסקה {{{Name}}} אושרה",
    "emailAccount": "smtp12345x",
    "template": "tmpl098765",
    "saveToEmailsTable": true,
    "fieldsValue": [
      { "field": "AccountId", "targetClass": "Accounts", "type": "Pointer",
        "value": "AccountId", "visibleVal": "Account" },
      { "field": "SaleId", "targetClass": "Sales", "type": "Pointer",
        "value": "current", "visibleVal": "Current Object(Sales)" }
    ]
  } } }

• emailType: fixed (כתובת קבועה) או field (שדה מהרשומה, כולל מסלול Pointer).
• emailAccount הוא ה‑objectId של חשבון SMTP — מ‑Get-SMTP-Accounts. במערכת חדשה הרשימה ריקה ([]), ואז פעולת האימייל תיכשל. בדקו לפני — הכלי אינו מאמת את המזהים: פעולת email עם emailAccount ו‑template שאינם קיימים נשמרת בהצלחה.
• template הוא objectId מטבלת EmailTemplate. אי אפשר ליצור תבנית מייל מ‑MCP — היא נוצרת בממשק.
• saveToEmailsTable שומר עותק ב‑Emails, ו‑fieldsValue קובע לאילו רשומות הוא ייקשר.

sms

JSON

{ "sms": {
    "toType": "field", "to": "PhoneNumber",
    "from": "0501234567", "local": "IL",
    "content": "שלום {{{AccountId.Name}}}, הזמנתך על סך {{{Total}}} ₪ התקבלה.",
    "useQueue": true } }

useQueue: true מומלץ בכל תרחיש שיכול לרוץ במקביל על הרבה רשומות.

whatsapp-message

JSON

{ "whatsapp-message": {
    "toType": "field", "to": "PhoneNumber",
    "from": "100000000000000",
    "waba_id": "WABA_ID",
    "message": "עדכון סטטוס",
    "template": { "name": "status_update", "language": "he", "components": [] },
    "WATemplateParams": { "BODY": ["{{{AccountId.Name}}}", "{{{Name}}}"] } } }

from הוא ה‑Identity של הערוץ ולא ה‑objectId שלו. זו התקלה מספר 1 באינטגרציות WhatsApp — ההסבר המלא בכלי הודעות, וגם ה‑workflow להוצאת components ו‑WATemplateParams.

notification

JSON

{ "notification": {
    "userType": "field", "user": "OwnerId",
    "content": "<div>פנייה חדשה: <b>{{{Name}}}</b><br/>לקוח: {{{AccountId.Name}}}</div>",
    "icon": "fa-bell", "iconColor": "#00a396" } }

userType: fixed (objectId של משתמש) או field (שדה Pointer ל‑_User). התוכן תומך ב‑HTML. icon הוא שם אייקון של FontAwesome גרסה 3.4 (כך לפי תיאור הסכימה) — לא הגרסאות החדשות.

ההתראה נכתבת לטבלה _Notification (שדות Content, User, Icon, IconColor, Date, objectClass, objectIdValue), ה‑placeholders מוחלפים — כולל מסלול Pointer {{{OwnerId.name}}} ושלושת פורמטי התאריך: {{{Stamp.format(date,he-IL,Asia/Jerusalem)}}} ⇒ 10.9.2026, datetime ⇒ 10.9.2026, 11:30:00, timehm ⇒ 11:30. placeholder לשדה ריק מוחלף במחרוזת ריקה.

create-object

JSON

{ "create-object": {
    "targetClass": "Tasks",
    "fieldsValue": [
      { "field": "Name",      "type": "static",  "value": "לחזור ללקוח" },
      { "field": "SaleId",    "type": "dynamic", "value": "currentObject", "targetClass": "Sales" },
      { "field": "AccountId", "type": "dynamic", "value": "AccountId",     "targetClass": "Accounts" },
      { "field": "OwnerId",   "type": "dynamic", "value": "OwnerId",       "targetClass": "_User" },
      { "field": "DueDate",   "type": "dynamic", "value": "updatedAt",     "timeGap": 1440 }
    ] } }

שלוש התנהגויות שכדאי להכיר ב‑create-object:

• ערך static אינו עובר החלפת placeholders: { "field": "Name", "type": "static", "value": "משימה עבור {{{Name}}}" } נשמר מילולית, עם הסוגריים. לטקסט מהרשומה המפעילה השתמשו ב‑dynamic (שדה אחד) — או בפעולת notification/email, שבהן ההחלפה כן עובדת.
• מסלול Pointer ב‑dynamic עובד: "value": "OwnerId._User.name" מעתיק את שם הבעלים.
• הרשומה שנוצרת מקבלת createdBy/updatedBy = Master ושדה updatedByTrigger עם מזהה הטריגר.

מגבלה ידועה — currentUser מפעולה שמופעלת דרך MCP/API נשמר מילולית

{ "field": "OwnerId", "type": "static", "value": "currentUser", "targetClass": "_User" } אמור להציב את המשתמש שגרם לשינוי. כשהשינוי מגיע מ‑MCP או מ‑REST בחיבור Master / API Key אין משתמש כזה, והמנוע שומר Pointer עם "objectId": "currentUser" — מזהה שאינו קיים, בלי שגיאה ובלי רישום ב‑_syslogTriggers. רשומות כאלה לא יופיעו באף סינון לפי בעלים. בטריגרים שצפויים לרוץ גם מסוכן/API: העתיקו בעלים מהרשומה המפעילה ("type": "dynamic", "value": "OwnerId") או הציבו objectId קבוע.

update-object — סמנטיקת ה‑connection

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

הערך	המשמעות	דוגמה
source.<PointerField>	הרשומה המפעילה מצביעה אל רשומת היעד	טריגר על Sales שמעדכן את הלקוח: source.AccountId
target.<PointerField>	רשומות היעד מצביעות אל הרשומה המפעילה. מעדכן את כולן	טריגר על Sales שמעדכן את כל שורות המכירה: target.SaleId
current.objectId	הרשומה המפעילה עצמה	חותמת זמן על אותה מכירה

current.objectId — הערך היחיד שעובד לעדכון עצמי

תיאור הסכימה מזכיר רק target ו‑source. בפועל, עדכון עצמי דורש בדיוק את המחרוזת current.objectId — רק איתה השדות התעדכנו. self נכשל עם {"message":"missing type or field"} ב‑_syslogTriggers; target.objectId ו‑source.objectId לא מייצרים שגיאה כלל — הם נרשמים כ‑{"message":"no objects to update"} ולא משנים דבר. זה המקרה הגרוע יותר: הטריגר “רץ”, ואין שום סימן לתקלה.

JSON

{ "update-object": {
    "targetClass": "Sales",
    "connection": "current.objectId",
    "fieldsValue": [
      { "field": "OwnerSetDate", "type": "dynamic", "value": "updatedAt" }
    ] } }

fieldsValue תומך גם במסלולים חוצי‑טבלה: {"field":"AccountId","type":"dynamic","value":"SaleId.Sales.AccountId","targetClass":"Accounts"} מעתיק את הלקוח מהמכירה האב.

http

JSON

{ "http": {
    "url": "https://hooks.example.com/mb?sale={{{objectId}}}&name={{{Name}}}",
    "method": "POST",
    "useQueue": true,
    "headers": [ { "name": "Content-Type", "value": "application/json" } ] } }

method יכול להיות GET, POST, PUT, DELETE או AUTO — כאשר, לפי תיאור הסכימה, AUTO בוחר POST באירוע יצירה ו‑PUT באירוע עדכון. גוף הבקשה הוא ה‑JSON המלא של הרשומה, אוטומטית; ה‑placeholders פועלים בתוך ה‑URL (?name={{{Name}}}&oid={{{objectId}}} יוצא כ‑?name=FIRE%20many-a&oid=1q3vkAuGl7, וה‑URL שנקרא בפועל נרשם ב‑_syslogTriggers בשדה error כשהיעד מחזיר שגיאה).

שימו לב: webhook שמצביע אל ה‑API של הפלטפורמה עצמה (api.mbapps.co.il) מנותב לכתובת פנימית ונכשל ב‑403 unauthorized — פעולת http נועדה לשרת חיצוני; לכתיבה חזרה למערכת השתמשו ב‑create-object / update-object.

server-side-code

JSON

{ "server-side-code": { "functionName": "calculateCommission", "useQueue": true } }

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

ai-webhook

JSON

{ "aiWebhook": { "webhookId": "aiwh012345", "webhookName": "Lead Scoring" } }

שני השדות חובה, ושניהם מגיעים מטבלת AiWebhooks (Get-Data עליה). זו הפעולה היחידה שבה המפתח ב‑actionData (aiWebhook) שונה מ‑actionType (ai-webhook). בחלק מגרסאות השרת שני הערכים היו trigger-ai-webhook — ודאו את הערך ב‑tools/list לפני שימוש. זכרו גם: webhookId אינו מאומת, ו‑AiWebhooks אינה קיימת במערכת חדשה.

ערכים דינמיים ב‑fieldsValue

type	value
static	ערך קבוע. ל‑Pointer — objectId (הוסיפו targetClass ו‑visibleVal). המילה currentUser = המשתמש שגרם לשינוי
dynamic	שם שדה מהרשומה המפעילה. מסלול Pointer: AccountId.Accounts.Name

ערכים דינמיים מיוחדים: currentObject (Pointer לרשומה המפעילה), updatedAt, createdAt, updatedBy.

שדה תאריך מקבל ערך דינמי בלבד.

timeGap — חשבון תאריכים בדקות

מצורף לערך תאריך דינמי:

JSON

{ "field": "DueDate", "type": "dynamic", "value": "updatedAt", "timeGap": 1440 }

דקות	משך
60	שעה
1440	יום
2880	יומיים
10080	שבוע
43200	30 יום
-1440	יום אחורה

דקות לוח שנה, לא שעות עבודה. SLA שמדבר בימי עסקים לא ניתן לביטוי ב‑timeGap — הוא דורש server-side-code.

עריכה ומחיקה של פעולה

JSON

{ "tableName": "Sales", "triggerId": "9ht1ary5dW", "triggerType": "data change",
  "actionType": "http", "actionId": "abc123", "deleteAction": true,
  "actionData": { "http": { "url": "https://example.com", "method": "POST" } } }

מגבלה ידועה — מחיקה דורשת actionData תקין

גם עם deleteAction: true חייבים לשלוח actionData בעל מבנה חוקי. בלעדיו השרת קורס עם Error: Cannot read properties of undefined (reading 'http'); עם אובייקט ריק ({ "http": {} }) הוולידציה דורשת את שדות החובה של הסוג. התוכן לא משנה — המבנה כן. מחיקה שהצליחה מחזירה את סכימת המחלקה (או את הטריגר המתוזמן) בלי הפעולה; מחיקה חוזרת של אותו actionId מחזירה Error: Action not found — וזה הסימן שהמחיקה הראשונה אכן הגיעה ליעדה.

בטריגר מתוזמן actionId הוא אינדקס כמחרוזת ("1" עדכן את הפעולה השנייה, "0" מחק את הראשונה — ואחרי המחיקה הפעולה שנותרה היא אינדקס "0").

שרשרת טריגרים ותקרת שלוש הרמות

פעולה שכותבת נתונים יכולה להפעיל טריגר אחר. עומק השרשרת מוגבל לשלוש רמות: שלושה טריגרים רצים בזה אחר זה, והרביעי לא רץ — ונרשם ב‑_syslogTriggers עם {"message":"blocked! trigger step is to deep -3. source trigger: <id הטריגר הראשון>"} (בשרשרת של חמש טבלאות נוצרות רשומות בארבע הראשונות, החמישית נשארת ריקה).

T1 (יצירה) → טריגר 1 → T2 → טריגר 2 → T3 → טריגר 3 → T4 → טריגר 4 ✗ נחסם (T5 לא נוצרת)

הרשומות שנוצרות בשרשרת נושאות setObjectTriggerStep (1, 2, 3) ו‑updatedByTrigger — כך אפשר לראות בדיעבד באיזו רמה נוצרה כל רשומה.

שתי השלכות מעשיות:

1. אל תתכננו לוגיקה שנשענת על שרשרת ארוכה. מעבר לשלוש רמות — עברו ל‑server-side-code שעושה הכול בפעולה אחת.
2. בטעינה המונית זה מתפוצץ מוקדם יותר, כי כל שורה מתחילה שרשרת משלה. ראו skipTriggers בכלי נתונים.

השמירה מלולאות היא onSetFields: ודאו שהשדה שהפעולה כותבת אינו ברשימת השדות שהטריגר מאזין להם.

אין מחיקת טריגר

Set-Trigger עם active: false הוא הכיבוי. מחיקה אמיתית אפשרית רק בממשק — Databases ← Tables ← הטבלה ← Triggers.

בפועל זה בסדר: אחרי active: false יצירת רשומה תואמת אינה מפעילה את הפעולות, והטריגר המכובה לא עולה כלום ומשמר את ההיסטוריה של מה שהיה. שימו לב רק שטריגר מכובה עדיין מופיע ב‑Get-Triggers עם active: false, ולכן ספירה נאיבית של “כמה אוטומציות יש כאן” תיתן מספר מנופח. ובטריגר מתוזמן — כיבוי בעדכון חלקי בטוח בגרסאות שרת עדכניות; בשרת ישן יותר הוא דרס את הגדרת הטריגר — שם שלחו את כל השדות.

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

1. הרשומה — Get-Data עליה. זו באמת הרשומה שמדובר בה?
2. _Timeline — מה קרה בפועל, מתי, ועל ידי מי. user.objectId === "Master" פירושו שינוי מטריגר/API.
3. _syslogTriggers — שגיאות ורישומי ריצה. כל ריצה רושמת שורת {"status":"trigger run","actions":[…]} ושורה לכל פעולה (actionId, error, data); הערכים ב‑data/error חוזרים ב‑REST כ‑HTML‑escaped ("). היעדר רשומות אינו הוכחה שהטריגר לא רץ — לא כל סביבה מתחזקת את הטבלה הזו.
4. Get-Triggers — active, events, criterias מול הערכים בפועל, onSetFields מול השדה שבאמת השתנה, ו‑oneachupdate (אם false והטריגר כבר ירה על הרשומה — הוא לא יירה שוב).

התסמין	הסיבה הסבירה
לא רץ אף פעם	לא פעיל · תנאי לא תואם (מזהה/טיפוס שגוי) · השדה שהשתנה אינו ב‑onSetFields · נכתב עם skipTriggers
רץ פעם אחת ולא שוב	oneachupdate: false
מייל לא יצא	objectId שגוי של חשבון SMTP או של תבנית
WhatsApp לא יצא	from הוא objectId במקום Identity · התבנית אינה APPROVED
מתוזמן לא יורה	schedulerField ריק או בעבר · בשרת ישן: הטריגר עודכן חלקית ואיבד את schedulerField/shcedulerHours
עדכון עצמי לא קורה, בלי שגיאה	connection הוא target.objectId/source.objectId במקום current.objectId
הבעלים ברשומה שנוצרה הוא "currentUser"	הטריגר רץ מ‑MCP/API

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

המשך

• כלי נתונים — מה מפעיל את הטריגרים האלה
• כלי הודעות — Get-SMTP-Accounts ו‑WhatsApp לפעולות
• אינדקס הכלים המלא
• פונקציות צד שרת · יומנים וראיות · מגבלות ומכסות