Mga trigger & aksyon

Ano ang nagsisimula dito, ano ang ginagawa nito, paano ito nagdedesisyon

Tatlong tanong, at bawat workflow sa platform na ito ay sagot sa mga ito. Ang pahinang ito ang bokabularyo: ang mga paraan ng pagsisimula ng isang run, ang mga kayang gawin ng isang hakbang, at ang mga piraso na humuhubog sa daan sa pagitan ng dalawa.

Mga Trigger

Apat na paraan ng pagsisimula ng isang run

Isang iskedyul

Tuwing sampung minuto, tuwing Lunes ng alas-siyete, unang araw ng trabaho ng buwan. Naipapahayag sa timezone na pinili mo, kaya ang pag-urong ng orasan ay hindi isang insidente.

Isang webhook

Ang iyong shop, ang iyong CRM, ang iyong billing system, kahit anong kayang gumawa ng HTTP request. Naka-on by default ang signature verification at pinapanatili ang payload kasama ng run.

Isang kaganapan mula sa mundo

Anunsyo ng konsyerto, naka-iskedyul na laro, lindol, babala sa baha, paglampas sa antas ng kalidad ng hangin, pagka-down ng provider. Higit sa 175 na pinagkunan, sariwa bawat sampu hanggang dalawampung minuto.

Isang poll, o isang tao

Bantayan ang isang endpoint, mailbox o folder at magsimula kapag may nagbago. O simulan ito nang mano-mano, mula sa console, dahil minsan iyon ang tapat na sagot.

Isang run bawat bagay. Ang trigger na tumutugis nang dalawang beses para sa parehong pinagbabatayang kaganapan — isang webhook na inulit ng sender, isang poll na nakakita muli ng parehong row — ay nagsisimula ng isang run, hindi dalawa. Naka-key ang deduplication sa anumang nagkikilala sa bagay, at maaari mong itakda ang key na iyon kung mas masahol ang ideya ng sender sa id kaysa sa iyo.

Mga Aksyon

Mga hakbang na may ginagawa

Ang isang action ay nagbabago ng isang bagay sa labas ng run: sumusulat, nagpapadala, nag-sisingil, nagbo-book, kumukuha o nagfa-file. Dalawang uri, at ang pagkakaiba ay kung may kasamang model o wala.

Mga deterministic na action

Tumawag sa isang HTTP endpoint. Magbasa at magsulat sa sarili mong mga sistema. I-reshape ang isang payload. Maghanap sa reference data. Magpadala ng e-mail, SMS, push notification o naka-print na liham. Mag-alok ng booking slot. Kumuha ng bayad. Gumawa ng maikling link. Kunin ang isang imahe kasama ang lisensya nito. Sumulat ng isang row, file o record.

Parehong input, parehong output. Walang gastos ang pagpapatakbo nila, kaya ang tapat na payo ay gamitin ang mga ito sa lahat ng hindi talagang nangangailangan ng paghuhusga.

Mga AI action

I-classify ang mensaheng ito. I-draft ang sagot na iyon. Ibuod ang isang thread sa tatlong bullet point. Kunin ang mga field mula sa isang hindi nakaayos na dokumento. Pumili sa mga opsyon batay sa panuntunang isinulat mo sa malayang teksto. Isalin, pinapanatili ang tono.

Bawat AI step ay nagdedeklara ng hugis ng ibinabalik nito, at bineberipika ang pagbabalik laban sa hugis na iyon bago magpatuloy ang run. Kung gumawa ang model ng may sira, nabibigo nang malinis ang step sa halip na makasira sa susunod na labindalawang hakbang.

May nangyayari. Pagkatapos, ang tamang bagay ang susunod na nangyayari.

Flow: ang mga hakbang na nakatuon lamang sa run

Mga condition ay nagsasanga batay sa isang value. Parehong landas ay nakadefine, palagi — ang isang condition na walang nakadefine na else-branch ang pinakakaraniwang paraan ng tahimik na pagkawala ng mga record sa isang automation, kaya hindi posibleng mag-iwan ng nakabitin dito.

Mga wait ay nagpapatigil sa isang run hanggang sa isang sandali o kaganapan. Ang isang wait ay isang wake_at na nakasulat sa mismong run, hindi isang row na nakatambay sa queue, kaya kaya ng isang workflow na maghawak ng sampung libong tao sa loob ng tatlong linggo nang walang anumang gastos at walang mapapansin.

Ang quiet hours ay pumipigil sa mga papalabas na mensahe na dumating ala-tres ng madaling-araw. Ang run na umabot sa isang send step sa loob ng quiet window ay naghihintay hanggang sa magsara ang bintana. Maaaring salungatin ito ng severity, sadya, para sa mga alertong dapat gumising sa mga tao.

Ang mga split ay nagpapadala ng bahagi ng mga run sa landas A at ang natitira sa landas B, para makapagkumpara ka ng dalawang subject line, dalawang wait o dalawang pagkakasunod-sunod laban sa isa't isa sa live na trapiko.

Ang mga goal ay minamarka ang bagay na para saan ang workflow. Kapag umabot ang run sa goal nito, tumitigil ito doon, anuman ang natira sa downstream — ang customer na bumili ay hindi na tatanggap ng ikatlong paalala na bumili.

Naiwang basketNaabot ang layunin

⚡TriggerTue 16:02Basket na hindi gumagalaw nang 40 minuto. Na-deduplicate sa basket id.
?KondisyonBasket na higit sa 150 zł? Oo — kunin ang mas mahabang landas.
⏸Maghintay2 hIsang wake_at sa run. Walang queue row, walang gastos.
AHatiin50/50 sa subject line. Variant A ang nakuha ng run na ito.
✉IpadalaTue 18:02E-mail na may maikling link, binibilang ang mga redirect bawat recipient.
★LayuninTue 18:40Naipasok ang order. Tumitigil dito ang run; hindi na ipinapadala ang ikalawang paalala.

Mga step na tumawag sa model: 1Mga step na walang gastos: 5

Ang mga error ay bahagi ng daloy, hindi eksepsyon dito

Ang step na nabigo ay may mapupuntahan. I-retry na may backoff, at may limitasyon sa ilang beses. Kunin ang alternatibong landas. Itigil ang run at i-file ito kung saan makikita ito ng tao. Magpatuloy kahit paano, dahil opsyonal lang ang partikular na step na iyon at mas gusto mo ang karamihan ng resulta kaysa sa wala.

Ang default para sa isang step na nakikipag-usap sa sistema ng ibang tao ay mag-retry nang ilang beses at pagkatapos tumigil — dahil ang sistemang down sa 09:14 ay karaniwang gumagana na sa 09:19, at dahil mas madaling unawain ang run na tumigil kaysa sa run na kalahati nang nangyari.

Ang hindi mo maaaring gawin: hindi maaaring bumalik ang isang hakbang sa mas naunang hakbang. Ang workflow ay isang tuwid na landas, hindi isang programang may jump instruction. Kung talagang kailangan ng trabaho mo ang isang loop, umulit sa loob ng listahan sa loob ng isang hakbang, o magsimula ng run bawat item — parehong suportado, at parehong mas madaling basahin pagkatapos kaysa sa isang cycle.