Send a conditional case-creation webhook from a Workflow

A Case workflow can send a webhook when a case event meets your operational conditions. This is useful when another approved system should act on a defined subset of support work, such as new cases for a monitored customer service. The workflow determines when to send; the receiving system interprets the event and performs its own business action. Build and test both sides so a successful send becomes useful, accountable follow-up.

Confirm a conditional workflow is the right route  ·  Define the trigger and safe test scope  ·  Create the Case workflow and its matching rules  ·  Configure the Webhook action  ·  Understand the event envelope without guessing its schema  ·  Run a controlled end-to-end acceptance check  ·  Example: a service-specific customer escalation intake  ·  Plan for delayed or repeated processing  ·  Troubleshoot the rule, transport and business action separately

Confirm a conditional workflow is the right route

Use this procedure when you need Case workflow conditions or the action’s supported authentication. If you need a straightforward subscription to a supported event, review event webhook subscriptions instead. They have a different settings screen and payload contract.

The person configuring the rule needs permission to administer workflows and edit this section. The receiving-system owner must provide an approved endpoint and implement support for the event payload. A webhook URL from a different product is not automatically compatible with this request.

Define the trigger and safe test scope

1. Write the intended result: for example, “When an eligible new case for this support service is created, send a reference to the approved account-operations receiver.” Identify the customer/service condition and expected downstream owner.
2. Choose representative matching and nonmatching test cases. Include another customer or excluded scenario to reveal overly broad conditions.
3. Agree the endpoint, authentication and data handling with the receiver owner. Use HTTPS for customer data, even though the current URL validation accepts HTTP as well.
4. Agree how the receiver handles repeated requests and temporary failures. Record how missing results will be reconciled without creating duplicate downstream work.
5. Review existing workflows and subscriptions so the same event is not sent twice unintentionally. Keep the initial rule limited to the intended test scope.

Create the Case workflow and its matching rules

1. Open Settings → Configuration → Workflows and choose New workflow, or open the intended existing rule. Give it a name that states the purpose and scope.
2. In the workflow’s Trigger configuration, select the Case scope and the creation event offered for that scope. Confirm the workflow is active and within its allowed execution times. Review its processing priority and Stop processing behavior because they affect order and which other matching workflows may run. Then validate the rule’s conditions.
3. In Requirements, add the facts that must all be true for every qualifying case, such as the intended supported customer/service condition. Use the actual choices offered by the condition editor.
4. In Conditionals, add alternatives only when needed. At least one configured conditional must match after all requirements pass; these are not additional mandatory AND rules. Review any exclusions as well.
5. Check the logic against your matching and nonmatching examples before enabling an external action. Empty condition groups do not independently prove that every case will run the rule; the selected trigger and other workflow controls still apply.

Configure the Webhook action

1. Open Actions and locate the Webhook card. Turn on Enable webhook.
2. Enter the approved complete Webhook URL. Use the receiver’s event endpoint, not its sign-in or home page.
3. Choose Authentication according to the receiver’s contract: No authentication, Username and password, Bearer token, or Custom header.
4. Enter the fields for that method. Username/password uses the corresponding fields; bearer authentication uses Bearer token; a custom header uses Header name and Header value. Keep these values out of screenshots and ordinary case notes.
5. If the rule includes an optional custom webhook event label, agree its meaning with the receiver owner. It supplements the standard event; it does not change the case trigger you selected.
6. Review Historical request body if shown. It is read-only compatibility content: the current workflow sends the Supportbench event payload, not a body template you can design here.
7. Review the rule’s other actions, save it and reopen it to confirm the intended settings. Enable operational use only within the agreed controlled test and rollout scope.

Saved secrets are not displayed. Do not treat an empty-looking saved secret field as proof that the connection has no credential, and do not use Clear saved value unless you intend to remove that saved value. Test the selected authentication through the actual receiver after a credential change.

Understand the event envelope without guessing its schema

For the Case workflow path, the request includes these top-level fields. Have the receiver owner inspect a representative actual request for the detailed case data rather than using a speculative list of fields from an older tutorial.

The payload is JSON. The receiver must parse it and perform any mapping to its own task, issue or CRM record. A generic incoming-message URL may require a different JSON structure; adding its URL does not automatically translate the Supportbench event into that format.

Do not confuse this envelope with an event-subscription request or with a public API response. They are separate contracts. Verify relevant customer/internal data before approving an external destination.

Run a controlled end-to-end acceptance check

1. Reopen the saved workflow and verify Case scope, creation event, conditions, execution controls and the Webhook action. Record the non-secret configuration and expected result.
2. Create one approved matching test case through the normal Case Add path. A later edit to an existing case does not reproduce a case-creation event.
3. Check that the receiver got the expected request and accepted the selected authentication. Inspect the actual envelope and case identifier.
4. Verify the downstream task or record, including its customer mapping, responsible owner and link/reference back to the source case. HTTP success is not enough if the business action was skipped.
5. Create or use the agreed nonmatching test event. Confirm it does not create the downstream result. Test the most likely overly broad condition and an excluded customer scenario.
6. Have the receiver owner demonstrate repeat handling and a temporary-failure recovery. Check existing results before any manual replay or workaround.
7. Record results and introduce the rule into its intended scope. Assign ongoing monitoring and repeat the affected tests after condition, credential or endpoint changes.

Example: a service-specific customer escalation intake

A support operations team wants eligible new cases for a contracted equipment service to appear in an external engineering intake system. The administrator chooses the Case creation event and supported conditions for the intended customer/service scope. The receiver owner accepts the actual event envelope and creates one intake item associated with the correct customer.

The team tests a qualifying case, an unrelated service request and a repeated request. The support case retains an accountable owner and customer update plan; creating an external intake item does not itself transfer the customer commitment. If the need is specifically to create and link a supported provider issue, evaluate that provider’s native integration workflow instead of rebuilding its relationship behavior with a generic webhook.

Plan for delayed or repeated processing

This workflow webhook path has a bounded retry process of up to six attempts with 30 seconds between attempts. That is retry behavior, not a guaranteed delivery deadline or an assurance that the receiver performed its work exactly once. Receiver processing can succeed even when a response is lost, so repeats must be safe.

Before manually repeating work, check the source case, workflow conditions, receiver request logs and any already-created downstream record. If the receiver was unavailable beyond the retry window, use the agreed reconciliation process. Do not broaden the workflow or repeatedly create customer cases to make the integration try again.

Troubleshoot the rule, transport and business action separately

Continue learning

• Choose the correct webhook mechanism
• Configure simple event subscriptions
• Configure workflow structure and processing
• Understand workflow conditions
• Reference workflow actions
• Create a case with complete customer context