NL
All work
02

External Triggers

One interaction-design thread: separating “configure the connection” from “consume the trigger,” so a citizen developer never has to see an auth header.

Interaction design Integration Hub · Workflow Studio Utah → Yokohama

Customer problem

Before External Triggers, the only way to fire a flow from a third-party event was REST API, Asynchronous. The source document is blunt about why that failed a no-code audience:

It requires user to provide authentication information, roles, request parameters, query parameters, headers, roles. This is not a scalable option.

It was also worse than merely complex. That configuration had to be redefined per flow: one external event definition each time, with the third-party system reconfigured to match.

The brief

Hide every one of those configurations from the citizen developer. Leave them the parts they came for: put conditions on a trigger, consume the response, build the flow.

All these configurations would be abstracted from a citizen developer who has come in to define an automation workflow that triggers based on events happening in a third party and they can simply provide conditions on these triggers and consume the response and define their flows.

Source document

Personas

Integration owner

Admin, sets it up once
Does
Installs the spoke, authorises the inbound connection. Once per integration, not once per flow.
Accepts
A setup screen carrying real configuration weight. That is their job.

Citizen developer

Builds flows, repeatedly
Does
Picks a trigger, drags in a condition, builds the flow.
Never sees
Auth, roles, endpoints, headers, query parameters.

Solution

  1. Split one job into two, along the persona line. Defining the connection means auth, endpoint and roles. That happens once, done by whoever sets up the integration. Consuming the trigger means picking it, adding conditions and building the flow. That happens repeatedly, done by whoever builds automations. REST API–Async had bundled both into one person’s lap.
  2. The setup side is distinct and contained: install the spoke, find it under Workflow Studio ▸ Connections ▸ Inbound Connections, authorise it once.
  3. The configuration that remains is guided and pre-filled, not a blank form. This is the part the licensing document does not capture and the interaction spec does. REST API–Async handed one person a form and a list of things to supply: authentication, roles, request parameters, query parameters, headers. The trigger designer instead pre-fills everything the event source already knows. That covers the endpoint URL, the authentication type and location, the param name and the base path. It then walks the author through the rest in a seven-step guided tour: event source details, parser, output name, request headers, query parameters, body, conditions. Same concepts, reframed from supply these to review and confirm these.
  4. The parser derives structure instead of asking for it. Paste the event payload JSON and it generates the typed properties, reporting Properties generated successfully. Those become the data pills a flow author later drags in. Malformed input is caught at authoring time, with JSON is not formatted properly, rather than at the first real webhook.
  5. The building side is reduced to almost nothing. Pick a trigger, drag in a condition. None of the auth, role or endpoint machinery is present. That contrast is the design outcome: a setup screen with real configuration weight, against a consumption screen reduced to two actions.
  6. One precision worth keeping. The document’s own bidirectional-integration section complicates the citizen-dev framing: it notes that citizen developers cannot define event-triggered flows via the spoke’s webhook-registry and decision-table mechanism. So the citizen-dev-friendly experience is specifically the External Triggers picker, not the machinery underneath it. Worth being exact about which layer actually achieved the simplification.

Interaction spec walkthrough

23 frames from the External Trigger interaction spec — the guided tour that carries an integration owner through the configuration, and the two-control surface a flow author sees afterwards. Step through it, or let it play.

