Skip to content

article

Workflow Triggers: Manual, Webhook, Schedule, and App Events

A complete guide to the four StretchAutomate trigger types, when to use each, how to configure them, and how the trigger payload flows into your steps.

What a trigger does

The trigger is what starts a workflow and supplies its opening data. Every run begins with a trigger payload — the event's data — which becomes the root of the workflow's context. Your steps then reference that payload (for example {{ trigger.email }}) and build on it. Choosing the right trigger type is the first design decision in any automation.

StretchAutomate supports exactly four trigger types: Manual, Webhook, Schedule, and App event.

App event — react to something in the suite

An App event trigger fires when a named event occurs in a StretchSuite connector. This is the most common trigger because it wires your apps together. The available events come straight from the Connector Library — for example:

  • StretchCRM: lead_created, deal_stage_changed, contact_created
  • StretchShop: order_created, cart_abandoned, checkout_completed
  • StretchBooks: invoice_paid
  • StretchForms: form_submitted
  • StretchMail: email_received
  • StretchTasks: task_completed
  • StretchSchedule: appointment_booked, appointment_canceled
  • StretchSupport: ticket_created, sla_breach_imminent

Configure it by setting the trigger type to App event and choosing the connector and event in the trigger config. The event's data (the new lead, the paid invoice, the abandoned cart) arrives as the trigger payload.

Webhook — react to an outside system

A Webhook trigger fires when an external system sends an inbound HTTP request to your workflow's endpoint. Use it to start automations from tools outside StretchSuite. The request body becomes the trigger payload, so your steps can reference the incoming JSON just like any other trigger data.

Configure it by setting the trigger type to Webhook; the workflow then accepts an inbound webhook (the inbound_webhook capability of the Webhook / HTTP connector). Point your external system at the endpoint and send a JSON body.

Schedule — run on a clock

A Schedule trigger fires on a recurring time basis rather than in response to an event — for nightly digests, weekly clean‑ups, or periodic syncs. The Built‑in logic connector provides the schedule trigger capability.

Configure it by setting the trigger type to Schedule and specifying the cadence in the trigger config. Because there is no external event, scheduled workflows usually start with a step that fetches the data they need.

Manual — run on demand

A Manual trigger does not fire on its own; you start the workflow yourself, optionally passing a trigger payload. Manual is ideal while you are building and testing — you control exactly when it runs and what data it sees — and for one‑off operational tasks you kick off by hand.

Configure it by setting the trigger type to Manual. Then run the workflow from the Workflows tab, supplying a sample or real payload.

The trigger payload flows into every step

Whatever the trigger type, the payload it produces is placed in the run's context under trigger. Downstream steps reference it with template tokens — for instance an action might set its recipient to {{ trigger.email }} or its amount to {{ trigger.total }}. See Data Mapping and Templating for the full reference syntax. If a step references a field the trigger payload does not contain, the run records an unresolved reference and the step fails — a good reason to simulate with a realistic payload first.

Realistic example

A retailer wants to win back abandoned carts. They create a workflow with an App event trigger listening for StretchShop cart_abandoned. The trigger payload includes the customer's email and the cart contents. A filter checks the cart value is above a threshold; if it passes, a StretchMail send_email action reminds the customer, using {{ trigger.customer_email }} as the recipient. Because the trigger carries everything the steps need, no extra lookups are required.

Tips

  • Use Manual while building so you can run on demand with controlled test data, then switch the real workflow to App event, Webhook, or Schedule.
  • Match the trigger to the moment: react to suite events with App event, outside systems with Webhook, and clock‑based work with Schedule.
  • Simulate with a representative payload — the closer to production data, the more references you will validate before going live.
  • Note that some connectors are action‑only (StretchSocial has no triggers) and StretchForms is trigger‑only — the Library tells you which events a connector supports.

Troubleshooting

"Workflow trigger type is invalid." The trigger type must be one of manual, webhook, schedule, app_event. Choose a supported value.

My App event trigger never fires. Confirm the workflow is Active (not Draft or Paused) and that the connector event you chose actually occurs. Test the logic first with a Manual trigger and a sample payload.

Steps fail with unresolved references. The trigger payload did not contain a field a step expected. Inspect a real payload, adjust your mappings, and re‑simulate.

Was this helpful?

Help us improve this article

Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.