Create a trigger

Add a trigger to a workflow by clicking the Add Trigger button in the workflow builder, which will open up a new dialog with a form.

Note that you can have multiple triggers per workflow, for example a webhook and a trigger that runs when a ticket gets saved in the PSA.

Update the relevant fields in the form as needed, to set up your trigger.

Modify an existing trigger

To modify an existing trigger, click Edit Trigger. If there are multiple triggers for the workflow, select the appropriate trigger from the dropdown menu.

How to use a trigger on a form

Once the trigger has been created on a workflow, it can then be used on a form. This must be an options generator workflow, whose requirements can be found here.

The above is a snippet from a form where a dropdown field has been selected and the output will be based on the workflow output. When running the form, if the client is added on the trigger and the trigger is set on the form, the workflow will run, and the options will fill into the form field.

Common triggers

There are five key triggers to understand when getting started with Rewst. These triggers cover a range of automation scenarios, from scheduled executions to real-time event responses. In Rewst, we denote these from other triggers by calling them core triggers. Type core into the Trigger Type field to isolate most of these trigger types from the total list.

Core - Cron Job

The cron job trigger initiates a workflow on a predefined schedule. This allows you to automate recurring tasks without manual intervention.

Schedules are configured using cron syntax. Consult crontab guru for help configuring this syntax.

For example, you can configure a workflow to run every Monday at 3:00 PM to generate weekly reports or clean up outdated records.

This trigger is most useful for:

• Scheduled maintenance workflows (e.g., clearing stale data, running audits)

• Recurring notifications (e.g., sending reminders, generating reports)

• Automated check-ins (e.g., verifying system statuses, updating dashboards)

Core - Form Submission

A workflow can be triggered when a user submits a form. Forms collect structured information, ensuring the workflow has the necessary data to proceed.

For example, you can submit an employee onboarding form to trigger a workflow that creates user accounts, assigns permissions, and sends welcome emails.

This trigger is most useful for:

• Request-based workflows (e.g., access requests, service requests)

• Intake processes (e.g., user registrations, issue reporting)

• Approval workflows (e.g., leave requests, expense approvals)

Core - Webhook

A webhook trigger starts a workflow when external data is received in real time. Webhooks eliminate the need for manual checks, making them efficient for event-driven automation.

The webhook URL serves as a listening endpoint. When an external system (e.g., a CRM, ticketing system, or another Rewst workflow) sends data to the webhook URL, the workflow is triggered immediately. This enables seamless integration between Rewst and external applications without requiring a direct API connection.

For example, a webhook could trigger a workflow whenever a new customer signs up in a CRM, automatically assigning them an account manager and setting up follow-up tasks.

This trigger is most useful for:

• Event-driven automation (e.g., responding to new leads, updating records on status changes)

• Real-time notifications (e.g., escalating high-priority tickets, alerting teams to critical updates)

• External system integrations (e.g., syncing data between platforms, processing incoming requests)

Core - Always Pass

The always pass trigger allows a workflow to start without conditions. It is commonly used in workflows that do not depend on external events or schedules.

For example, you might use this trigger when testing workflows, executing a workflow from another workflow without needing a specific event, or populating dynamic options in a Rewst form.

This trigger is most useful for:

• Manual workflow execution (e.g., running a workflow on demand)

• Subworkflows or completion handlers (e.g., workflows triggered by other workflows)

• Testing automation (e.g., verifying workflow functionality)

• Option generators (e.g., dynamically populating form fields in Rewst)

PSA: Ticket record saved

This trigger is similar to the webhook trigger but is specific to PSA systems. When a ticket record is saved in an integrated PSA, the workflow starts automatically. This includes both newly created tickets and updates to existing tickets.

For example, if a ticket is updated to Escalated, a workflow can trigger an alert to the appropriate team or assign a senior technician.

This trigger is most useful for:

• Automating ticket management (e.g., escalating high-priority tickets, auto-assigning technicians)

• SLA enforcement (e.g., sending reminders for unresolved tickets, auto-responding to specific cases)

• Status-based automation (e.g., triggering follow-up workflows when a ticket is created or reaches a certain stage)

Other triggers

While these five triggers cover the most common use cases, Rewst offers additional triggers tailored to different automation needs. Explore the available triggers in the trigger type list to find the best fit for your specific processes, and learn more about them in our additional trigger type documentation here.

Trigger criteria

When you're comfortable with the basics of triggers, learn more about trigger criteria here.

A trigger criteria is a set of conditions that determine whether a workflow should start. A condition can be a simple comparison of two values, a complex set of conditions, or even a Jinja-based query. Trigger criteria can resolve into the following possible statuses:

1. VALID - A valid trigger criteria means the triggered event satisfies all possible conditions and will start the workflow. A criteria is satisfied when all specified conditions are satisfied by logical means against the trigger context.

2. FILTERED - A filtered trigger criteria will not start the workflow and could be due to multiple reasons. The most common reason is one of the conditions is not satisfied by logical means by design and the system will filter out the event. Another reason could be due to a malformed condition that could not be parsed by the system. And finally, any malformed request initiating the trigger itself will also be filtered out.

3. UNDEFINED - A trigger criteria is undefined if the notification system is unable to determine the status of the trigger criteria. Please create a bug ticket if you encounter this status.

Trigger Criteria Functions

1. Adds new trigger criteria.

2. Opens the trigger criteria test dialog.

3. This field is used to access the trigger context. A trigger context is a dictionary of key-value pairs that contain the data of the event that triggered the workflow. The accessor field is used to access the value of the key in the trigger context.

4. Opens a Monaco editor dialog to edit the field accessor.

