מסמך זה תורגם על ידי בינה מלאכותית. לכל אי דיוק, אנא עיין בגרסה האנגלית
כאשר תהליך עסקי אינו יכול לקבל החלטות באופן אוטומטי לחלוטין, ניתן להשתמש בצומת (node) ידני כדי להאציל חלק מסמכות קבלת ההחלטות לאדם.
כאשר צומת ידני מופעל, הוא קוטע את ביצוע תהליך העבודה כולו ומייצר משימת "לביצוע" (to-do) עבור המשתמש המתאים. לאחר שהמשתמש שולח את המשימה, תהליך העבודה ימשיך, יישאר בהמתנה, או יסתיים, בהתאם לסטטוס שנבחר. זה שימושי מאוד בתרחישים כמו תהליכי אישור.
תוסף מובנה, אין צורך בהתקנה.
בממשק הגדרות תהליך העבודה, לחצו על כפתור הפלוס ("+") בתהליך העבודה כדי להוסיף צומת "טיפול ידני":

צומת ידני דורש הגדרת משתמש כאחראי על ביצוע משימת ה"לביצוע". את רשימת משימות ה"לביצוע" ניתן להוסיף כבלוק בעמוד, ותוכן חלון קופץ של משימה עבור כל צומת צריך להיות מוגדר בהגדרות הממשק של הצומת.
בחרו משתמש, או בחרו את מפתח ראשי (primary key) או מפתח זר (foreign key) של נתוני משתמש מההקשר באמצעות משתנה.

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

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

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

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

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

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


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

דוגמה לבלוק רשימת "לביצוע":

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

נניח שפוסט שנשלח על ידי משתמש רגיל צריך להיות מאושר על ידי מנהל מערכת לפני שניתן לעדכן אותו למצב "פורסם". אם תהליך העבודה נדחה, הפוסט יישאר במצב "טיוטה" (לא ציבורי). תהליך זה יכול להיות מיושם באמצעות טופס עדכון בצומת ידני.
צרו תהליך עבודה המופעל על ידי "יצירת פוסט" והוסיפו צומת ידני:
בצומת הידני, הגדירו את האחראי כמנהל מערכת. בהגדרות הממשק, הוסיפו בלוק המבוסס על נתוני הטריגר כדי להציג את פרטי הפוסט החדש:
בהגדרות הממשק, הוסיפו בלוק המבוסס על טופס עדכון רשומה, בחרו את אוסף הפוסטים, כדי שהמנהל יחליט אם לאשר. לאחר האישור, הפוסט המתאים יעודכן בהתבסס על הגדרות נוספות בהמשך. לאחר הוספת הטופס, יהיה כפתור "המשך תהליך עבודה" כברירת מחדל, אותו ניתן לראות כ"אישור". לאחר מכן, הוסיפו כפתור "סיים תהליך עבודה" שישמש לדחייה:
כאשר ממשיכים את תהליך העבודה, עלינו לעדכן את סטטוס הפוסט. ישנן שתי דרכים להגדיר זאת. אחת היא להציג את שדה הסטטוס של הפוסט ישירות בטופס לבחירת המפעיל. שיטה זו מתאימה יותר למצבים הדורשים מילוי טופס אקטיבי, כגון מתן משוב:
כדי לפשט את משימת המפעיל, דרך נוספת היא להגדיר הקצאת ערך לטופס בכפתור "המשך תהליך עבודה". בהקצאה, הוסיפו שדה "סטטוס" עם הערך "פורסם". משמעות הדבר היא שכאשר המפעיל ילחץ על הכפתור, הפוסט יעודכן למצב "פורסם":
לאחר מכן, מתפריט ההגדרות בפינה הימנית העליונה של בלוק הטופס, בחרו את תנאי הסינון עבור הנתונים שיש לעדכן. כאן, בחרו את אוסף "פוסטים", ותנאי הסינון הוא "מזהה שווה ל משתנה טריגר / נתוני טריגר / מזהה":
לבסוף, תוכלו לשנות את הכותרות של כל בלוק, את הטקסט של הכפתורים הרלוונטיים, ואת טקסט הטיפים של שדות הטופס כדי להפוך את הממשק לידידותי יותר למשתמש:
סגרו את לוח ההגדרות ולחצו על כפתור השליחה כדי לשמור את הגדרות הצומת. תהליך העבודה כעת מוגדר. לאחר הפעלת תהליך עבודה זה, הוא יופעל אוטומטית כאשר פוסט חדש נוצר. המנהל יכול לראות שתהליך עבודה זה דורש טיפול מרשימת משימות ה"לביצוע". לחיצה לצפייה תציג את פרטי משימת ה"לביצוע":
המנהל יכול לבצע שיקול דעת ידני בהתבסס על פרטי הפוסט כדי להחליט אם ניתן לפרסם את הפוסט. אם כן, לחיצה על כפתור "אישור" תעדכן את הפוסט למצב "פורסם". אם לא, לחיצה על כפתור "דחה" תשמור את הפוסט במצב "טיוטה".
נניח שעובד צריך לבקש חופשה, שחייבת להיות מאושרת על ידי מנהל כדי להיכנס לתוקף, ונתוני החופשה של העובד המתאים צריכים להיות מנוכים. ללא קשר לאישור או דחייה, צומת בקשת HTTP ישמש לקריאת API של SMS כדי לשלוח הודעת התראה לעובד (ראו את סעיף בקשת HTTP). תרחיש זה יכול להיות מיושם באמצעות טופס מותאם אישית בצומת ידני.
צרו תהליך עבודה המופעל על ידי "יצירת בקשת חופשה" והוסיפו צומת ידני. זה דומה לתהליך סקירת הפוסט הקודם, אך כאן האחראי הוא המנהל. בהגדרות הממשק, הוסיפו בלוק המבוסס על נתוני הטריגר כדי להציג את פרטי בקשת החופשה החדשה. לאחר מכן, הוסיפו בלוק נוסף המבוסס על טופס מותאם אישית כדי שהמנהל יחליט אם לאשר. בטופס המותאם אישית, הוסיפו שדה לסטטוס האישור ושדה לסיבת הדחייה:
בניגוד לתהליך סקירת הפוסט, מכיוון שעלינו להמשיך את התהליך הבא בהתבסס על תוצאת אישור המנהל, אנו מגדירים כאן רק כפתור "המשך תהליך עבודה" לשליחה, מבלי להשתמש בכפתור "סיים תהליך עבודה".
במקביל, לאחר הצומת הידני, אנו יכולים להשתמש בצומת תנאי כדי לקבוע אם המנהל אישר את בקשת החופשה. בענף האישור, הוסיפו עיבוד נתונים לניכוי חופשה, ולאחר מיזוג הענפים, הוסיפו צומת בקשה לשליחת הודעת SMS לעובד. זה מביא לתהליך עבודה השלם הבא:
התנאי בצומת התנאי מוגדר כ"צומת ידני / נתוני טופס מותאם אישית / ערך שדה האישור הוא 'אושר'":
הנתונים בצומת שליחת הבקשה יכולים גם להשתמש במשתני הטופס המתאימים מהצומת הידני כדי להבחין בין תוכן ה-SMS לאישור ולדחייה. זה משלים את הגדרת תהליך העבודה כולו. לאחר הפעלת תהליך העבודה, כאשר עובד שולח טופס בקשת חופשה, המנהל יכול לטפל באישור במשימות ה"לביצוע" שלו. הפעולה דומה באופן עקרוני לתהליך סקירת הפוסט.