סקילים — אוטומציה

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

הסקיל	איפה זה רץ	האם זה אוכף
myb-p-trigger-setup	שרת	כן — גם על כתיבות API
myb-p-form-rules	דפדפן, בטופס	לא — כתיבת API עוקפת לגמרי
myb-p-sla-configuration	שרת (טריגרים) + הגדרות	כן — אבל רק אחרי שבנו את הטריגרים

---

myb-p-trigger-setup

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

TRIGGER (מתי)                     ACTIONS (מה) — אחת או יותר
├── type: data change / scheduled ├── email
├── events: create / update       ├── sms
├── criterias: תנאים              ├── whatsapp-message
├── onSetFields: שדות מנוטרים     ├── create-object
└── oneachupdate: חוזר?           ├── update-object
                                  ├── notification
                                  ├── http (webhook)
                                  ├── server-side-code
                                  └── ai-webhook

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

איך נראה המזהה בתשובה: לטריגר data change התשובה היא סכימת הטבלה כולה, והמזהה יושב ב‑triggers[].._id (10 תווים — מחפשים לפי name); לטריגר scheduled התשובה היא {"value":"<24-hex>"}.

תשעה סוגי פעולות, לא שמונה

הסכימה החיה של Set-Trigger-Action מגדירה תשעה סוגי פעולות — נתקלתם ברשימה של שמונה? חסרה בה פעולת ה‑AI webhook. בסכימה החיה כרגע actionType הוא ai-webhook ובלוק ההגדרות הוא actionData.aiWebhook, עם webhookId ו‑webhookName (שניהם חובה) מטבלת AiWebhooks.

השם הזה התחלף בין עדכוני שרת — בחלק מגרסאות השרת הוא trigger-ai-webhook, ובגרסאות ישנות ai-webhook לא היה שמיש בשום צירוף מפתחות. לכן: לפני שמשתמשים בפעולה הזו בודקים את הערך בפועל ב‑tools/list של השרת שמולו עובדים, ולא מסתמכים על מה שכתוב כאן. שימו לב גם ש‑webhookId אינו מאומת, וטבלת AiWebhooks אינה קיימת במערכת חדשה.

Set-Trigger — הפרמטרים

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

בעדכון — שולחים רק את מה שמשתנה, בשני הסוגים (ב‑scheduled, שינוי שם בלבד שומר את כל שאר ההגדרות).

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

בגרסאות שרת ישנות, קריאת Set-Trigger עם _id ורק name על טריגר scheduled מחקה את schedulerField, shcedulerHours, criterias ו‑actions. מול שרת ישן שלחו תמיד את כל השדות.

shcedulerHours — שתי עובדות

1. ערך 0 מתקבל ונשמר ("0"), וכך גם ערכים שליליים — כפי שתיאור הסכימה אומר (“value can be 0 (run on time) or negative value”).
2. shcedulerHours מאויית שגוי ב‑API עצמו, והאיות הנכון אינו נכשל בשקט: schedulerHours מחזיר Error: Scheduler hours is required for scheduled trigger והטריגר לא נוצר.

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

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

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

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

מבנה התנאי

JSON

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

האופרטורים בסכימה: contains · startsWith · equalTo · greaterThan · lessThan · greaterThanOrEqualTo · lessThanOrEqualTo · notEqualTo · containedIn · notContainedIn.

exists איננו ברשימה

ה‑enum של Set-Trigger צר יותר מרשימת האופרטורים הכללית של המערכת — אין בו exists, doesNotExist, endsWith. ראו את ההשוואה המלאה בעמוד הטריגרים.

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

הפעולות — מה כל אחת דורשת

actionType	שדות החובה ב‑actionData
email	template · emailAccount · emailType (fixed/field) · emailTarget · emailSubject · saveToEmailsTable
sms	from · local · content · toType · to
whatsapp-message	toType · to · message · from · template · WATemplateParams
notification	userType · user · content (+ icon, iconColor אופציונליים)
create-object	targetClass · fieldsValue[]
update-object	targetClass · connection · fieldsValue[]
http	url · method (GET/POST/PUT/DELETE/AUTO)
server-side-code	functionName
ai-webhook	webhookId · webhookName (בבלוק actionData.aiWebhook; השם התחלף בין גרסאות שרת ובחלקן הוא trigger-ai-webhook. מוודאים ב‑tools/list)

