Hvilke data kan en handling bruge fra en hændelse

/

Uanset hvilken hændelse et workflow lytter på, kan handlingen bagefter bruge det hændelsen ved i sin egen tekst — en e-mail, en webhook-URL. Denne artikel viser, hvad hver hændelsestype stiller til rådighed.

I artiklen “Lad et workflow reagere på ændringer i et emne” viser vi, hvordan en handling kan bruge data fra en hændelse om et emne — {entity_id}, {value.Status} og lignende. Det samme virker for alle andre hændelsestyper, bare med andre navne, fordi det er en anden slags hændelse, der er sket.

Denne artikel er opslagsværket: find din hændelsestype, og se hvilke navne du kan skrive i krøllede parenteser.

Handling startet / afsluttet / mislykkedes

Disse tre hændelser fortæller om en handling, der selv er en del af et workflow — nyttigt når én handling skal reagere på, at en anden lige er kørt.

  • {action_type} — hvilken slags handling, fx SendNotificationAction
  • {workflow} — navnet på det workflow, handlingen hører til
  • {result} — kun på “Handling afsluttet”: hvad handlingen selv rapporterede, fx “Webhook blev udført”
  • {error} — kun på “Handling mislykkedes”: fejlbeskeden

Integration startet / afsluttet / behandlet emne / mislykkedes

Disse fortæller om en integration (kanal), der kører — importerer eller eksporterer data til eller fra et andet system.

  • {channel} — navnet på integrationen
  • {progress} — hvor mange emner integrationen har behandlet
  • {source} / {destination} — kun på “Integration startet”: hvor data kommer fra, og hvor det sendes hen
  • {result} — kun på “Integration afsluttet”: resultatet af kørslen
  • {entity_id}, {external_id}, {entity_type}, {index} — kun på “Integration behandlede emne”: hvilket emne der lige blev håndteret, og hvilket nummer det var i rækken
  • {error} — kun på “Integration mislykkedes”: fejlbeskeden

“Integration behandlede emne” udløses én gang for hvert emne integrationen rører ved — det er den at bruge, hvis en regel skal reagere på hvert enkelt emne en integration behandler, ikke kun når hele kørslen er færdig.

Import startet / afsluttet / mislykkedes / behandlede emne / sprang linje over

  • {filename} — navnet på filen der importeres
  • {filesize}, {entity_type}, {headers} — kun på “Import startet”
  • {total} — kun på “Import afsluttet”: hvor mange emner der blev læst
  • {error} — kun på “Import mislykkedes”
  • {entity_id}, {title}, {created}, {count} — kun på “Import behandlede emne”: hvilket emne, og om det var nyt
  • {reason}, {row}, {columns} — kun på “Import sprang linje over”: hvorfor linjen blev sprunget over

Eksport startet / afsluttet / mislykkedes

  • {total} — antal emner
  • {query_type}, {language}, {target} — kun på “Eksport startet”: hvad der eksporteres, og på hvilket sprog
  • {filename} — kun på “Eksport afsluttet”
  • {error} — kun på “Eksport mislykkedes”

Planlagt workflow startet

  • {workflow} — navnet på workflowet
  • {schedule} — hvor ofte det køres, fx “Hver 12. time”

Webhook modtaget

Her er der ikke en fast liste — hvert felt i den JSON, det andet system sender, bliver sit eget navn. Sender systemet {"order_id": "ORD-1", "status": "afsendt"}, kan du med det samme skrive {order_id} og {status} i din handling.

To ting du kan regne med, uanset hændelsestype

  • Et navn, hændelsen ikke kender, bliver stående. Skriver du {result} i en regel, der udløses af en integration, der ikke er færdig endnu, står der {result} i beskeden — det bliver aldrig stiltiende erstattet af ingenting.
  • Kun tekst bliver udfyldt. Dropdowns og afkrydsningsfelter i en handling indeholder et valg, du har truffet fra en liste; der bliver ikke sat noget ind i dem.