Frame 1 of 23 — External triggers live in the same Triggers module as every other saved trigger — one library, whatever the event source. Frame 2 of 23 — Creating one starts the same way as any trigger: name, type, description, application. Frame 3 of 23 — “Event source details — review the endpoint URL, authentication protocols, and other details.” The endpoint, authentication type and l Frame 4 of 23 — “The parser is your trigger’s interpreter, translating external system data into a easy to understand format.” This is the step that r Frame 5 of 23 — “Name your trigger output — this name will appear as a data pill in Flows.” The naming step exists because the output is what a downst Frame 6 of 23 — “Request headers provide additional information about the request being sent to the server.” The same headers REST API–Async demanded, Frame 7 of 23 — “Query parameters act as search filters to help you find what you’re looking for.” Choose which ones the trigger uses. Frame 8 of 23 — “The Body contains key information. Describe how the tool should understand this data.” Frame 9 of 23 — “Define the conditions that must be met to run your flow. A trigger only runs a flow when all of its start conditions are met.” Frame 10 of 23 — The event source preview, always visible above the parser: name, authentication type, authentication location, param name, base path Frame 11 of 23 — The parser proper: trigger output name, request headers, query parameters and body, each collapsible so the author sees one concern a Frame 12 of 23 — Paste the event payload JSON and the parser derives the typed structure from it, instead of asking the author to declare every proper Frame 13 of 23 — “Properties generated successfully” — the generated properties become the data pills a flow author later drags in. Frame 14 of 23 — And it validates: “JSON is not formatted properly” is caught at authoring time rather than at the first real webhook. Frame 15 of 23 — Conditions on the parsed payload — the part a downstream flow author is allowed to extend. Frame 16 of 23 — Searching within the parsed structure to pick the field to test. Frame 17 of 23 — Publishing is the gate between authoring and availability. Frame 18 of 23 — “Trigger published successfully — you can now use this trigger in Flows.” The moment the integration owner’s work becomes the citizen Frame 19 of 23 — Trigger properties keep the event source bound to the trigger: name, type, event source name, authentication type. Frame 20 of 23 — Deletion is blocked while flows still reference the trigger, with the dependent flows named rather than a generic failure. Frame 21 of 23 — The other half of the split: in a flow, the trigger is tagged “Saved Trigger”, and the whole surface is a dropdown plus “Add filters” Frame 22 of 23 — The same flow in diagram view — the external trigger sitting at the head of the canvas like any other. Frame 23 of 23 — Even the character limit is a real state rather than a silent truncation: “Character limit reached: 6000 / 6000.”
01/23
The trigger library External triggers live in the same Triggers module as every other saved trigger — one library, whatever the event source.

User flows

Set up the connection integration owner, once
  1. Install the spoke
  2. Workflow Studio ▸ Connections
  3. Inbound Connections
  4. Authorise
  5. Connection live for every future flow
Author the trigger integration owner, guided
  1. New ▸ Trigger
  2. Event source details, pre-filled
  3. Parser
  4. Name the output
  5. Request headers
  6. Query parameters
  7. Body: paste JSON, properties generated
  8. Conditions
  9. Publish
  10. “You can now use this trigger in Flows”
Build a flow on it citizen developer, repeatedly
  1. New flow
  2. Trigger picker
  3. External trigger, e.g. Jira
  4. Drag in a condition
  5. Build the flow
What this replaced REST API–Async, per flow
  1. New flow
  2. Auth info, roles, request params, query params, headers
  3. Reconfigure the third-party system to match
  4. Repeat for the next flow

KPIs

Measured N → 1

connection configurations per integration, instead of one per flow

Measured 0

auth, role or endpoint fields exposed to a flow builder

Measured 2

actions to attach a third-party event to a flow: pick, then condition

Absent 0

research citations, named pain points or adoption data in the source material

Worth being precise about what backs this up. The interaction spec above is thorough: a full authoring surface, its guided tour, its validation and error states, and its governance rules. What sits behind it is not. There is no research citation, no named stakeholder pain point, no iteration history. One clearly stated design intent, and the screens that resulted. The first three figures are structural facts about the design rather than measured adoption, and saying so is more useful than inflating it.

Still open

  • Adoption. No usage data reached me. The three structural figures above describe the design, not its uptake.
  • Validation with real citizen developers. The source material carries no research citation and no iteration history, so the guided tour has never been tested against the audience it was built for.
  • The bidirectional layer. Citizen developers still cannot define event-triggered flows through the spoke’s webhook-registry and decision-table mechanism. Only the picker got simpler.