Core Docs - Core Concepts - Configure a Webhook to a Workflow

Rock Version: v21.0
Last Modified: 2026-09-14 12:24 PM

You have seen several ways to launch a workflow from inside Rock. Webhooks open the door from the outside. When a document is signed in DocuSign, a payment clears in Stripe, a form comes in from Typeform or Jotform, or almost any other modern web service finishes a task, that service can call Rock and start a workflow for you. Nobody has to remember to go do it.

Most web services offer webhooks, which let them call out to other systems when something happens. Formstack can call Rock every time a form is completed, for example. Services like Zapier and Power Automate sit in the middle and route webhooks between services that do not talk to each other directly.

Rock listens for these calls at one address that ships with every install. This is the URL you hand to the service doing the calling.
https://rocksolidchurchdemo.com/Webhooks/LaunchWorkflow.ashx

How Rock Matches a Webhook to a Workflow

Rock decides what to launch using a Defined Value. These live under
Admin Tools > General Settings > Defined Types > Workflow Webhook.
Every webhook that arrives is checked against this list, one entry at a time. Rock evaluates the Lava in the Process Request attribute of each Defined Value, and any that return 'True' launch their workflow.

Because every Defined Value gets a look at every webhook, the Process Request Lava needs to be specific. The simplest way to keep them apart is a query string parameter on the URL you give the service.
https://rocksolidchurchdemo.com/Webhooks/LaunchWorkflow.ashx?WorkflowTypeId=12
Your Process Request template then only has to check for it.

{% if QueryString.WorkflowTypeId == "12" %} True {% else %} False {% endif %}

Use HTTPS in Your Webhook URL
Most Rock instances redirect http to https. When that redirect happens the POST body is dropped and the webhook fails, usually with nothing obvious to show for it on the Rock side. Always give the sending service the https address.

When No Workflow Is Found
If nothing matches, Rock returns a 404. That can be confusing the first time you are debugging a new webhook, but it is deliberate: it keeps anyone from probing your Rock for valid webhook endpoints.

Pass Information into the Workflow

A launched workflow is more useful when it knows what triggered it. The Defined Value lets you set a Lava template for the Workflow Name, so each run can be named from the data in the webhook call instead of every run sharing one generic name.

You can also list attribute keys from the workflow and give each one a Lava template for its value. The challenge is knowing what data you have to work with. The Defined Type screen has a feature that shows and hides the available fields. The basic items are:

Body and RawBody both carry what the service sent. RawBody is the raw text exactly as it arrived. Body is that same content already parsed, which Rock provides for JSON, form-encoded and XML requests, so you can reach values directly instead of parsing the string yourself. For any other content type, RawBody is the one to use.

Each of these items can carry a lot of child properties, and the actual values change greatly depending on the calling service. The Defined Type screen documents some of them, but the reliable way to learn what a particular service sends is to set a test attribute to RawBody and look at what comes through.

You can put Lava into the Workflow Attribute configuration on the Defined Value, but most of that logic belongs inside the workflow instead. The Lava on the Defined Value cannot contain special characters like the pipe that Lava filters require.

Example

Say you pass the request body into the workflow using an attribute key of RequestBody. This Lava inside the workflow then reaches its properties.

{% assign body = Workflow | Attribute:'RequestBody' | FromJSON -%}
{{ body.propertyname }}