AUTO ב‑http בוחר את השיטה לפי סוג האירוע: POST ליצירה, PUT לעדכון.

connection — הכיוון של העדכון

זה הפרמטר שהכי מבלבל ב‑update-object. הערך הוא DIRECTION.FIELD_NAME:

הכיוון	המשמעות
target.<Field>	הרשומה המעודכנת מצביעה לרשומה שהפעילה. למשל target.SaleId כשהטריגר על Sales והשדה SaleId בטבלה המעודכנת מצביע למכירה
source.<Field>	הרשומה שהפעילה מצביעה לרשומה המעודכנת. למשל source.AccountId — לעדכן את הלקוח המקושר

current.objectId — עדכון של אותה רשומה

תיאור הסכימה מציין רק target ו‑source, אבל connection: "current.objectId" הוא הערך שעובד לעדכון של הרשומה עצמה (ראו חותמת זמן). כל הערכים מתקבלים בכתיבה; בזמן ריצה self ו‑objectId נרשמים ב‑_syslogTriggers עם missing type or field, ו‑target.objectId / source.objectId נכשלים בשקט — בלי שגיאה ובלי עדכון.

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

בתוך fieldsValue, הפרמטר timeGap מוסיף דקות לערך תאריך דינמי. שלילי מותר.

JSON

{ "field": "DueDate", "type": "dynamic", "value": "updatedAt", "timeGap": 1440 }
// יום אחרי רגע העדכון

Placeholders בתוכן

{{{FieldName}}} — שלוש סוגריים — עובד בנושא ובגוף המייל, בתוכן ה‑SMS, בתוכן ההתראה, ובכתובת ה‑URL של ה‑webhook:

• {{{Name}}} — שדה מהרשומה שהפעילה
• {{{AccountId.Name}}} — מעבר דרך Pointer
• {{{SaleDate.format(date,he-IL,Asia/Jerusalem)}}} — סוג (date/timehm/datetime), locale, אזור זמן

emailTarget תומך גם הוא במעבר Pointer: "OwnerId.email" שולח לאחראי.

תבניות נפוצות

התבנית	הטריגר	הפעולה
התראה על שינוי סטטוס	events: ["update"], onSetFields: ["StatusId"], קריטריון לסטטוס	notification / email / sms
מייל ברוכים הבאים	events: ["create"]	email
משימת מעקב אוטומטית	events: ["update"] + קריטריון לסטטוס סגירה	create-object עם timeGap: 1440
סנכרון שדות בין טבלאות	events: ["update"], onSetFields: ["<field>"]	update-object עם connection
תזכורת מתוזמנת	type: "scheduled", shcedulerHours: 24	sms / notification
webhook למערכת חיצונית	events: ["create", "update"]	http POST

מה לא נתמך

• מחיקת טריגר. MCP יכול רק לכבות (active: false). מחיקה אמיתית — Admin ← Databases ← Tables ← [הטבלה] ← Triggers, ידנית.
• טריגר מסוג “הוספה לציר זמן” — קיים בממשק בלבד.
• עריכת תבניות מייל — נוצרות בממשק; הטריגר רק מפנה ל‑objectId קיים.
• יצירת חשבונות SMTP — Get-SMTP-Accounts מציג את הקיימים; יצירה בממשק.
• יצירת תבניות WhatsApp — נדרש אישור מוקדם של Meta. Send-WhatsApp-Message עם getTemplates: true מציג את המאושרות.

מלכודות

• מחיקת פעולה דורשת actionData — גם עם deleteAction: true חייבים להעביר אובייקט actionData תקף לסוג הפעולה. בלעדיו: Cannot read properties of undefined. שולחים מינימום שתקף סכימתית.
• טריגרים מתוזמנים מחזירים מזהה בפורמט אחר — {"value":"69df53414167a73a568f34df"}", כלומר ObjectId של MongoDB, ולא _id בסגנון Parse. משתמשים בשדה value בתור ה‑triggerId.
• Get-WhatsApp-Template-Params תלוי בבלוק ה‑example של מטא — הכלי לא סופר את ה‑{{N}} בגוף התבנית, אלא ממיר את בלוק ה‑example שמגיע ממטא. יש example, כל הפרמטרים חוזרים נכון, גם כשיש כמה; אין example, מוחזר אובייקט ריק לגמרי, גם לתבנית עם פרמטר יחיד. קיבלתם {} — בונים את WATemplateParams.BODY ידנית, עם ערך לכל {{N}} לפי הסדר.
• מגבלה ידועה — שרשרת טריגרים מוגבלת ל‑3 רמות. שלושה טריגרים שלובים רצים; הרביעי נחסם ונרשם ב‑_syslogTriggers עם blocked! trigger step is to deep -3. source trigger: <id>. הסכימה מזהירה מזה במפורש.
• useQueue קיים ב‑http, ב‑sms וב‑server-side-code. לטריגר שעלול לרוץ פעמים רבות בו‑זמנית — הפעילו אותו.

