הודעות חוזרות ב־Slack: Workflow חוסך בניית בוט, לא ניהול הרשאות

לשליחת הודעה מחזורית לערוץ Slack, התחילו ב־Workflow אם אפשר לקבוע מראש את הנוסח, הערוץ והתדירות. תבנית ההודעות המחזוריות של Slack מאפשרת להגדיר את שלושתם ולפרסם את התהליך בלי לפתח אפליקציה. עדיין צריך לדאוג להרשאת פרסום בערוץ ולמי שיוכל לתחזק את ההודעה.

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

מתי התבנית מספיקה ומתי צריך אפליקציה?

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

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

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

הקמת הודעה מחזורית ב־Workflow

במחשב פותחים את Agents & tools בסרגל הצד, נכנסים ל־Workflows, בוחרים Templates ואז Send a scheduled message. אם הכרטיסייה Agents & tools אינה מופיעה, ייתכן שהיא מוצגת בשם Tools או נמצאת תחת More. התבנית מגיעה עם תזמון ושלב שליחת הודעה, ולכן אפשר להתחיל מהגדרת הפרטים שלה.

1. פותחים את שלב התזמון באמצעות סמל העיפרון הראשון. בוחרים מועד התחלה, שעה ותדירות ושומרים. לפני הפרסום מוודאים שהשעה מתאימה למי שאמורים לראות את ההודעה, בעיקר בערוץ שבו עובדים מאזורים שונים.
2. בסמל העיפרון הבא בוחרים את הערוץ מתוך הרשימה וכותבים את גוף ההודעה. כדאי שהבקשה תהיה מפורשת ושהקישור המצורף, אם יש כזה, יישאר שימושי גם בשליחה הבאה.
3. ב־Finish Up נותנים ל־Workflow שם שמבהיר את תפקידו. עוברים על הערוץ, התזמון, הנוסח, המנהלים וההרשאות ורק אז בוחרים Publish.

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

הרשאות ובעלות לפני הפרסום

מדריך Workflow Builder של Slack מציין שיצירת Workflow זמינה כברירת מחדל לחברים בתוכנית בתשלום, אך בעלי המרחב ומנהליו יכולים להגביל גישה. כדי להגדיר שלב ששולח הודעה לערוץ, ליוצר דרושה הרשאת פרסום באותו ערוץ. אם ההרשאה חסרה, יש לבקש אותה מבעלים או ממנהל מורשה לפני ההגדרה.

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

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

מה משתנה במסלול ה־API?

תיעוד השליחה והתזמון של Slack קובע שאפליקציה זקוקה להרשאת chat:write כדי לשלוח הודעה מתוזמנת, ושאפשר לקבוע את שליחתה עד 120 יום מראש. אם האפליקציה צריכה לאתר מזהים של ערוצים ציבוריים, ייתכן שתזדקק גם ל־channels:read. אלה הרשאות של האפליקציה, ולא הרשאות הניהול של Workflow Builder.

לשליחה מיידית משתמשים ב־chat.postMessage; לקביעת מועד של הודעה מסוימת משתמשים ב־chat.scheduleMessage עם post_at. הקריאה השנייה אינה יוצרת לבדה כלל שחוזר מדי שבוע. לכן, אפליקציה ששולחת תזכורת מחזורית צריכה להחליט מתי ליצור את ההודעה הבאה: לתזמן מופעים נוספים מראש בתוך חלון הזמן המותר, או להפעיל תהליך שמוסיף אותם בהמשך.

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

שינוי או עצירה בלי להשאיר הודעה ממתינה

ב־Workflow, מנהל מורשה יכול לערוך תהליך שכבר פורסם, לרבות שלב ההודעה וההרשאות. כשצריך להפסיק את המחזור, הוא יכול להסיר את התהליך מפרסום או למחוק אותו. עריכה של הודעה שכבר נשלחה לערוץ אינה משנה את המקור שמייצר את השליחות הבאות; השינוי צריך להיעשות ב־Workflow עצמו.

באפליקציה, תגובת chat.scheduleMessage מחזירה scheduled_message_id לכל הודעה שתוזמנה. אפשר למצוא הודעות ממתינות של האפליקציה גם באמצעות chat.scheduledMessages.list, ואז לבטל מופע בעזרת chat.deleteScheduledMessage. כדי לשנות הודעה שטרם נשלחה, מבטלים את התזמון הקיים וקובעים הודעה חדשה עם הפרטים המתוקנים.

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