לחשוב מחוץ לטופס: Fillout הוא לא טופס - הוא מערכת שלמה מעל בסיס נתונים
רובנו רואים ב-Fillout "עוד Google Form" - שדה, שדה, שלח. עוז רוט הראה שזו טעות שמשאירה 90% מהכוח על השולחן: Fillout הוא כלי לבניית תהליכים עסקיים שלמים, מיני-אתרים ופורטלים, כשהדאטה חי בבסיס נתונים חיצוני והטופס הוא רק שכבת ה-UI מעליו. הוא לימד ארבעה כלים שהופכים טופס למערכת - Record Picker, חישובים על סטים, Prefetch, ו-Redirect - ואיך בונים איתם פורטל שלם. 8 הפרומפטים למטה מלמדים אתכם לחשוב מחוץ לטופס.
הערת הכתבת: הסשן הזה (5.11.2024) הוא צלילה עמוקה ל-Fillout, כלי שחי ומצוין ויקר ללב שלנו - הפוסט הראשון בכלל בסדרה הזו היה על פורטל Fillout אישי (סשן #1 של אוטוטיוזדיי). הטכניקות שעוז לימד - Record Picker, טבלה מקשרת, פורטל עם Redirect, Prefetch - עדיין עובדות, אם כי שווה לאמת את מדרגות התוכניות והפיצ'רים העדכניים (חלקם בתשלום). אבל מעל הכלי יש כאן שיעור נצחי: להפסיק לחשוב על "טופס" ולהתחיל לחשוב על מערכת מעל בסיס נתונים - טבלאות מקשרות, מבנה רלציוני, human-in-the-loop, ובעיקר הגודל הנכון (עוז עצמו עצר ואמר: לפעמים Make פשוט יותר לתחזק). זה נכון בכל כלי בונה-בלי-קוד. הפרומפט הפתוח למטה עוזר לתכנן תהליך עסקי כמערכת, לא כטופס שטוח.
"תבנה לי טופס" - וכולם רצים לבנות שדות. עוז רוט הגיע למפגש ה-18 של אוטוטיוזדיי כדי לשבור את התפיסה הזו. כי Fillout, כשמבינים אותו נכון, הוא לא כלי לאסוף תשובות - הוא שכבת ממשק חיה מעל בסיס נתונים, שקוראת וכותבת רשומות בזמן אמת, מנתבת משתמשים בין מסכים, ובונה פורטלים שלמים. זה סשן לבנאים שרוצים להפסיק לבנות טפסים ולהתחיל לבנות מערכות. וזה הסשן שסוגר מעגל עם הראשון בסדרה - שגם הוא היה על פורטל Fillout אישי.
המסע: 8 תחנות
כל תחנה = מה קרה בסשן + הפרומפט שאורז את זה בשבילכם
לחשוב על Fillout כמערכת ולא כטופס
עוז פתח מה-reframe שמשנה הכל: רוב האנשים קוראים ל-Fillout 'פלטפורמת טפסים' וחושבים עליו כמו Google Form, וזו טעות שמגבילה אותם. בפועל Fillout הוא כלי לבניית תהליכים עסקיים שלמים, כשהדאטה חי בבסיס נתונים חיצוני (בדרך כלל Airtable) והטופס הוא רק שכבת ה-UI מעליו. ההבדל המעשי: בטופס רגיל אוספים תשובות; ב-Fillout קוראים וכותבים רשומות בזמן אמת, מסננים דינמית, מחשבים על מערכים, ומנתבים משתמשים לפי תנאים. עוז נתן את ארבעת הכלים שהופכים טופס למערכת: Record Picker (בחירת רשומות מקושרות), Calculations (חישובים על סט שלם), Prefill/Prefetch (משיכת נתונים לפני שהטופס נטען), ו-Page Logic + Redirect (ניתוב דינמי). ההבנה הזו לבד - שהטופס הוא ממשק ולא מאגר - פותחת עולם.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
לתכנן Record Pickers דינמיים (פיקר שמשפיע על פיקר)
עוז צלל ל-Record Picker, שהוא לדעתו הכלי החזק ביותר ב-Fillout: בחירת רשומות מקושרות מבסיס הנתונים. והיכולות שהוא פרש מרשימות: דינמיות (אותו פיקר מחזיק בחירה אחת או עשרים, כל משתמש בונה רשימה באורך שונה, עם מינימום/מקסימום), פילטור (להציג רק את מה שרלוונטי לפי ערך בעמודה או View), והחזק מכולם - פיקר שמשפיע על פיקר: שדה 'אשכול' מסנן את שדה 'רשויות', כך שאחרי בחירת אשכול רשימת הרשויות מציגה רק את מה שמקושר אליו. וזה עובד רק אם מבנה הנתונים מקושר נכון מלכתחילה. עוז הוסיף גם דפוס חכם - לאפשר למשתמש להוסיף רשומה חדשה, אבל עם Human in the Loop: שדה נסתר 'נוסף על ידי לקוח', הפיקר מציג רק מאושרות, ואדם מאשר לפני שזה עולה לכולם. הכוח כאן הוא בדיוק במבנה הנתונים שמאחורי הפיקר.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
לבנות מבנה נתונים נכון עם טבלה מקשרת (Junction Table)
וכאן עוז לימד את המושג שמפריד בין מי שבונה טפסים למי שבונה מערכות: טבלה מקשרת (Junction Table). הטעות הנפוצה - לקשר ישירות בין שתי טבלאות: 'הזמנות' ישירות ל'מוצרים'. הבעיה - אי אפשר להגיד 'מהג'ינס אני רוצה 5 ומהחולצה 7', או לציין צבע ומידה לכל פריט, כי לקישור עצמו אין מקום לאחסן נתונים. הפתרון: טבלה שלישית באמצע - 'פריטי הזמנה' - שכל רשומה בה מקושרת להזמנה אחת ולמוצר אחד, ומחזיקה את מה שמתאר את הקשר: צבע, מידה, כמות, מחיר ברגע ההזמנה. ב-Fillout זה תת-טופס (Subform) שמתווסף דינמית. עוז הראה שאפשר להפוך את זה ל'טופס חכם' עם טבלאות מלאי - הזמנה מורידה מהמלאי, והפיקר מסונן להציג רק מה שקיים. זו לא דקדוק טכני - זה ההבדל בין מבנה שמתפרק למבנה שמנהל עסק אמיתי.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
חישובים על סטים של נתונים + שליטה בזרימת הטופס
עוז עבר לחוזק שהוא ייחודי ל-Fillout: חישוב על סט (מערך) של נתונים, לא רק על שדות בודדים. כשיש פיקר או תת-טופס עם מספר משתנה של פריטים (פעם 2, פעם 8,000), אפשר לקחת שדה מכל איבר ולבצע עליו פעולה - לסכום את 'תקציב' מכל יוזמות המשנה, או 'מחיר כפול כמות' מכל פריטי ההזמנה, גם כשמספר האיברים לא ידוע מראש. הדוגמה שלו לניהול תקציב: סכום כולל לחלוקה, המשתמש מחלק בין סעיפים, וחישוב בזמן אמת מציג כמה נותר ('נותר לחלוקה X' / 'חרגת'). ואת השליטה בזרימה: לחסום מעבר לדף הבא עד שתנאי מתקיים (לא להמשיך עד שכל התקציב חולק), כפתור Disabled שנראה אבל לא לחיץ, ו-Page Logic שמנתב לדף שונה לפי תנאי. עוז הראה שטופס טוב הוא לא רשימת שדות - הוא תהליך עם היגיון וגבולות.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
להשתמש ב-Prefill/Prefetch כדי לטעון נתונים לפני שהטופס עולה
פה עוז לימד טכניקה שמשדרגת את חוויית המשתמש: Prefill (או Prefetch) - למשוך נתונים מבסיס הנתונים לפני שהטופס נטען ועולה. זו קריאת ה-API הראשונה שקורית, עוד לפני שהמשתמש ראה או מילא משהו. והנקודה הקריטית היא התזמון: כי זה קורה לפני הטעינה, אפשר להשתמש בו רק במה שקיים מראש (לא בנתונים שהמשתמש ימלא). איך זה עובד: מעבירים מזהה דרך ה-URL (Record ID או מייל) ומקבלים בחזרה את כל השורה - היתרון על העברת דאטה גולמי ב-URL הוא ש-ה-URL נשאר נקי. הדפוסים של עוז: פנייה אישית (לברך את המשתמש בשמו ברגע הפתיחה), מעבר בין טפסים בלי לדעת ID מראש (טופס אוסף מייל, השני עושה Prefetch לפיו), ו'הרשומה הקרובה' (View או נוסחה ב-Airtable שמחזירים תמיד את השיעור הקרוב). התובנה: כל הלוגיקה הדינמית חיה בבסיס הנתונים, לא ב-Fillout.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
לבנות פורטל עם לולאת Redirect דינמית ותנאי עצירה
וכאן עוז בנה את הפיסה שהופכת טפסים לפורטל אמיתי: לולאת Redirect דינמית עם תנאי עצירה - למשל onboarding שבו עובד ממלא 3 עד 20 טפסים. הארכיטקטורה: הפורטל הוא טופס עדכון (קשור לרשומה קיימת), עם Record Picker שמציג רק את הטפסים של אותו משתמש. המשתמש בוחר טופס, הפורטל עושה Redirect דינמי לטופס האישי שלו, וכל טופס בסיומו חוזר לפורטל (עם ה-ID מוזרק) ומעדכן ב-Airtable שהוא מולא - מה שמוריד אותו מהרשימה. זו לולאה: פורטל, טופס, פורטל, טופס. ותנאי העצירה - ב-Page Logic: כברירת מחדל להפנות לטופס הבא, אבל אם 'נותרו למלא = 0' להפנות לדף סיום. עוז הוסיף אינטגרציות מותנות: Webhook ששולח הכל לדרייב ירוץ רק כשהכל מולא. זה הרגע שבו Fillout מפסיק להיות טופס והופך למערכת ניהול תהליכים שלמה.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
לייצר PDF דינמי וחתימה דיגיטלית מתוך הטופס
עוז חשף פיצ'ר שרבים לא מכירים: הפקת PDF דינמי וחתימה דיגיטלית מתוך הטופס. Fillout מייצר PDF-ים יפים מתשובות הטופס - לוקחים תבנית PDF כרקע, גוררים תיבות שדה למקומות המדויקים, ושולטים בפונט, צבע ויישור. התוצאה: כרטיס פרויקט, הסכם או סיכום שהמשתנים מהטופס יושבים בו במקום - נשמר אוטומטית ל-Airtable או נשלח ב-Webhook. אפשר גם לאסוף חתימה ולהטמיע בהסכם. אבל עוז היה כן לגבי שתי מגבלות שחשוב לדעת מראש: אין טבלה דינמית ב-PDF (המידע 'מוטבע' כתמונה, אז אי אפשר מספר שורות משתנה - לזה צריך תבנית Word/Docs עם placeholders), ואין Audit Trail מלא לחתימה (לא מתאים למסמכים משפטיים מחייבים, אבל מצוין לחתימות זריזות מול לקוח). לדעת מה כלי עושה טוב - ומה לא - הוא חלק מהמקצועיות.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
Prefetch API — משיכת נתונים מ-API חיצוני לפני טעינת הטופס
ואת הסשן עוז סגר ביכולת המתקדמת ובאזהרה חכמה. Prefetch API - להרחיב את ה-Prefetch מעבר ל-Airtable: לבנות קריאת API מלאה לכל endpoint חיצוני (POST/GET, body, headers), שרצה לפני טעינת הטופס. עוז הבהיר בלבול נפוץ: הפיצ'ר יושב תחת 'Webhook' בממשק, אבל זו לא שליחה בסוף - זו קריאה מקדימה. דוגמאות: שער דולר עדכני מ-API של בנק ישראל בפתיחת הטופס, או קריאת GraphQL מלאה ל-Monday ישירות מ-Fillout בלי Make באמצע. ואז עוז אמר משהו ששווה לחקוק: שקלו אם זה הגודל הנכון. בניית Query מורכב בתוך Fillout עובדת, אבל קשה לתחזוקה - ולפעמים כלי אוטומציה רגיל (Make/n8n) פשוט יותר. זו בדיוק החשיבה הנכונה: לא כי אפשר, אלא כי זה הגודל הנכון לתחזק.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
🎯 מה עושים עם זה עכשיו?
קראת איך זה נעשה. עכשיו קחו את הכלים ותעשו את זה בעצמכם - כל הפרומפטים של הסשן, מוכנים להריץ על העסק שלכם. פלוס ההקלטה המלאה והתמלול.
הצטרפו לאוטוטיוזדיי+· 49 ש״ח בחודשעוד לא בשלים? בואו ללייב הבא בחינם ←רוצים לעבוד על התמלול הנקי?
העתיקו אותו ותעבדו איתו איך שנוח לכם.
🔒 התמלול המלא שמור לחברי אוטוטיוזדיי+. עם המנוי אתם מעתיקים אותו בקליק ועובדים איתו איך שנוח לכם.
לפתוח את התמלול · 49 ש״ח בחודששאלות ששאלתם (וה-AI ישאל גם)
מה ההבדל בין Fillout ל-Google Form?
ב-Google Form אוספים תשובות. ב-Fillout בונים תהליך עסקי שלם: הדאטה חי בבסיס נתונים חיצוני (בדרך כלל Airtable), והטופס קורא וכותב רשומות בזמן אמת, מסנן דינמית, מחשב על מערכים, ומנתב משתמשים לפי תנאים.
מה זה טבלה מקשרת (Junction Table)?
טבלה שלישית שמחברת בין שתי טבלאות ומחזיקה נתונים על הקשר עצמו. במקום לקשר הזמנות ישירות למוצרים (שאז אין איפה לשמור כמות/צבע), מוסיפים פריטי הזמנה באמצע - כל שורה מקשרת הזמנה למוצר ומחזיקה כמות, צבע, מחיר.
מה זה Prefetch ב-Fillout?
משיכת נתונים מבסיס הנתונים (או API חיצוני) לפני שהטופס נטען. מעבירים מזהה ב-URL ומקבלים את כל השורה - למשל לברך את המשתמש בשמו בפתיחה. הלוגיקה הדינמית חיה בבסיס הנתונים, לא ב-Fillout.
מתי לבנות בתוך Fillout ומתי במערכת אוטומציה?
עוז עצמו הזהיר: לוגיקה מורכבת (כמו GraphQL query) עובדת בתוך Fillout אבל קשה לתחזוקה. שאלת הגודל הנכון - לפעמים Make/n8n פשוט יותר לתחזק. בונים בכלי הטפסים רק כשזה באמת הגודל הנכון.
💬 הדיון על הסשן
שאלות, תובנות, מה יישמנו - השרשור של הקהילה.
עוד אין תגובות - תהיו הראשונים לפתוח את הדיון 👇