This is an implementer guide, following basic workflow and trigger setup. You need an integration owner and an approved test endpoint. Success means checking the received request and its content in the target system, not just seeing a trigger in the editor.
A workflow Webhook trigger calls a previously configured Webhook record. It is not an editor for arbitrary HTTP requests.
Configure the destination
An administrator or authorized editor should create the Webhook record under Settings → Webhooks, with the intended URL and active state.
Check whether its model/event subscriptions are appropriate as well. A webhook used from a workflow trigger and a webhook subscribed to model events serve different purposes; avoid unintended extra calls.
The Create Webhook form before entering destination details. Name and URL are required. Review Active and any Model/Events subscriptions with the integration owner before saving. Once configured, select this record in the step trigger’s Webhook action.
Attach it to a step
Select the step and open Triggers.
Add a trigger and choose the step event.
Choose Webhook as the action.
Select the required Webhook record.
Add a condition if the call should happen only for certain cases.
Save, validate, and test through a controlled real session.
The picker shows the configured records and their active/inactive status. Choose the intended active destination.
What is sent
Dispatch uses HTTP POST, a system-generated JSON payload, and Content-Type: application/json. The payload includes model, trigger, and data information.
The workflow trigger does not provide controls for choosing GET/PUT/PATCH, supplying an arbitrary request body, or entering custom authentication headers. Do not assume variable interpolation in a trigger URL or body.
Authentication
This webhook mechanism does not provide a configurable authentication-header or signing setup in the workflow editor. If the receiver requires authentication, have the integration owner design and verify the receiving endpoint or gateway accordingly.
Check the actual request and receiver behavior in a test environment. Do not describe an endpoint as protected just because it is on an internal network or because its URL is difficult to guess.
Verify delivery
Preview does not prove that the receiver got a real request. Run a controlled test event, inspect receiver-side logs, and confirm the expected payload.
If nothing arrives, check the selected record, active state, trigger event and condition, and the server-to-receiver connection. Keep webhook integration diagnostics separate from ordinary workflow save diagnostics.