בדיקה ואבחון

טריגרים כן יורים מכתיבות API ו‑Master Key — Create-Data, Update-Data ו‑Create-Many כולם מפעילים אירועי create/update. כלומר בדיקה דרך MCP היא בדיקה תקפה, וממשק ו‑API מתנהגים אותו דבר.

וזה חותך לשני הכיוונים

ייבוא המוני מסעיר את האוטומציות כברירת מחדל — עשרות מיילים, מאות רשומות בנות. ההשתקה היחידה היא Create-Many(skipTriggers: true) (master key בלבד; skipTimeline: true באותו אופן לציר הזמן). לכלים של רשומה בודדת אין דגל דילוג. ראו נתונים ואינטגרציות.

לא ירה? יומן הטריגרים:

JSON

Get-Data({ "table": "_syslogTriggers", "order": "-createdAt", "limit": 5,
           "keys": ["triggerId", "actionId", "objectIdValue", "error", "event", "createdAt"] })

שורה לכל פעולה (ועוד שורה לטריגר עצמו, עם actionId: null). השדות הקיימים: triggerId, actionId, objectIdValue, error, data, event — אין triggerName; את השם מצליבים מ‑Get-Triggers.

הסיבות החוזרות, לפי סדר: onSetFields לא כולל את השדה שהשתנה · criterias לא תואמים (objectId שגוי, T שגוי) · הטריגר כבוי · oneachupdate: false והוא כבר ירה על הרשומה הזו · עומק שרשרת חורג מ‑3 · הרשומה נכתבה עם skipTriggers: true.

---

myb-p-form-rules

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

למה הסקיל הזה קיים בכלל

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

שלושת הכלים

הכלי	מה הוא עושה
Get-Form-Rules	קורא את מערך הכללים הנוכחי של הדף. תמיד ראשון
Edit-Form-Rules	מוסיף / עורך / מוחק כלל אחד. זה הכותב
Set-Form-Rules	דורס את כל הכללים בטופס. מוצא אחרון בלבד

JSON

{ "pageId": "<pageId>", "action": "add",
  "rule": { "name": "<שם ייחודי>", "conditions": [...], "actions": [...] } }

{ "pageId": "<pageId>", "action": "edit",
  "rule": { "name": "<שם קיים>", "conditions": [...], "actions": [...] } }

{ "pageId": "<pageId>", "action": "delete",
  "rule": { "name": "<שם קיים>", "conditions": [], "actions": [] } }

edit מחליף לגמרי את התנאים והפעולות של הכלל הנקוב — זה לא מיזוג. delete צריך רק את השם.

שם הכלל הוא הזהות

edit ו‑delete מאתרים לפי name. add עם שם קיים נדחה (Error: Rule name already exists), delete/edit על שם שאינו קיים — Error: Rule not found. שמות ייחודיים ותיאוריים, בעברית.

מבנה הכלל

JSON

{
  "name": "סיבת ביטול חובה כשהסטטוס בוטל",
  "conditions": [
    { "field": "StatusId", "equesition": "equalTo",
      "value": "abc1234567", "visibleVal": "בוטל", "condOr": false }
  ],
  "actions": [
    { "field": "CancelReason", "action": "required", "value": "" }
  ]
}

שימו לב לאיות: equesition — כך זה בסכימה, ואין ברירה אלא לכתוב כך.

האופרטורים בסכימה של Edit-Form-Rules: equalTo · greaterThan · lessThan · greaterThanOrEqualTo · lessThanOrEqualTo · notEqualTo · containedIn · notContainedIn — וגם שני ערכי ה‑legacy equealTo ו‑empty.

