App Event-Triggered Pattern
An external business event triggers a genie workflow — either continuing an existing conversation or starting a new one.
Why This Pattern
The reasoning fork is whether the event should resume a conversation the user already started, or proactively start one they didn't ask for. Get the direction wrong and you produce either silence (a user waiting inside a thread that never resumes) or noise (unsolicited conversations for events nobody needed to hear about).
A second layer of reasoning worth copying from the cookbook's own example: validate the event before acting, and gate the final write behind human confirmation — an automatically-triggered workflow is exactly the kind of thing that will run on bad input if you let it.
When to Use It
- Continue Conversation — an external event or scheduler needs to resume an existing conversation thread (e.g., notifying a user of a change to a ticket they created through the genie).
- New Conversation — an external event should proactively start a new conversation (e.g., a completed call that needs summarizing and logging).
When NOT to Use It
- The workflow doesn't depend on an external system event at all — a user-initiated conversation is simpler.
- The event hasn't been validated — never trigger genie action straight off a raw event without checking it's the right kind of event first.
How It Works in Workato
Continue Conversation: store the external key in Workato storage alongside the conversation ID; a trigger recipe listens for the application event, identifies the existing conversation using that key, and continues it via App Events.
New Conversation: a trigger recipe listens for the application event and starts a new conversation via App Events.
Source: Agentic Design Cookbook V2.0, pp. 25–27