כשמגיעות פניות מסוגים שונים, צריך כלל ברור שקובע לאן כל אחת ממשיכה. במדריך הזה נבנה Router שמפריד בין שאלה על מדריך, בעיה טכנית והצעת תיקון, ושומר מסלול נוסף לכל מה שלא מתאים. נלמד את הניתוב עם נתוני לימוד של מאיץ ומשתנים בתוך Make, לפני שמחברים אותו למערכת חיצונית.
התרחיש והצילומים כאן נבדקו בחשבון Make ב־4 באוקטובר 2026. בוצעו שבע הרצות ידניות של התרחיש המלא: כל אחת הגיעה למסלול המתאים, כולל קטגוריה ריקה ומזהה שמכיל רווחים בלבד. התזמון נשאר כבוי. הבדיקה השתמשה ב־Tools וב־Router בלבד; ההרחבה ל־Google Sheets שבהמשך לא הורצה.
מה בונים
המידע עובר מ־Sample source אל Normalize category ומשם אל Router. המקור מספק request_id ו־request_type. המודול השני מנקה את הקטגוריה. שלושה ענפים רגילים בודקים התאמה מדויקת, והענף הרביעי, Needs review, הוא fallback. בסוף כל ענף מודול Tools מחזיר route_result, כך שרואים לאן הנתון הגיע בלי לשלוח הודעה.
1. מכינים שני שדות לימוד
צרו תרחיש בדיקה והוסיפו Tools > Set variables. תנו למודול את השם Sample source, והוסיפו request_id עם MAITZ-ROUTE-001 ו־request_type עם Guide_Question ורווח בסופו. אין כאן פרטי פונה אמיתי. השאירו את מתג התזמון כבוי; Run once יבצע הרצה ידנית אמיתית ועשוי לצרוך קרדיטים. בדקו את המכסה בחשבון לפני הניסוי.
שמרו את המודול ואת התרחיש. כשפותחים בהמשך את בועת הפלט של המקור, שני השדות צריכים להופיע בנפרד. אם מופיע רק ערך אחד, חזרו לרשימת המשתנים והוסיפו את הפריט החסר.
2. מנרמלים את הקטגוריה לפני הפיצול
הוסיפו Tools > Set variable בשם Normalize category. בשדה Variable name כתבו category_key. בשדה Variable value בנו lower(trim(ifempty(request_type; ""))), כאשר request_type הוא אסימון ממופה של Sample source. בדוגמה המצולמת מספר מודול המקור הוא 2; אצלכם הוא עשוי להיות אחר. ifempty נותן ערך ריק כשאין קטגוריה, trim מסיר רווחים בקצוות, ו־lower הופך אותיות לקטנות.
התוצאה עבור Guide_Question עם רווח בסוף היא guide_question. אם מתקבל הטקסט request_type עצמו, הוזן שם השדה כטקסט קבוע במקום מיפוי. בממשק שנבדק היו Variable name ו־Variable value בלבד, בלי הגדרת lifetime. אין צורך לחפש One cycle; האפשרות הוסרה ב־1 באוקטובר 2026.
3. מגדירים שלוש התאמות שאינן חופפות
הוסיפו Router אחרי הנרמול ושלושה ענפים רגילים. לחצו על החיבור של הענף הראשון כדי לפתוח Set up a filter. כתבו Guide question ב־Label והשאירו את אפשרות fallback על No. בתנאי הראשון מפו category_key, בחרו Text operators: Equal to והקלידו guide_question. באמצעות Add AND rule הוסיפו length(trim(request_id)), בחרו Numeric operators: Greater than והזינו 0. גם request_id מגיע כאסימון מהמקור.
בשני הענפים הבאים השתמשו באותו מבנה: Technical issue עם technical_issue, ו־Correction עם correction. שמרו כל פילטר באמצעות Save. ההתאמות המדויקות הופכות את הקטגוריות לנפרדות. Contains או OR עלולים לאפשר לאותו פריט לעבור ביותר מענף אחד; סדר המסלולים אינו כלל של “עצור בהתאמה הראשונה”.
4. מוסיפים fallback למה שלא התאים
הוסיפו ענף רביעי ופתחו את הפילטר שלו. הגדירו Label בשם Needs review ובחרו Yes באפשרות Set the route as a fallback. השאירו אותו בלי תנאי נוסף ולחצו Save. הוא יקבל נתון שלא עבר באף מסלול רגיל, כולל סוג לא מוכר או מזהה שאחרי trim נשאר ריק.
Fallback מטפל באי־התאמה לתנאים. הוא אינו מתקן שגיאה של מודול או כשל בשירות חיצוני. אם נתון לא מוכר לא מגיע למסלול הזה, ודאו ש־Yes אכן נשמר ושלא נוסף תנאי מצמצם.
5. נותנים לכל מסלול פלט שקל לזהות
בסוף כל ענף הוסיפו Tools > Set variable. בכל הארבעה הגדירו Variable name בשם route_result. הערכים הקבועים, לפי הסדר, הם guide_queue, technical_queue, corrections_queue ו־manual_review. לצורך קריאות תנו גם למודולים את השמות האלה. שמרו את התרחיש ולחצו Run once.
פתחו את בועת הפלט מעל Sample source ואחר כך מעל המודול שבסוף המסלול שעבר. בבדיקה הראשונה התקבל guide_queue. בדקו את Output עצמו, לא רק סימון ירוק. אם שני מודולי סיום פעלו, חזרו לפילטרים וחפשו תנאי חסר או OR במקום AND.
6. בודקים גם ערכים לא תקינים
בכל ניסיון משנים רק את שדות המקור, שומרים ומריצים פעם אחת. אלה התוצאות שנצפו בשבע הבדיקות של התרחיש המלא:
- Guide_Question (רווח בסוף); MAITZ-ROUTE-001 → guide_queue
- technical_issue; MAITZ-ROUTE-002 → technical_queue
- other; MAITZ-ROUTE-003 → manual_review
- correction; MAITZ-ROUTE-004 → corrections_queue
- קטגוריה ריקה; MAITZ-ROUTE-005 → manual_review
- guide_question; מזהה של שלושה רווחים → manual_review
- guide_question,correction; MAITZ-ROUTE-007 → manual_review
בבדיקת המזהה הריק חזותית הוזנו שלושה אסימוני space, כי העורך חתך רווחים שהוקלדו כפשוטם. כל המסלולים הרגילים נדחו, והפלט היה manual_review. לכן גם קטגוריה מוכרת אינה מספיקה כאשר אין מזהה תקין. אלה בדיקות ניתוב נקודתיות, ולא בדיקת עומס או הבטחה לכל סוג קלט אפשרי.
7. הרחבה לגיליון: שלב נפרד שדורש בדיקה
לאחר שהכללים ברורים, אפשר לתכנן החלפה של Sample source ב־Google Sheets > Watch New Rows, ושל מודולי הסיום ב־Update a Row. ההרחבה הזאת לא בוצעה במדריך. היא דורשת חיבור מורשה וגיליון בדיקה. שמרו את request_id ואת request_type המקוריים, והוסיפו שדות תוצאה כמו routed_to ו־routing_version. מפו את מספר השורה מהטריגר ובדקו שהמזהה באותה שורה עדיין תואם לפני כתיבה.
מספר שורה הוא מיקום זמני. אל תמיינו, תזיזו או תמחקו שורות בזמן העיבוד. כשיש עורכים נוספים צריך למנוע דריסה של שינוי חדש. ודאו גם שמישהו מטפל בפריטי manual_review: ניתוב לתור אינו טיפול בפנייה.
קובצי תרגול ומקורות
החבילה המעודכנת כוללת CSV ו־JSON של שבע הבדיקות ותיאור התוצאות שנצפו. אלה קבצים מקוריים שהוכנו מקומית, לא Blueprint רשמי או קובץ ליבוא אוטומטי ל־Make.
הורדת קובצי תרגול Router המעודכנים
חבילת Make הקודמת נשארת זמינה. דוגמאות ה־Router שבה משתמשות ב־sales, billing ו־support ומתעדות ציפיות בלבד; הן שונות מהתרגיל המצולם כאן.
לשיקולי התאמה, מכסה ותחזוקה קראו את סקירת Make לעסקים קטנים.
מקורות רשמיים: Router, Scenario variables, Cycles removal on October 1, 2026.
התוצאה השימושית של התרגיל היא כלל ניתוב שאפשר להסביר ולבדוק. השאירו את תרגיל הלימוד ללא תזמון קבוע, ושנו את ערכי המקור בכוונה כדי להבין מתי מופעל כל ענף.