5. The operator is used to compare the value of the trigger context with the value of the field.

6. Value of the field to compare with the value of the trigger context.

7. Removes trigger criteria.

{
    fruit: "apple",
    fruits: ["APPLE", "orange", "banana"],
    price: 1.99,
    types: {
        colors: ["red", "orange", "yellow"],
    }
}

{
    fruit: "apple",
    fruits: ["APPLE", "orange", "banana"],
    price: 1.99,
    types: {
        colors: ["red", "orange", "yellow"],
    }
}

{{ CTX.fruit == 'apple' or CTX.price < 2 }}

Trigger Criteria Insights

The test dialog aims to assist you in developing your trigger criteria, with incoming trigger events displayed on the left and the corresponding trigger criteria form on the right.

1. Start/Stop receiving trigger events. This does not disable the trigger itself. It only stops the UI from displaying additional trigger events from showing.

2. Click the value of the trigger context to generate trigger criteria. This will automatically map the field accessor and the selected value of the trigger context.

Time Interval

Time intervals can be set to trigger a workflow repeatedly over specified periods. This trigger is suitable for workflows that need to repeat on a regular basis.

• Examples:

  • Every 5 minutes

  • Every hour

  • Daily

  • Weekly

Introduction

In Rewst, setting specific trigger criteria for PSA Ticket triggers can be crucial to ensuring that workflows are initiated only under certain conditions. This page provides a step-by-step approach to customizing these triggers.

Getting Started with Trigger Setup

Create the workflow

In the Rewst platform:

1. Navigate to Workflows > Create.

2. Enter a workflow name, like My First Webhook Trigger.

3. Click Submit to proceed to a blank workflow creation screen.

4. Add a single no-op action to the canvas. Name it BEGIN. Click Publish to save your workflow. No other actions are needed, as you'll just be working with triggers.

5. Click Add Trigger at the top of your workflow builder.

Create the trigger

1. Name your trigger.

2. Toggle Enable on.

3. Choose the trigger type relevant to your particular PSA ticket system:

   1. ConnectWise PSA: Ticket Record Saved.

   2. Datto PSA: Ticket Webhook

      1. Note: Ensure that webhooks are enabled as per Rewst Documentation.

   3. Halo PSA: New Ticket Record.

4. Click on the graph button under the Trigger Criteria section.

The trigger is now active and will capture data when a new ticket is submitted. This screen is listening for your ticket records to be saved, and will show you live results as they come in.

Testing the Trigger with a PSA Ticket

To see the trigger in action follow the below steps

Creating a Test Ticket

• In your PSA system, create and classify a new ticket with desired criteria.

• Submit the ticket.

• You should see the ticket record appear in Rewst.

Selecting Criteria

Find and click the values in the ticket you want as trigger criteria. They will have their corresponding path entered into the Trigger Criteria on the right.

Finalizing and Implementing Trigger Criteria

Saving Your Criteria

• After selecting all desired criteria, click Save then Close.

• Your trigger criteria are now set and visible.

Applying Criteria to Workflows

• Copy these criteria values.

• Paste them into other workflows you are configuring.

Conclusion

This process allows for precise control over when your workflows are triggered, enhancing the automation's effectiveness. Experiment with different criteria to tailor your workflows to specific needs.

Create the workflow

In the Rewst platform:

1. Navigate to Workflows > Create.

2. Enter a workflow name, like My First Webhook Trigger.

3. Click Submit to proceed to a blank workflow creation screen.

4. Add a single no-op action to the canvas. Name it BEGIN

5. Click Publish to save your workflow. No other actions are needed, as you'll just be working with triggers.

6. Click Add Trigger at the top of your workflow builder.

Create the trigger

1. Name your trigger.

2. Toggle Enable on.

3. Choose the trigger type Core - Webhook.

Set trigger parameters

The following parameters are available for editing:

• Allowed Methods

  • Used to define which HTTP request method is accepted by the trigger. Attempting to send a request with a method not in this list will result in an error

• Include Raw Body

  • Whether to include the raw string sent in the request body in the results as raw_body

• Response Body

  • Content to return in response body. {{ REQUEST }} may be used to access request data.

• Response Headers

  • HTTP headers to include in response. {{ REQUEST }} may be used to access request data.

  • TIP: Set your content type here if returning a specific format of data, such as text\html

• Response Status

  • HTTP status to return in response. {{ REQUEST }} may be used to access request data.

• Secret Key

  • Required to Wait For Results. This value must be included in the header as x-rewst-secret when making calls to this webhook. You will receive a 401 if this field is filled out and the secret key is not provided when making the request. Secrets can be defined in the Organization Variables section of the UI

• Wait for Results

  • If true, calls to the trigger endpoint will redirect to a results endpoint that will return the output of the workflow.

Access data in a webhook trigger request

When a webhook receives a request, it will include data received in the following schema:

{
    body:{},
    headers:{},
    method:"",
    params:{},
    timestamp:""
}

Data can then be pulled from this as context variables. For example, to access the value for test sent to the webhook as:

{
    "test": "Hello, World!"
}

The value can be accessed at {{ CTX.body.test }}.

Similarly, if a URL parameter is sent as ?test=Hello, this can be accessed at {{ CTX.params.test }}

Anatomy of a webhook URL

Webhook URLs are formatted consistently using the trigger ID and organization ID. The format is as follows: https://engine.rewst.io/webhooks/custom/trigger/{{ Trigger ID }}/{{ Organization ID }}

Using this information, you can craft webhook links on the fly for organizations a webhook trigger is enabled for. This may be useful for invoking certain workflows using links in a PSA ticket note or email, for example