עשרה אופרטורים — שניים מהם legacy

אין exists, אין contains, אין startsWith. equealTo (שגיאת הכתיב הישנה) ו‑empty נוספו ל‑enum כדי ש‑round‑trip של חוקים שמורים יעבור. כלל חדש שנכתב עם equealTo או empty נשמר כפי שהוא — אין המרה אוטומטית לאופרטור הקנוני; מה שכן מנורמל בכתיבה הוא מטא‑שדות התצוגה. למרות זאת עדיף לכתוב חוקים חדשים עם האופרטורים הקנוניים, כי מול שרת ישן ערכי ה‑legacy נדחים בוולידציה.

שמונה הפעולות בסכימה: readonly · required · hidden · fixed-value · dynamic-value · formula-value · show-message · value-from-url.

AND הוא ברירת המחדל. OR דורש condOr: true על שני תנאים לפחות — תנאי בודד מסומן לא עושה כלום. ו‑conditions: [] פירושו שהכלל רץ תמיד — זה הניב של שיקוף שדות, אבל fixed-value תמידי בטעות דורס קלט של המשתמש בכל טעינת טופס.

מבקשות נפוצות לכללים

הבקשה	סקיצת הכלל
“שדה חובה רק כשסטטוס = X”	זוג כללים: hidden כשהסטטוס notEqualTo X, ו‑required כשהוא equalTo X
“תסתיר את השדות עד שנבחר סוג”	פעולות hidden (אחת לכל שדה) כל עוד שדה הסוג notEqualTo הערך המשחרר
“תנעל את הכרטיס אחרי סגירה”	קבוצת OR של סטטוסי סיום (condOr: true על 2+) ← readonly לכל שדה נעול
“העתק פרטים מהלקוח לטופס”	conditions: [] + dynamic-value לכל שדה ("AccountId.Email" — קפיצת Pointer אחת)
“תאריך סיום אוטומטי בסגירה”	סטטוס equalTo סגור ← fixed-value בערך "today"
“חובה רק עבור סוגים מסוימים”	containedIn עם מערך של objectIds ← required
“הצג אזהרה במצב רגיש”	תנאי על המצב ← show-message עם טקסט ההודעה
“אחראי ברירת מחדל = המשתמש”	conditions: [] + fixed-value בערך "currentUser" על ה‑Pointer ל‑_User
“קישור שממלא שדות מראש”	פעולת value-from-url

מה חוק טופס אינו

לא גבול אבטחה

hidden ו‑readonly אינם עושים כלום מול כתיבת API, ייבוא, או עדכון שמגיע מטריגר. אם הדרישה היא אכיפה — זה טריגר או CLP, לא חוק טופס. אמרו את זה ללקוח במפורש; זה ההבדל בין “המשתמש לא רואה” לבין “אי אפשר”.

הבקשה	לאן היא שייכת
פעולה בשמירה / מייל / יצירת רשומה / אכיפה בשרת	myb-p-trigger-setup
הוספה/הזזה של שדות, סקשנים, טאבים	myb-p-page-builder
מי רשאי לקרוא או לכתוב (CLP, תפקידים)	myb-p-users-roles-permissions
עמודות בטבלה, סינון, צביעת שורות	myb-p-page-tables
סינון אפשרויות בדרופ‑דאון לפי שדה אחר	myb-p-parent-child-fields — לא פעולת כלל, מנגנון ילידי

הזרימה

0. Get-Site-Pages                → איתור דף הכרטיס (יחיד = טופס, רבים = רשימה, Mobile-* = נייד)
1. Get-Form-Rules(pageId)        → גיבוי + ספירת בסיס
   Get-Schema(tableName)         → שמות וטיפוסי שדות מדויקים
   Get-Data(<lookup>)            → objectIds לערכי תנאי מסוג Pointer
2. ניסוח הכלל
3. הצגת תוכנית ואישור — לפני הכתיבה הראשונה
4. Edit-Form-Rules — קריאה אחת לכל כלל
5. Get-Form-Rules — קריאה חוזרת + בדיקת התנהגות בדפדפן

formId מוגדר כברירת מחדל לטופס הראשון בדף. יש בדף יותר מטופס אחד? מעבירים formId במפורש — הערך הוא ה‑id של אלמנט ה‑<form> כפי שהוא מופיע ב‑Get-Page-Content(minimal: true) (למשל P268; formId שאינו קיים מחזיר Form not found).

