> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tedro.io/llms.txt
> Use this file to discover all available pages before exploring further.

# בונה תהליכי עבודה

> בניית אוטומציות עם קנבס ויזואלי מבוסס צמתים ב-Tedro.

# בונה תהליכי עבודה

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

## דרישות מוקדמות

* סביבת עבודה ב-Tedro עם תפקיד **Admin**
* לפחות ערוץ מחובר אחד (לבדיקת תהליכי עבודה)

## פריסת הקנבס

לבונה תהליכי העבודה ארבעה אזורים עיקריים:

| אזור           | מיקום                 | תפקיד                                       |
| -------------- | --------------------- | ------------------------------------------- |
| **לוח צמתים**  | סרגל צד שמאלי (280px) | גררו צמתים מכאן אל הקנבס                    |
| **קנבס**       | מרכז                  | שטח העבודה הראשי לבניית הזרימה              |
| **Inspector**  | פאנל ימני (360px)     | הגדרת הצומת הנבחר                           |
| **סרגל עליון** | עליון (56px)          | שם התהליך, סטטוס שמירה, תצוגה מקדימה ופרסום |

## בניית תהליך עבודה

<Steps>
  ### יצירת תהליך עבודה

  עברו אל **Workflows** בסרגל הצד ולחצו על **Create Workflow**. הזינו שם ולחצו **Create**. הבונה נפתח עם קנבס ריק.

  ### הוספת צומת טריגר

  כל תהליך מתחיל בטריגר. גררו צומת טריגר מקטגוריית **Triggers** בלוח הצמתים אל הקנבס. הטריגר הנפוץ ביותר הוא **Inbound Message** -- הוא מופעל כשלקוח שולח הודעה בכל ערוץ. לתהליכים ספציפיים לערוץ, השתמשו ב-**WhatsApp Message**, **Instagram Message**, **Messenger Message** או **Live Chat Message**.

  <Note>
    לכל תהליך עבודה חייב להיות בדיוק צומת טריגר אחד. הבונה אוכף זאת -- לא ניתן לפרסם תהליך ללא טריגר.
  </Note>

  ### הוספת צמתי עיבוד

  גררו צמתים נוספים אל הקנבס לבניית לוגיקת האוטומציה:

  * **AI Agent** -- תנו ל-AI לטפל בשיחה עם כלים וידע
  * **Condition** (logic.switch) -- הסתעפו בזרימה על בסיס תוכן ההודעה, נתוני איש הקשר או קריטריונים אחרים
  * **Set Field** -- שמרו נתונים ברשומת איש הקשר או השיחה
  * **Rate Limit** -- הגבילו קצב ביצוע לשליטה בעלויות ומניעת ספאם

  ### חיבור צמתים

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

  לצמתי Condition יש מספר ידיות יציאה -- אחת לכל ענף ועוד ברירת מחדל. חברו כל ענף לשלב הבא המתאים.

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

  בסוף הזרימה, הוסיפו צמתי פעולה לתקשורת עם הלקוח:

  * **Send Message** (לפי ערוץ: WhatsApp, Instagram, Messenger או Live Chat) -- השיבו ללקוח
  * **Send Template** (WhatsApp בלבד) -- שלחו תבנית מאושרת מראש
  * **Handoff to Human** (לפי ערוץ) -- העלו לנציג אנושי בתיבת הדואר

  ### הגדרת כל צומת

  לחצו על צומת כלשהו בקנבס כדי לפתוח את פאנל **Inspector** מימין. לכל סוג צומת אפשרויות הגדרה משלו (system prompt, תנאים, טקסט הודעה וכדומה). עיינו ב-[הפניות לצמתים](/he/nodes/trigger-nodes) לפרטי ההגדרות של כל סוג צומת.

  ### הוספת צומת סיום

  השתמשו בצומת **End** (logic.end) לסיום מפורש של נתיבי ביצוע. אמנם לא חובה (תהליכים עוצרים כשאין עוד צמתים מחוברים), אך צמתי End מקלים על קריאה ואיתור באגים.
</Steps>

## טיוטה מול מפורסם

לתהליכי עבודה שני מצבים:

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

<Warning>
  פרסום יוצר גרסה חדשה של תהליך העבודה. הגרסה המפורסמת הקודמת מוחלפת. ודאו שבדקתם את הטיוטה לפני הפרסום.
</Warning>

### פרסום תהליך עבודה

לחצו על **Publish** בסרגל העליון. הבונה מריץ בדיקות תקינות לפני הפרסום (ראו להלן). אם התקינות עוברת, הטיוטה הנוכחית הופכת לגרסה המפורסמת הפעילה.

## כללי תקינות

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

| כלל                   | תיאור                                                                                                   |
| --------------------- | ------------------------------------------------------------------------------------------------------- |
| **טריגר יחיד**        | חייב להיות בדיוק צומת טריגר אחד                                                                         |
| **אין צמתים מבודדים** | כל צומת חייב להיות נגיש מהטריגר דרך חיבורים                                                             |
| **קיים נתיב handoff** | לפחות צומת `handoff` אחד חייב להיות נגיש מהטריגר (מבטיח שלקוחות תמיד יכולים להגיע לנציג אנושי)          |
| **שדות חובה מלאים**   | שדות הגדרה נדרשים ספציפיים לצומת חייבים להיות מלאים (לדוגמה, AI Agent צריך system prompt או סוכן מקושר) |

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

## תצוגה מקדימה ובדיקה

השתמשו בכפתור **Preview** בסרגל העליון כדי לבדוק את הטיוטה ללא פרסום. התצוגה המקדימה מריצה את התהליך עם נתונים מדומים כדי שתוכלו לוודא את הלוגיקה לפני שיוצאים לאוויר. אפשר גם להשתמש בצומת `trigger.manual_test` במהלך הפיתוח לאיטרציה מהירה.

## מה הלאה

<CardGroup cols={2}>
  <Card title="צמתי Trigger" icon="play" href="/he/nodes/trigger-nodes">
    למדו על סוגי הטריגרים השונים שמפעילים את תהליכי העבודה.
  </Card>

  <Card title="סוכני AI" icon="robot" href="/he/automation/ai-agents">
    הגדירו סוכני AI שמטפלים בשיחות באופן עצמאי בתוך תהליכי עבודה.
  </Card>
</CardGroup>