הבנת תנאים ב-Shopify Flow

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

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

זרימת עבודה יכולה לכלול מספר בלתי מוגבל של תנאים, בהתאם למורכבות של זרימת העבודה שלך. תנאים יכולים גם להתחבר לתנאים או לפעולות אחרות, תלוי במה שאתה רוצה שזרימת העבודה תעשה. אפשר להגדיר תנאים כך שיתחברו ברצף (לדוגמה, אם תנאי A הוא נכון (true), אז תבדוק את תנאי B; אם A הוא שקר (false), אז תבדוק את תנאי C), או להגדיר אותם כך שיתרחשו בו-זמנית כחלק מאותו שלב (לדוגמה, תבדוק אם A או B או C נכונים).

בעמוד זה

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

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

משתנה הוא מציין מקום שמגדיר את הנתונים שבהם התנאי משתמש. לדוגמה, אם תנאי נועד לבדוק קוד הנחה ספציפי בהזמנה, אז המשתנה יהיה order.discountCode. המשתנים משתמשים בכתיב הנקודה של GraphQL Admin API.
אופרטור לוגי מציין כיצד זרימת העבודה צריכה לקבוע אם התנאי מתקיים. אפשר להחיל אופרטורים לוגיים ברמת המשתנה, או כאשר מספר משתנים נכללים כחלק מקריטריוני התנאי הכוללים:
- אפשרויות ברמת המשתנה כוללות אופרטורים ברמת השדה כגון גדול מ- (Greater than) או מתחיל ב- (Starts with), או אופרטורים של רשימה כגון לפחות אחד מתוך (At least one of) או הכול מתוך (All of).
- אפשרויות ברמת התנאי כוללות את AND (וגם), שמשמעותה היא שכל המשתנים חייבים להיות נכונים כדי שהתנאי ייחשב לנכון באופן כללי, או OR (או), שמשמעותה היא שלפחות משתנה אחד חייב להיות נכון כדי שהתנאי ייחשב לנכון באופן כללי.
ערך הוא המידע בפועל שהמשתנה מחפש. לדוגמה, אם ה-order.discountCode הספציפי שאתה רוצה שזרימת העבודה תבדוק הוא AFFILIATE10, אז זה יהיה הערך שצריך לכלול כחלק מהתנאי.

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

למידע נוסף ומפורט על מרכיבי התנאים ב-Shopify Flow.

הבנת משתנים בתנאים

בעת יצירת שלב תנאי בזרימת עבודה, השלב הראשון שתתבקש לבצע הוא הוספת משתנה. אבל מהו בעצם משתנה?

ב-Shopify Flow, משתנה הוא מציין מקום שמציין את הנתונים המשמשים את התנאי בזרימת העבודה. כאשר תנאי קורא "אם A גדול מ-10...", החלק של A הוא המשתנה. בחירת משתנה עבור תנאי היא למעשה להגיד לתנאי באופן ספציפי אילו נתונים להעריך.

המשתנים מעוצבים באמצעות כתיב הנקודה של GraphQL Admin API. אינך צריך להיות בקיא ב-API כדי ליצור זרימות עבודה באמצעות היישום Flow, אבל הבנה בסיסית של שמות משתנים והגדרותיהם יכולה לעזור לך לבנות את הלוגיקה הספציפית שאתה רוצה לזרימת העבודה.

כדי להבין אילו נתונים משתנה מייצג, עיין במידע הבא על משתנים:

טיפ: קבל עזרה לגבי משתנים מ-Dev Docs Assistant

אם אינך בטוח איזה משתנה לבחור בעת בניית התנאי שלך, כדאי לשקול לבקש עצה מה-Dev Docs Assistant של Shopify. ל-Dev Docs Assistant יש גישה לכל התיעוד בנוגע ל-GraphQL Admin API, והוא יכול להציע הצעות לעיצוב תנאי ב-Shopify Flow:

עבור אל Shopify Dev Docs.
לחץ על Ask Assistant כדי לפתוח את חלונית הצ'אט.
בשדה ההודעה, הזן את הבקשה שלך, כמו למשל "באיזה משתנה כדאי לי להשתמש ב-Shopify Flow אם אני רוצה לגשת לנתוני התג של הלקוח כשהטריגר שלי מתחיל ב-"Order created"?".
יש ללחוץ על Enter או ללחוץ על .

קריאת כתיב נקודה במשתנים

בעת בחירת משתנים, תבחין שהם מעוצבים כמילות מפתח המופרדות בנקודות, כגון order.customer.tag. פורמט זה מציין את השלבים שה-API עושה כדי להגיע לנתונים שבהם ברצונך להשתמש. כל 'שלב' של משתנה מופרד בנקודה, והנתיב לנתונים נקרא משמאל לימין. אורך המשתנים עשוי להשתנות בהתאם למיקום אחסון הנתונים ב-API ולנתיב שבו עוברת זרימת העבודה כדי להגיע אליהם.

לדוגמה:

order.email: בודק את כתובת הדוא"ל המשויכת ללקוח עבור ההזמנה. זה דומה לאופן שבו לוחצים על הזמנה ולאחר מכן בודקים את כתובת הדוא"ל בפרטי ההזמנה.
refunds_item.staffMember.name: בודק אם יש החזר כספי על פריט בהזמנה, עובר למידע על חבר הצוות המשויך לאותו החזר כספי, ובודק את השם המלא של איש הצוות.

בעת בחירת משתנה, כדאי לחשוב כיצד מנווטים במנהל של Shopify כדי למצוא את המידע הרצוי. סביר להניח שה-API יצטרך לעבור נתיב דומה, מה שיכול לעזור לקבוע כיצד המשתנה שלך עשוי להיות מעוצב.

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

