> For the complete documentation index, see [llms.txt](https://showreward.gitbook.io/showreward-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://showreward.gitbook.io/showreward-docs/gohighlevel/workflows.md).

# Use ShowReward in GoHighLevel workflows

GoHighLevel workflows can react to ShowReward activity or send a call-validation decision to ShowReward when the corresponding Marketplace modules are available to your installed account. Calendar synchronization can be set up independently of these optional workflow features.

## Tutorial 05

**HighLevel Workflow Triggers and Examples**

Learn how to use ShowReward events with your own HighLevel automations, choose event filters, and build follow-up steps for participants and your team.

{% embed url="<https://assets.cdn.filesafe.space/mYdk8zjDWRfpvpBKfwxH/media/6ac440855be7b18197950cf5.mp4#t=4>" %}

[Open Tutorial 05 video in a new tab](https://assets.cdn.filesafe.space/mYdk8zjDWRfpvpBKfwxH/media/6ac440855be7b18197950cf5.mp4).

The tutorial covers these chapters:

* Attendance-confirmation and preparation-video completion triggers.
* Cancellation, video-submission, and re-recording follow-up examples.
* Reminder branches and personal portal links.
* Reward-decision follow-up messages.
* Filtering manual call-validation events.
* Reward-claim and reward-status triggers.

The examples show configurations you can adapt to your business. Some sections only demonstrate draft trigger settings, so follow the written testing and publishing steps below before using a workflow with customers.

[Browse all video tutorials](/showreward-docs/getting-started/video-tutorials.md).

## ShowReward triggers

### React to ShowReward activity

In a workflow for the connected subaccount, look for the ShowReward trigger for the event you need. The integration supports these types of events when their modules are enabled:

* A participant confirms attendance in the portal.
* An introduction video is submitted.
* Preparation videos are completed.
* A participant needs to rerecord an introduction video.
* An introduction video is reviewed.
* A reward claim is submitted.
* A reward is approved, paid, or rejected.
* A call is manually validated in ShowReward.

For example, **ShowReward — Attendance confirmed** can begin your follow-up after the participant confirms their intention to attend. **ShowReward — Call validated** is for the closer's actual post-call validation in ShowReward. These are different moments in the customer journey.

Choose the trigger, configure the available filters, add your workflow steps, and test with a contact and appointment you control before using it with customers. Start with an internal tag update so you can confirm the trigger without sending messages.

If the ShowReward module is missing, ask your account administrator to check the installed app version, workflow permissions, and Marketplace feature availability. Do not substitute a generic webhook with guessed settings.

## Workflow examples

Combine a ShowReward trigger with HighLevel's native actions, such as adding a contact tag, sending an email or SMS, notifying the contact owner, or moving a contact through a reminder sequence. Installing ShowReward does not automatically install the example workflows shown in the tutorial; create and configure the ones your business needs.

The tutorial demonstrates these patterns:

* **Attendance and preparation:** add a tag after attendance is confirmed or preparation videos are completed. Use that tag in your own follow-up logic.
* **Video submission:** add a tag, send a confirmation email, notify the contact owner, and remove the contact from a video-reminder workflow.
* **Re-recording requests:** use the **Selfie needs re-recording** event and its available custom values to explain the reviewer's reason and direct the participant back to their portal.
* **Video reminders:** after a wait, check whether the video has been submitted. End the sequence for participants who have completed the task and continue reminders for those who have not. Use the contact's **ShowReward Claim URL** field for the participant's personal portal link.
* **Reward follow-up:** use event filters or your own contact tags and branches to tailor claim invitations and other messages. These messaging actions do not make a reward payment.

The cancellation example uses HighLevel's native **Appointment status** trigger, with filters for a cancelled appointment and a change made through the API. It is separate from the ShowReward event triggers. Its email uses appointment notes to include the cancellation explanation; check that the expected notes are present in your own test.

To build and activate an example:

1. Create a workflow in the connected subaccount and give it a descriptive name.
2. Select the relevant trigger and configure its filters. For example, **Call validated** can be filtered to **Show** and **Send claim**; **Reward status changed** offers **Approved**, **Paid**, and **Rejected**.
3. Add the follow-up actions your business needs. Select dynamic values from HighLevel's value picker and the relevant ShowReward event rather than guessing field names.
4. Save the workflow, check all branches and message recipients, and test with a contact and appointment you control. Confirm the resulting event, tag, or message before relying on it.
5. Switch the completed workflow to **Publish** when it is ready. Saving a trigger in a draft does not activate a finished automation.

## Validate a call from a workflow

The workflow-action setup is demonstrated in [Tutorial 04: Validate Calls and Manage Reward Claims](/showreward-docs/daily-operations/validations.md#tutorial-04). Tutorial 05 above focuses on triggers and follow-up examples.

Where **ShowReward: Validate Call** is available, use it only in a workflow that has the exact GoHighLevel appointment context.

1. Add the ShowReward validation action.
2. Use GoHighLevel's value picker to map the exact appointment ID from the workflow context. Do not choose a contact ID or guess which appointment belongs to a contact.
3. Choose Show or No-show.
4. For Show, provide a call outcome and reward decision. Supported outcomes cover not qualified, sold, not sold with follow-up, and a second call rescheduled. Reward decisions cover enabling a claim, leaving the decision pending, not sending a claim, and sending the case for review.
5. Add an approximate call duration and notes if needed. For No-show, leave outcome, reward decision, and duration empty.
6. Test the action and check the appointment and reward in ShowReward.

If the workflow cannot provide an exact appointment ID, validate the call directly in ShowReward instead.

### Advanced example: Last Appointment ID

Tutorial 04 also shows a tag-based validation workflow using a dedicated contact field to carry an appointment ID from a booking workflow. Use this approach only when you have confirmed that the stored ID still belongs to the exact call you intend to validate.

1. In HighLevel **Settings → Custom Fields**, create a **Single line** field called **Last Appointment ID** on the **Contact** object. The recording places it in the **Additional Info** group.
2. Create a separate workflow with the **Customer Booked Appointment** trigger.
3. Add an **Update contact field** action. Select **Last Appointment ID** as the destination and use the value picker to insert **Appointment → ID** from that booking.
4. Save the workflow, test that it stores the correct booking ID, and publish it when ready.
5. In the validation workflow's **ShowReward: Validate Call** action, map the appointment ID from **Contact → Custom Fields → Last Appointment ID**. Configure the attendance, call outcome, and reward decision as described above.
6. Before activating the validation workflow, test the complete sequence and confirm which appointment is being validated in ShowReward.

{% hint style="warning" %}
This field stores one appointment ID per contact. Another booking can overwrite it, so “last appointment” does not necessarily mean the call you are validating. Do not use it when multiple calls or delayed workflow steps make the appointment ambiguous. If you cannot confirm the exact appointment, validate directly in ShowReward.
{% endhint %}

## Understand the result

An applied or already-applied result confirms the action's outcome. Manual review or conflict needs investigation before downstream steps assume success. Do not repeatedly change inputs on the same appointment to force a different final result.

A Show initially left with a pending decision can be finalized by a later validation action for the same original appointment. This is intended for a follow-up decision; it does not reopen an already final reward or correct a No-show.

The **Call validated** trigger applies to manual validations in ShowReward. A validation sent by the GoHighLevel action does not emit that same trigger back into GoHighLevel, avoiding a workflow loop. Triggers also do not automatically replay all historical activity when first added.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://showreward.gitbook.io/showreward-docs/gohighlevel/workflows.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.