Trigger Nodes

Every workflow starts with exactly one trigger. It decides when the workflow runs and which data it passes on. Apart from the manual trigger, triggers only fire after you have deployed a version and while the workflow is Active.

Manual Trigger

Runs when you click Run test in the builder. Use it for workflows you start on demand and while you are building.

No configuration.

Webhook Trigger

Runs when an HTTP request reaches the workflow's webhook URL:

https://<your DeutschlandGPT address>/workflows/api/v1/webhook/<workflow ID>

There is one URL per workflow. The Webhook URL is shown in the trigger's panel; copy it from there. It accepts GET, POST, PUT, PATCH and DELETE. A JSON body becomes the payload output. Without a JSON body, payload is an empty object.

The URL only accepts requests once a version is deployed. Each caller address can trigger a workflow up to 60 times per minute and 5,000 times per day; beyond that the webhook answers with status 429.

To test without an external system, click Create webhook test data in the trigger's panel and enter a sample JSON object.

Configuring the response

By default the webhook answers with status 200 and a JSON object of success, executionId and message. Under Advanced settings you can set your own response. These fields are labeled in German in the node:

The body may use what is already known when the request arrives:

• {{<trigger>.outputs.payload.field}}: a field from the request body, in the spelling the Variables panel inserts
• {{<trigger>.outputs.triggeredAt}}: when the request arrived
• {{executionId}} and {{workflowId}}

The response leaves as soon as the run is queued, not when it finishes. A later node's output therefore cannot be returned, and such an expression is left in the response verbatim so the mistake is visible. Rejected requests keep their own status and JSON error body: unknown workflow, wrong secret, workflow not deployed, or rate limit exceeded.

Form Trigger

Runs when someone submits the workflow's form. The form lives at /workflows/<workflow ID>/form; the Form URL is shown in the trigger's panel. See Forms for what submitters see.

Access Control has three values:

• Private (Only owner): only you, signed in
• Workspace (Members only): signed-in members of your workspace
• Public (Anyone): anyone with the link, without signing in

Each field has a key, a label, a type and a required flag, plus an optional description and placeholder. The field types are Text, Multiline text, Dropdown, Checkbox, Number, Date and File upload. Number fields take a minimum and maximum, dropdowns a list of options, and file fields the accepted file types, a maximum size (10 MB by default) and whether several files are allowed (up to 5 by default).

Reference a field as {{formTrigger.outputs.formData.<key>}}, with your trigger's variable name in front.

Scheduled Trigger

Runs the workflow on a schedule. In the trigger's Schedule field, choose one of the Predefined schedules, or type a description such as "every weekday at 8" and let the AI turn it into an expression. The field shows the next five execution times.

Schedules are evaluated in German time (Europe/Berlin), including the switch to and from daylight saving time.

The expression uses the six-field AWS EventBridge cron format:

minute  hour  day-of-month  month  day-of-week  year

• Either day-of-month or day-of-week must be ?, never both.
• Day-of-week counts from 1 = Sunday to 7 = Saturday. Monday to Friday is therefore 2-6.

Integration Triggers

Start a workflow when something happens in a connected service, for example a new email in Outlook or Gmail, a new message in a Slack channel or a new Jira issue. In the node picker, open Triggers → Integration Triggers, pick the service and the event, and choose a Connection.

Which events exist is listed on each integration's page. Get test event in the trigger's panel fetches a real event from the service and pins it as test data.

If the connection behind a deployed trigger is deleted or loses access, the workflow is deactivated and the builder shows a notice on the trigger.

Subworkflow Trigger

Makes the workflow callable from other workflows through the Subworkflow node.

Under Parameters you define what the caller passes in. Each parameter has a key, a label, a type (string, number, boolean, object or array) and a required flag. The parameters become the trigger's outputs for the following nodes. Under Test data you enter example values to test the subworkflow on its own.

A subworkflow only runs when called if it is deployed, active and in the same workspace as the caller.