המשתנה שבו תשתמש כדי להחזיר את אותם נתונים ב-Shopify Flow יעבור נתיב דומה: order.customer.statistics.rfmGroup.

דרישות נתונים עבור משתנים

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

לדוגמה, אם זרימת העבודה שלך מתחילה בטריגר מוצר נוצר (Product created), התנאים שאתה יוצר מאותו טריגר מוגבלים למשתנים הזמינים ממערך הנתונים מוצר (product). לכן, משתנים כגון product.category.name, product.vendor ו-variants_item.displayName זמינים כולם לשימוש כחלק מהתנאי. לעומת זאת, משתנים כמו customer.verifiedEmail או subscriptionContracts_item.status לא יוצגו כאפשרויות, כיוון שהם אינם משויכים למערך הנתונים של המוצר.

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

לדוגמה, נניח שאתה רוצה שזרימת העבודה שלך תבדוק את התגים בפרופיל הלקוח. אם זרימת העבודה מתחילה בטריגר הזמנה נוצרה (Order created), המשתנה יהיה order.customer.tags כיוון שזרימת העבודה מתחילה בנתוני ההזמנה, לאחר מכן בודקת את פרטי הלקוח בהזמנה, ואז בודקת את התגים של אותו לקוח. אם זרימת העבודה שלך מתחילה בטריגר לקוח נוצר (Customer created), המשתנה יהיה פשוט customer.tags כיוון שזרימת העבודה מתחילה בנתוני הלקוח, ולכן היא יכולה לעבור ישירות לבדיקת התגים בפרופיל הלקוח.

בדיקת נתיב של משתנה בעת חיפוש המבוסס על מילות מפתח

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

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

order.tags: התגים שהוחלו על ההזמנה עצמה. לדוגמה, #rush order או #gift.
order.customer.tags: התגים שהוחלו על הלקוח שביצע את ההזמנה. לדוגמה, #VIP או #affiliate.
order.lineItems.product.tags: התגים שהוחלו על המוצרים שנרכשו בהזמנה. לדוגמה, #fragile או #requiresID.

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

הבנת אופרטורים לוגיים בתנאים

אופרטורים לוגיים מגדירים כיצד התנאי שלך מוחל, והתוצאה שלהם היא הצהרה שהיא נכונה (true) או שגויה (false). כאשר תנאי מציין "אם A גדול מ-10...", החלק של ה-גדול מ- (is greater than) הוא האופרטור הלוגי. בחירת אופרטור לוגי עבור תנאי היא בעצם להורות לתנאי כיצד להעריך את המשתנה.

בזרימות העבודה של Shopify Flow, ישנם 3 סוגים של אופרטורים לוגיים:

אופרטורים ברמת השדה, כגון גדול מ- (Greater than) או מתחיל ב- (Starts with).
אופרטורים של רשימה, כגון לפחות אחד מ- (At least one of) או הכול מ- (All of).
אופרטורים ברמת התנאי, כגון וגם (AND) או או (OR).

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

אופרטורים ברמת השדה הם סוגי האופרטורים הנפוצים ביותר, המשמשים בכל סוג של הצהרת משתנה. באמצעות אופרטורים ברמת השדה, ניתן ליצור הצהרות מותנות כמו "אם A גדול מ-10, בצע את X" או "אם B מכיל את 'VIP', בצע את X" כדי שתהיה לך רמת שליטה גבוהה יותר אילו ערכים של משתנה יחזירו תוצאה נכונה. האופרטור הלוגי ברירת המחדל הוא שווה ל- (Equal to).

אופרטורים של רשימה יכולים לחול רק על משתנים שיכולים להחזיר רשימת תוצאות. לדוגמה, המשתנה lineItems_item.variant.price מחזיר את המחיר עבור גרסת מוצר בהזמנה, מה שעשוי להחזיר רשימת תוצאות כאשר הלקוח קנה מספר מוצרים באותה הזמנה. המשמעות היא שניתן להחיל אופרטור של רשימה כגון לפחות אחד מ- (At least one of) כאשר רוצים שהצהרה מותנית כגון "lineItems_item.variant.price גדול מ-10$" תהיה נכונה אם יש לפחות גרסת מוצר אחת בהזמנה שעולה על 10$. לעומת זאת, אופרטורים של רשימה אינם מוצגים עבור משתנים שיכולים להחזיר רק תוצאה אחת בכל פעם. לדוגמה, יש רק ערך אפשרי אחד עבור משתנה כגון order.createdAt משום שהזמנה יכולה להיווצר רק פעם אחת, ולכן אופרטורים של רשימה אינם מוצגים כאפשרויות לשינוי ההצהרה המכילה את אותו משתנה.

אופרטורים ברמת התנאי, כגון AND ו-OR, מאפשרים לכלול מספר משתנים באותו התנאי. לדוגמה, במקום הצהרה מותנית פשוטה כמו "אם A שווה ל-5, בצע את X", אפשר לבנות תנאים מורכבים יותר כגון "אם A שווה ל-5 ו-B גדול מ-10, בצע את X" שדורש שגם משתנה A וגם משתנה B יהיו נכונים, או "אם A שווה ל-5 או B גדול מ-10 או C קטן מ-1, בצע את X" שדורש שרק 1 מבין המשתנים A,‏ B, או C יהיה נכון. יש להשתמש ב-AND כאשר כל התנאים בזרימת העבודה חייבים להיות נכונים; יש להשתמש ב-OR כאשר די בכך שקריטריון אחד בלבד יתקיים כדי שהתנאי יהיה נכון.

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

למידע נוסף ומפורט על אופרטורים לוגיים בתנאים.