היקף הוא לכל דף ולכל טופס

דף הכרטיס הרגיל ודף ה‑Mobile-* של אותה ישות הם שני סטים נפרדים של כללים. שכפול נעשה במכוון, ובלי מעקב הם נפרדים בשקט. אותה טבלה על N דפים = N עותקים של כל כלל.

Set-Form-Rules — אם באמת חייבים

זה כותב‑מצב‑מלא. כתיבה עיוורת מוחקת כל כלל שלא כללתם:

1. backup = Get-Form-Rules(pageId)     // לשמור את ה-JSON המלא בצד
2. newRules = backup.rules ± השינויים  // למזג, אף פעם לא לכתוב מהזיכרון
3. Set-Form-Rules(pageId, rules: newRules)
4. Get-Form-Rules(pageId)              // לוודא ששום דבר לא אבד

אימות — קריאה חוזרת אינה מספיקה

Get-Form-Rules מוכיח אחסון, לא התנהגות. הכללים רצים בדפדפן בלבד, ואין יומן שרת של הערכת כללים. לכן צריך גם בדיקת התנהגות: לפתוח את הדף, רענון קשה (Ctrl+F5) — הגדרות הכללים נטענות עם הדף — ואז להפוך את שדה התנאי ולראות את הפעולה נכנסת ויוצאת.

הכלל לא ירה? בסדר הזה: דף שגוי (רגיל מול Mobile-*) · formId שגוי · לא היה רענון קשה · ערך התנאי הוא תווית תצוגה במקום objectId · condOr בודד · כלל אחר פועל על אותו שדה · ציפייה שהכלל יירה על כתיבת API.

מגבלות ידועות

• צד לקוח בלבד — required/readonly/hidden הם חוויה, לא שלמות נתונים.
• שכפול לפי דף וטופס — נפרדים בשקט.
• אין כללים מותנים לפי תפקיד — לתנאי יש רק field/equesition/value בסכימה. התנהגות לפי קהל דורשת הגדרות תפקיד ברמת הדף, או דפים נפרדים.
• אין סדר עדיפויות בין כללים על אותו שדה — הפעולות מצטברות (hidden בכלל אחד ו‑required בכלל אחר על אותו שדה → השדה גם מוסתר וגם חובה, בשני הסדרים — והטופס לא ניתן לשליחה). תכננו תנאים בלעדיים הדדית.
• formula-value הוא קופסה שחורה — התחביר לא מתועד בסכימה. המהלך הבטוח היחיד הוא העתקה מכלל חי שעובד.
• fixed-value על צ’קבוקס: הערך שמסמן הוא "checked"; "checkbox" ו‑"true" לא עושים דבר.
• dynamic-value — קפיצת Pointer אחת בלבד: "OwnerId.email" ו‑"SubDeptId.Name" עובדים; שתי קפיצות ("SubDeptId.DeptId.Name") מחזירות את ה‑objectId של ה‑Pointer הביניים, לא את השם.

---

myb-p-sla-configuration

מנגנון ה‑SLA של מודול הפניות בנוי משבעה חלקים שכולם חייבים להיות מוגדרים כדי שהוא באמת יאכוף משהו. חסר אחד — והמערכת נראית מוגדרת ולא עושה כלום.

#	החלק	מה הוא נותן
1	מינוח (_Dictionary)	תוויות בעברית לשדות ה‑SLA
2	מצבי פנייה (CaseStates + CaseStatuses.StateId)	קיבוץ סטטוסים לפתוח / סגור (במערכת חדשה קיימים שני אלה בלבד; “מושהה” מוסיפים ביישום). השעון רץ רק במצב “פתוח”
3	שעות עבודה (BusinessHours)	חלון שבוע העבודה + חגי ישראל + תאריכים מיוחדים
4	יעדים (SLASettings)	היעד עצמו, בשעות או בימים, לפי סוג / סוג+תת‑סוג / סוג+תת‑סוג+סטטוס
5	טריגרים שממלאים את שדות ה‑SLA	SLADeadline, ResponseTime, ResolutionTime
6	טבלת מעקב + ווידג’ט (CaseSLAProcess)	שורה לכל סטטוס — היסטוריית השעון על כרטיס הפנייה
7	הסלמה (טריגרים מתוזמנים + דוחות)	התראות לפני/אחרי חריגה, ודוחות שחושפים חריגות

