Actions in Rewst

Actions are the operations available for creating and automating, which live inside of a workflow. You grab these actions from the left side menu of the workflow builder, and drag them onto the workflow canvas. When you run a workflow, Rewst is completing a series of actions specified within that workflow. Once an action has been dragged onto the canvas, we refer to that dragged action as a task, to differentiate between a dragged and undragged action.

Once you've set up an integration, Rewst offers you a number of actions related to that integration to build your workflows. They're accessible from the accordion menus in the left side menu of the workflow builder, and sorted based on their respective sources, including integrations by brand, Core, Rewst, Transform, and Workflow. Expand any accordion to see the related actions it contains.

The actions menu of the workflow builder

Each action serves a unique purpose and comes with a brief description to aid in understanding its functionality. Click on any action to begin dragging and dropping it onto your workflow builder canvas. For more on our workflow builder and how workflows are essential to Rewst, see our workflow documentation here.

Click through to any of the related action type pages to learn more.

Core actions

Core actions: These are the essential platform components like webhooks, email dispatching, and noops.

Integrations

Integrations actions: When you set up an integration in Rewst, it comes with a predefined set of actions, which will appear in your workflow builder action menu. These actions allow you to work with various parts of the integrated product as per its API. Rewst's integrations pull in the most useful and most commonly used actions, but not all available actions. Each integration's action accordion menu will also contain an action to allow you to pull in additional actions. This action is titled [Integration Name] API Request. See our individual integration setup pages for more information on available actions.

Rewst actions

Rewst actions: These actions are for interacting with your Rewst environment. You can perform tasks such as creating organizations and users, associating with multi-tenanted objects, and setting organization variables.

Transform actions

Transform actions: These actions help you shape and modify your data for efficient workflow execution, replacing the need for complex Jinja statements.

Workflows actions

Workflows actions: These actions allow you to call other workflows within your environment. They enable you to feed information from the parent workflow as inputs and return the results upon completion.

Known actions issues and errors

This collection of issues related to actions have been reported to Rewst by our customers. If you experience an issue with actions that is not in this list, contact us in your dedicated Discord support channel.

Click on any of the issues below to expand and see its solution or information.

Brave browser

Brave browsers will block the click event on Rewst actions. This is due to the way that Brave handles the click event. To fix this, you can either disable the Brave shield for the page, or use a different browser.

ThreatLocker

We have received reports that ThreatLocker may block certain Rewst actions. Threatlocker has a built-in application for Rewst IP addresses that can be added to your Ringfence policy.

To set this up in ThreatLocker:

1. Navigate to Modules > Application Control.

2. Click Policies.

3. Select PowerShell Ringfencing Policy.

4. In the Actions section, click Tags.

5. Add Rewst.

This process may not be necessary if you have already whitelisted our outgoing IP addresses, but it's something to consider if you run into any issues.

UnreachableJoinError: The join task|route "XXXXXXX" is partially satisfied but unreachable.

This error is related to having multiple transitions going to a single action.

1. Click the Advanced tab within the action that has multiple transitions going to it.

2. Under the field Task Transition Criteria, you'll likely have a 0. This means that all actions previously have to be complete before that action will run.

3. Change this to the relevant number. For example, change to a 1 so that only one of the previous actions must complete before that action runs.

In the image above, the workflow chooses the RMM of the client. Then, depending on the result, it runs a script on that system. The client likely isn't going to have multiple RMMs, so only one of the script tasks is going to run.

However, they all merge into the final compile_results task at the bottom. By default, this workflow will fail, as it is expecting each script task to complete before hitting that final task.

This is where you would change the Task Transition Criteria Sensitivity to a 1. This states that only one of the tasks that come into it must have been completed.

If there was a workflow where you wanted to run on two instances then you would enter 2, for 2 tasks to be completed.