ConnectWiz Flows
မည်သူနှင့် စကားပြောနေသည်ကို သိသော အလိုအလျောက်စနစ်။
ယေဘုယျ workflow tool များက ဒေတာ row များကို အလိုအလျောက်လုပ်သည်။ Flows က စကားဝိုင်းများကို အလိုအလျောက်လုပ်သည် — အလုပ်၏ ယူနစ်မှာ အဖြေကို စောင့်နေသော လူတစ်ဦး ဖြစ်ပြီး "၃ ရက် စောင့်ပါ" အဆင့်သည် ပုံမှန်ဖြစ်ကာ ခွင့်ပြုချက် မေးခွန်းသည် canvas ပေါ်တွင် တကယ့် node တစ်ခုအဖြစ် ရှိနေသည်။ Node အမျိုးအစား ၂၇ မျိုး၊ ချန်နယ်တိုင်း၊ ရိုးသားစွာ ကန့်သတ်ထားသည်။
Trigger များ
Flow တစ်ခု စတင်နိုင်သော နည်းလမ်း ၆ မျိုး — တစ်ခုစီသည် canvas ပေါ်ရှိ ပထမတန်းစား ကတ်တစ်ခု
စကားဝိုင်းအသစ်
ပထမဆုံး ဆက်သွယ်မှုတိုင်းကို ဖွဲ့စည်းပုံကျသော ကြိုဆိုစကားဖြင့် နှုတ်ဆက်ပါ — widget တွင်မူ ဧည့်သည် စာမရိုက်မီ chat window ပွင့်သည်နှင့်ပင် စတင်နိုင်သည်။
Keyword
သင့် keyword များနှင့် ကိုက်ညီသော ဖောက်သည် မက်ဆေ့ချ်က မှန်ကန်သော flow ကို စတင်စေသည် — "ရက်ချိန်း"၊ "ဈေးနှုန်း"၊ "ပြန်အမ်း" — မည်သည့်ချန်နယ်တွင်မဆို။
အချိန်ဇယား
နာရီက ပရိသတ်တစ်စုကို ရွေးပြီး စကားဝိုင်းများ ဖွင့်ပေးသည် — သက်တမ်းတိုး သတိပေးချက်၊ ရာသီအလိုက် အဆက်အသွယ်ပြုခြင်း — အချိန်ဇယားနှင့် ပေးပို့ခြင်းကြားတွင် သဘောတူခွင့်ပြုချက် guard များ ရပ်နေသည်။
ဖောင် တင်သွင်းပြီး
ဖောက်သည်က ဖောင်ကို တင်သွင်းလိုက်သည်နှင့် flow တစ်ခု စတင်ပြီး အဖြေတိုင်းကို variable အဖြစ် အသုံးပြုနိုင်သည် — ဖောင် ရောက်လာသည့် စက္ကန့်မှာပင် နောက်ဆက်တွဲ လုပ်ငန်း စတင်သည်။
ဝန်ထမ်း ခလုတ်
ဝန်ထမ်းများက တိုက်ရိုက် စကားဝိုင်းတစ်ခုပေါ်တွင် flow ကို တစ်ချက်နှိပ်ရုံဖြင့် စတင်နိုင်သည် — ငွေပြန်အမ်း လုပ်ငန်းစဉ်၊ onboarding အစဉ် — လူ၏ ဆုံးဖြတ်ချက်က အလိုအလျောက် လုပ်ဆောင်မှုကို ရွေးချယ်သည်။
Webhook — လုံခြုံစွာ
Webhook trigger တိုင်းတွင် ကိုယ်ပိုင် secret ပါသော ကိုယ်ပိုင် public URL၊ raw body ပေါ်ရှိ HMAC စစ်ဆေးမှုနှင့် replay ကာကွယ်မှု ရှိသည်။ Payload သည် ညွှန်ကြားချက် မဟုတ်ဘဲ ဒေတာသာ ဖြစ်သည်: လူတစ်ဦးကို အမည်ဖော်နိုင်သော်လည်း flow ၏ အတွင်းပိုင်းကို မည်သည့်အခါမျှ ထိန်းကျောင်း၍ မရပါ။
Node စာရင်း
Node အမျိုးအစား ၂၇ မျိုး — ၎င်းတို့ကို ရိုးသားနေစေသော စည်းမျဉ်းတစ်ခုနှင့်အတူ
Node တစ်ခုသည် ၎င်း၏ runner၊ editor ဖောင်၊ validation၊ test နှင့် documentation အားလုံး ရှိသည့်နေ့မှသာ palette ထဲ ဝင်သည်။ Palette ကို engine ကိုယ်တိုင်မှ ထုတ်ပေးသဖြင့် runner က မလည်ပတ်မည့် အဆင့်ကို editor က ကမ်းလှမ်း၍ မရပါ။
မက်ဆေ့ချ်ပို့ခြင်း (၆)
မက်ဆေ့ချ်၊ ရွေးချယ်စရာများ၊ မီဒီယာ၊ WhatsApp တမ်းပလိတ်၊ chat အတွင်း ဖောင်နှင့် ချန်နယ်အလိုက် rich sender — သင့်ဖောက်သည် တကယ် မြင်ရသော စကားလုံးများနှင့် မျက်နှာပြင်များ။
Logic နှင့် အချိန် (၅)
Condition၊ switch၊ connector (အဆင့်တစ်ခုသို့ ခုန်ခြင်း သို့မဟုတ် sub-flow ခေါ်ခြင်း၊ အနက် ကန့်သတ်ထားသည်)၊ ခိုင်မာသော delay နှင့် ရုံးချိန် — နာရီနှင့် ပြက္ခဒိန်ကို လေးစားသော branching။
ဒေတာ (၄)
အဖြေများ ဖမ်းယူခြင်း၊ variable သတ်မှတ်ခြင်း၊ မည်သည့် REST API ကိုမဆို ခေါ်ခြင်းနှင့် သင့်ကိုယ်ပိုင် data table များကို ဖတ်ခြင်း သို့မဟုတ် ရေးခြင်း — ချိတ်ဆက်မှု မလိုသော ချိတ်ဆက်မှု။
AI (၄)
Intent ကို ခွဲခြားခြင်း၊ သင့် knowledge base မှ ဖြေကြားခြင်း သို့မဟုတ် မပြောမီ အချက်အလက်များ — သင့် CRM အပါအဝင် — ရှာဖွေနိုင်သော tool သုံး AI agent ထံ အဆင့်တစ်ခု လွှဲပေးခြင်း။
လူနှင့် လမ်းကြောင်းခွဲခြင်း (၁)
လုပ်ဆောင်ချက်စုံ node တစ်ခုက ဌာနနှင့် ဝန်ထမ်းများကို တာဝန်ပေးအပ်သည်၊ တဂ်တပ်သည်၊ ဦးစားပေးအဆင့် သတ်မှတ်သည်၊ စကားဝိုင်းကို ဖွင့်ခြင်း သို့မဟုတ် ပိတ်ခြင်း ပြုလုပ်သည် — အလိုအလျောက်စနစ်မှ လူထံ လွှဲပြောင်းခြင်းကို ရှင်းရှင်းလင်းလင်း။
CRM နှင့် အရောင်း (၃)
သင့် CRM ကို palette ထဲရှိ app တစ်ခုအဖြစ်: ဖတ်ရန် လုပ်ဆောင်ချက် ၁၀ ခုနှင့် ရေးရန် လုပ်ဆောင်ချက် ၇ ခု — ရေးခြင်းတိုင်းသည် ဂိတ် သုံးခု (ချိတ်ဆက်ပြီး၊ လုပ်ဆောင်နိုင်ပြီး၊ admin က ရှင်းရှင်းလင်းလင်း ဖွင့်ပေးပြီး — ပုံသေအားဖြင့် အားလုံး ပိတ်ထားသည်) နောက်တွင် ရှိသည်။
Commerce၊ ဖုန်းခေါ်ဆိုမှုနှင့် ရက်ချိန်း (၂)
သင်၏ ကတ်တလောက်ကို ရှာဖွေခြင်း၊ အော်ဒါတင်ခြင်း၊ ဖုန်းခေါ်ဆိုမှု စတင်ခြင်း၊ တကယ့် ရက်ချိန်း အချိန်ကွက်များကို ကမ်းလှမ်းပြီး ယူပေးခြင်း — တမင်ပင် လုပ်ဆောင်ချက် နှစ်ခု၊ ကမ်းလှမ်းပြီးမှ ယူသဖြင့် ဖောက်သည်က ရွေးချယ်ရသည်။
Guard များ (၂)
သဘောတူခွင့်ပြုချက်နှင့် အကြိမ်ရေကို မြင်သာသော အဆင့်များအဖြစ် — ခွင့်ပြုချက် မေးခွန်းကို ဆက်တင်များထဲ မြှုပ်မထားဘဲ စစ်ဆေးသူများ မြင်နိုင်သော canvas ပေါ်တွင် ထားသည်။
ချန်နယ်ကို သိသော ပေးပို့ခြင်း
Flow တစ်ခု၊ ချန်နယ်တိုင်း — rich ဖြစ်နိုင်သည့်နေရာတွင် rich
Rich sender တွင် ချန်နယ်အလိုက် လုပ်ဆောင်ချက် ၂၀ ခန့် ပါဝင်သည် — list၊ reply ခလုတ်၊ carousel၊ ကုန်ပစ္စည်း ကတ်၊ ပြေစာ၊ coupon၊ တည်နေရာ တောင်းခံခြင်း၊ ခေါ်ဆိုမှု ခလုတ်၊ WhatsApp Flows — ချန်နယ်ကို ၎င်း ဘာပြနိုင်သည်ကို သုံးကြိမ် သီးခြားစီ မေးသည်: palette တွင်၊ သိမ်းချိန်တွင်နှင့် ပို့ချိန်တွင်။ အဖြေက ပြောင်းလဲတတ်သောကြောင့် ဖြစ်သည်။
ချန်နယ်အလိုက် rich element များ
WhatsApp တွင် list၊ Telegram တွင် ခလုတ်၊ Messenger တွင် carousel — တစ်ကြိမ်သာ ရေးစပ်ပြီး ချိတ်ဆက်ထားသော ချန်နယ်တစ်ခုစီ တကယ် ပံ့ပိုးသည့်အရာနှင့် မထုတ်မီ စစ်ဆေးအတည်ပြုသည်။
အတွင်းတွင် WhatsApp Flows
Meta ၏ chat အတွင်း native ဖောင် screen များကို flow အဆင့်တစ်ခုအဖြစ် ပို့ပြီး တိုက်ရိုက် screen ဒေတာကို host လုပ်ထားသော encrypt data endpoint က ပေးသည် — ဒေတာ ရင်းမြစ် တစ်ခု ချို့ယွင်းသွားလျှင်လည်း screen သည် သေမသွားဘဲ ယဉ်ကျေးသော အသိပေးချက်ဖြင့် ပြသဆဲ ဖြစ်သည်။
သင်ကြားပေးသော တမ်းပလိတ်များ
Built-in flow တမ်းပလိတ် ၈ ခု — ဦးစားပေးစီခြင်း၊ FAQ၊ အော်ဒါ အခြေအနေ၊ Lead ဖမ်းယူခြင်း၊ follow-up၊ menu၊ ရက်ချိန်း၊ စောင့်ဆိုင်းခြင်း — တစ်ခုစီက pattern တစ်ခုကို ပြသည်၊ နီးပါးတူ ၅၀၀ အစား တမင် နည်းနည်းသာ ထားသည်။
စမ်းသပ်ခြင်းနှင့် ဗားရှင်းများ
"Editor ထဲမှာ အလုပ်လုပ်တယ်" ဆိုသည်မှာ နောက်ဆုံးတွင် အဓိပ္ပာယ် ရှိလာသည်
တကယ့် dry-run များ
Test ခလုတ်က ပို့သော output အစား စုဆောင်းသော output ဖြင့် တကယ့် engine ကို လည်ပတ်သည် — runner တစ်ခုတည်း၊ trace တစ်ခုတည်း၊ ပို့သော မက်ဆေ့ချ် သုည။ သင် ကြည့်နေသည်မှာ production လုပ်မည့်အရာပင် ဖြစ်သည်။
ဗားရှင်းများနှင့် ပြန်ယူခြင်း
ထုတ်ဝေတိုင်း ဗားရှင်းကို snapshot ယူသည်၊ မည်သည့် ဗားရှင်းကိုမဆို တစ်ချက်နှိပ်ရုံဖြင့် ပြန်ယူနိုင်သည်။ သောကြာနေ့ စမ်းသပ်မှုက တနင်္လာနေ့ကို ဓားစာခံ မဖမ်းနိုင်ပါ။
ငြင်းခုံတတ်သော validator
သီးခြား တွေ့ရှိချက် ၉၇ ခန့် — အသုံးမဝင်သော branch များ၊ ပျောက်နေသော capture များ၊ ချန်နယ် မကိုက်ညီမှုများ — ကို မထုတ်ဝေမီ editor ထဲတွင် ပြသည်၊ အကြောင်းမှာ စာလုံးပေါင်းအမှားကို ရှာတွေ့ရန် ဖောက်သည်သည် မှားယွင်းသော နေရာ ဖြစ်သောကြောင့် ဖြစ်သည်။
Run များ — trace လုပ်ပြီး funnel ပြထားသည်
Run တိုင်းတွင် အဆင့်တစ်ခုစီ၏ input နှင့် output ကို မှတ်တမ်းတင်သည်။ Funnel မြင်ကွင်းက လူများ ဘယ်သို့ စီးဆင်းပြီး ဘယ်နေရာတွင် ကျသွားသည်ကို ပြသည်။ Debug လုပ်ခြင်းသည် ခန့်မှန်းခြင်း မဟုတ်ဘဲ ဖတ်ခြင်း ဖြစ်သည်။
Guard များ
ခွင့်ပြုချက် မေးခွန်း — canvas ပေါ်တွင် ဆွဲထားသည်
သဘောတူခွင့်ပြုချက်ကို အဆင့်တစ်ခုအဖြစ်
သဘောတူခွင့်ပြုချက် node က ဈေးကွက်ရှာဖွေရေး branch မတိုင်မီ အတိုင်းအတာ ခွဲထားသော သဘောတူခွင့်ပြုချက် လယ်ဂျာ — ချန်နယ်၊ ရည်ရွယ်ချက်၊ အမျိုးအစား — ကို စစ်ဆေးသည်။ စစ်ဆေးသူများက diagram ထဲတွင် guard ကို မြင်ရပြီး စာရင်းစစ်များက run trace ထဲတွင် မြင်ရသည်။
အကြိမ်ရေကို အဆင့်တစ်ခုအဖြစ်
Frequency node က လူတစ်ဦးကို အလိုအလျောက်စနစ်က မည်မျှ မကြာခဏ ထိတွေ့နိုင်သည်ကို ကန့်သတ်သည် — ကမ်ပိန်းများ ညှိနှိုင်းမည်ဟု မျှော်လင့်ခြင်းဖြင့် မဟုတ်ဘဲ ဖွဲ့စည်းပုံအရ စာရင်း ငြီးငွေ့မှုကို ကာကွယ်သည်။
နာရီကို လေးစားသည်
ခိုင်မာသော delay များနှင့် ရုံးချိန် node ကြောင့် flow တစ်ခုသည် ၃ ရက် စောင့်ပြီးနောက်တွင်ပင် ရုံးချိန်အတွင်း ရောက်နိုင်သည် — သည်းခံမှုသည် ကပ်ထားသော cron job မဟုတ်ဘဲ engine ၏ feature တစ်ခု ဖြစ်သည်။
မဖုံးကွယ်ထားသော အသေးစိတ်များ
Flows က မဖြစ်လိုသည့်အရာ — အကြောင်းပြချက်များနှင့်အတူ
Parallel branch မရှိ
လူတစ်ဦးသည် စကားဝိုင်း branch နှစ်ခုတွင် တစ်ပြိုင်နက် မရှိနိုင်ပါ။ လူကို တစ်ပြိုင်နက် လမ်းကြောင်းများအဖြစ် ခွဲခြင်းသည် မက်ဆေ့ချ် နှစ်ထပ် ထွက်စေသော data-pipeline အတွေးအခေါ် ဖြစ်သည် — ဒီဇိုင်းအရ ငြင်းပယ်ထားသည်။
Item အလိုက် loop မရှိ
"ကုန်ပစ္စည်းတိုင်းအတွက် မက်ဆေ့ချ် တစ်စောင် ပို့ပါ" ဆိုသည်မှာ spam ပုံစံ ဖြစ်သည်။ ထပ်ခါထပ်ခါ လုပ်ခြင်း တရားဝင်သည့်နေရာတွင် node တစ်ခုက ၎င်းကို list သို့မဟုတ် carousel မက်ဆေ့ချ် တစ်ခုအဖြစ် ပြသည်။
Code node မရှိ
ဖောက်သည် စကားဝိုင်း engine အတွင်း စိတ်ကြိုက် code သည် ကျွန်ုပ်တို့ မရောင်းရန် ရွေးချယ်ထားသော လုံခြုံရေးနှင့် support ဝန်ထုပ်ဝန်ပိုး ဖြစ်သည်။ REST node က သင့်စနစ်များကို ခေါ်သည်၊ သင့် code သည် သင့်စနစ်များထဲတွင်သာ ရှိသည်။
ရည်ရွယ်ချက်ရှိရှိ ကန့်သတ်ထားသည်
တစ်ကြိမ် ဖြတ်သန်းမှုလျှင် node ၃၂ ခု၊ sub-flow အနက် ၅ ဆင့်၊ အရွယ်အစား သတ်မှတ်ထားသော variable နေရာ — စကားဝိုင်း ဒီဇိုင်းအတွက် ရက်ရောပြီး ထိန်းမနိုင်သော အလိုအလျောက်စနစ်အတွက် ရန်လိုသည်။ အမြင့်ဆုံး ကန့်သတ်ချက်များကို ရှာတွေ့ရခြင်း မဟုတ်ဘဲ မှတ်တမ်းတင်ထားသည်။
Flows FAQ
မတည်ဆောက်မီ
နောက်ထပ်အချက်များကို အပြည့်အစုံပါသော FAQ တွင် ဖတ်ပါ၊ သို့မဟုတ် ကျွန်ုပ်တို့ကို တိုက်ရိုက်မေးပါ။
စကားဝိုင်းကို ဆွဲပါ။ Engine က ၎င်း၏ ကတိများကို တည်သည်။
တမ်းပလိတ်တစ်ခုမှ စတင်ပါ၊ တကယ့် engine ပေါ်တွင် dry-run လုပ်ပါ၊ အမြဲ ပြန်လှည့်နိုင်သော ဗားရှင်းဖြင့် ထုတ်ဝေပါ။