הפער שחייבים להכיר לפני שמבטיחים ללקוח

מגבלה ידועה — הטבלאות הן מעטפת קונפיגורציה, אין מנוע ריצה

SLASettings ו‑BusinessHours, ודפי ההגדרות תחת הגדרות מערכת ← הגדרות פניות, הם מעטפות קונפיגורציה. אין מנוע ריצה שקורא את הטבלאות האלה וכותב SLADeadline / ResponseTime / ResolutionTime על הפניות (במערכת חדשה: שורת SLASettings + פנייה חדשה = אפס שדות SLA על הפנייה).

המסקנה המעשית: מי שמיישם SLA ללקוח חייב לבנות גם את הטריגרים שממלאים את השדות ומתחזקים את טבלת המעקב. SLASettings משמשת אז כתיעוד של כללי ה‑SLA ומקור לדוחות שמצטלבים איתה — אבל הטריגרים הם שמזיזים את הנתונים.

שדות ה‑SLA אינם בסכימה של מערכת חדשה — מוסיפים אותם בעצמכם

נתקלתם בטענה ש‑SLADeadline, ResponseTime, ResolutionTime, EstimatedResolution, IsEscalated, EscalationLevel, EscalatedTo הם “שדות פלטפורמה” שקיימים בכל מערכת? במערכת חדשה אף אחד מהם אינו קיים על Cases, וגם לא IsClosed (כפי שרואים ב‑Get-Schema), וטבלת CaseSLAProcess נוצרת רק בשלב 6. לפני שלב 5 מוסיפים את השדות ב‑Add-Field-to-Table (SLADeadline/ResponseTime/ResolutionTime/EstimatedResolution — Date; IsEscalated/IsClosed — Boolean; EscalationLevel — Number; EscalatedTo — Pointer ל‑_User). במערכות ותיקות שבהן הם כבר קיימים, תכונת ה‑dictionary שלצידם ב‑Get-Schema היא רק התווית המתורגמת, לא סימן ל“שדה מותאם”.

מה שואלים את הלקוח לפני שמתחילים

1. גרנולריות — היעד תלוי רק ב‑CaseType? ב‑CaseType + SubType? או גם בסטטוס?
2. ימים או שעות — SLADays או SLAHours. אחד לכל שורה, לא שניהם.
3. חלון העבודה — חלון שבועי יחיד + חגי ישראל + תאריכים חריגים. מקבילים אינם נתמכים.
4. מיפוי סטטוסים — סטטוסי “סגור”/“מושהה” ממופים ל‑CaseStates שאינם “פתוח”?
5. מדיניות הסלמה — מי מקבל התראה ומתי (למשל שעתיים לפני היעד; בחריגה). התבנית הדיפולטיבית מתריעה ל‑OwnerId; ל“מנהל” צריך objectId ספציפי או תפקיד.
6. עומק חישוב ימי העסקים — התבנית הפשוטה מוסיפה ימים קלנדריים. חישוב ימי עסקים אמיתי (דילוג על סופי שבוע וחגי ישראל) דורש פעולת server-side-code. מאשרים עם הלקוח שקלנדרי מספיק ל‑v1, או שמערבים מפתח.

תשעת השלבים

#	השלב	קובץ הייחוס בסקיל
1	אימות תנאים מקדימים — CaseTypes/CaseSubTypes/CaseStatuses/CaseStates מלאים, וכל סטטוס עם StateId	prerequisites.md
2	תרגומי _Dictionary לכל השדות	dictionary-setup.md
3	שורת BusinessHours יחידה	business-hours.md
4	שורה אחת ב‑SLASettings לכל כלל	sla-settings.md
5	שלושת טריגרי המילוי	sla-triggers.md
6	טבלת CaseSLAProcess + שני טריגרים + ווידג’ט על הכרטיס	case-sla-process-table.md
7	שני טריגרים מתוזמנים — אזהרה וחריגה	escalation-triggers.md
8	שלושת הדוחות הסטנדרטיים	sla-reports.md
9	אימות על פנייה אמיתית	verify-and-troubleshoot.md

שלושת הדוחות: דוח SLA — כללי (כל הפניות עם כל השדות) · חריגות פניות פתוחות (IsClosed = false, ממוין לפי SLADeadline עולה) · חריגות פניות סגורות (IsClosed = true, ממוין לפי ResolutionTime יורד).

הווידג’ט על הכרטיס עובר דרך סקיל אחר — במפורש

שלב 6ג משבץ טבלת CaseSLAProcess על דף הפנייה, תמיד דרך myb-p-page-tables. הסיבה: אותו סקיל מתעד את דרישת ה‑aggrField, את מלכודת המיקום (ווידג’ט שמתקנן בתוך מיכל טאבים ומציג 0 רשומות), ואת השלמת ה‑Edit-Table-View.

איך יודעים אם פנייה עמדה ב‑SLA

התנאי על שורת הפנייה	המשמעות
ResponseTime קיים ו‑ResponseTime <= SLADeadline	עמדה — המענה הראשון הגיע לפני היעד
ResponseTime קיים ו‑ResponseTime > SLADeadline	חריגה — המענה הגיע, באיחור
ResponseTime ריק, SLADeadline < now, IsClosed = false	בחריגה כרגע
ResponseTime ריק ו‑SLADeadline >= now	בתוך התקציב

התצוגה לפי סטטוס מגיעה מ‑CaseSLAProcess: לכל שורה יש StatusEnteredAt, StatusExitedAt, DeadlineForStatus ודגל IsBreached — כלומר היסטוריית ההעברות המלאה, עם יעדים.

ביקורת על מערכת קיימת

Get-Data(table: "SLASettings", limit: 100)
Get-Data(table: "BusinessHours", limit: 5)
Get-Data(table: "CaseStates", limit: 20)
Get-Data(table: "CaseStatuses", keys: ["Name", "StateId"], limit: 50)
Get-Triggers(tableName: "Cases")
Get-Schema(className: "CaseSLAProcess")
Get-Reports()
Count-Data(table: "Cases", where: { "SLADeadline": { "$exists": true } })
Count-Data(table: "CaseSLAProcess")

התרחיש החוזר: ללקוח “יש SLA” כי דפי הניהול קיימים ול‑SLASettings יש שורות — אבל Count-Data על פניות עם SLADeadline מחזיר 0. פירושו שהטריגרים חסרים: מישהו הניח שהמנוע מחובר.

בקשות נפוצות

הבקשה	התשובה
“טבלת היסטוריית SLA על כרטיס הפנייה”	CaseSLAProcess — שלב 6
“SLA של 4 שעות לפניות VIP”	שורה ב‑SLASettings עם SLAHours = 4 ו‑CaseTypeId תואם + ודאו שטריגר שלב 5 מכסה את הסוג
“SLA לא ירוץ בסופי שבוע וחגים”	זה ב‑BusinessHours — אבל הטריגר הפשוט createdAt + N ימים לא מתייעץ איתו. דילוג על סופי שבוע דורש server-side-code
“הפנייה סגורה אבל ה‑SLADeadline עדיין מוצג כחורג”	SLADeadline הוא ערך מחושב סטטי — הוא לא “מתנקה” בסגירה. הדוחות מסננים לפי IsClosed
“התראות למנהל במקום לאחראי”	בטריגרי שלב 7, userType מ‑field/OwnerId ל‑fixed/<objectId של המנהל>

דברים לשים לב אליהם

• המנוע לא רץ מעצמו — קונפיגורציה לבדה לא מחשבת דבר.
• קלנדרי מול ימי עסקים — התבנית הפשוטה מוסיפה ימים קלנדריים.
• קדימות גרנולריות — כללים עם יותר Pointers ספציפיים יותר. קדימות מלאה דורשת server-side-code; הטריגר הפשוט עם timeGap משתמש בערך קבוע אחד.
• חלון שעות עבודה אחד בלבד. אל תנסו למדל שתי משמרות כשתי שורות.
• לא לקבוע גם SLAHours וגם SLADays באותה שורה.

---

המשך

• כלי טריגרים ואוטומציות ב‑MCP — סכימת הכלים המלאה
• סקילים — דפים וממשק — הדפים שחוקי הטופס יושבים עליהם
• סקילים — נתונים ואינטגרציות — טריגרים בזמן ייבוא, והדוחות של ה‑SLA
• עבודה בטוחה עם סוכן על מערכת חיה