🎯 Getting Started🏫 Cluck University📚 Documentation📦 Prebuilt Automations📢 Updates
❓Additional Resources

Core Actions

Discover the Power of Rewst Core Actions

The Core Actions in Rewst are your gateway to the platform's vast array of intrinsic functionalities. These actions, usable right out of the box, offer features ranging from ad-hoc HTTP requests to document parsing. This guide offers a comprehensive overview of each Core Action, its usage, and its capabilities, aiding you in designing robust, versatile workflows.

How to Use Core Actions

Core Actions are used in the same way as regular actions within workflows. They are selected from the list of available actions, configured based on their parameters, and then added to the workflow at the appropriate place.

Here are some details of the available core actions:

No-Operation (Noop)

  • Description: Does nothing. Often used for logic or as a placeholder in the workflow.

  • Parameters: None.

  • Output: None

Ad-hoc HTTP Requests

Performs an HTTP request to a specified URL, supporting a variety of methods, body content types, and configurations. This is useful for interacting with APIs or other web services within a workflow, or for performing any other tasks that involve HTTP requests.

Parameters

  • URL: The URL to which the HTTP request is sent.

  • Request Method: The HTTP method to use for the request. You can select from the dropdown options (HEAD, GET, POST, PUT, DELETE, OPTIONS, TRACE, PATCH, PURGE).

  • Auth Username: The username for basic HTTP Authentication, if needed.

  • Auth Password: The password for basic HTTP Authentication, if needed. (This parameter is secret to ensure security.)

  • Allow Redirects: Specifies whether the HTTP request will follow redirects. By default, it's set to true.

  • Body: The body to send with the request. This parameter is not required if JSON or Files is provided.

  • JSON: The JSON body to send with the request. This field is not required if Body or Files is provided.

  • Files: Here, you can add files to be uploaded with the HTTP request using multipart/form-data. Each file requires the following information:

    • Field Name: The name of the form field (not the filename).

    • File Name: The name of the file.

    • File Contents: Contents of the file to upload.

    • File URL: A publicly-accessible URL to the file contents to upload.

    • Content Type: The MIME type of the file to include in the multipart field.

  • Cookies: Input the cookies to send with the request. You can add more than one cookie by clicking on the + icon.

  • Headers: Specify the custom HTTP headers to be sent with the request. You can add more than one header by clicking on the + icon.

  • Params: Enter the query parameters to be used with the HTTP request. You can add more than one parameter by clicking on the + icon.

  • Timeout: Enter the timeout for the HTTP request in seconds. The default value is 5.

  • Require Success Status: If you check this box, the task will fail if a non-2xx HTTP status code is returned. This is useful for identifying and handling HTTP errors during the task's execution.

Output: The action returns the content returned by the server in response to the HTTP request. This could be a success message, a failure message, a data object, or any other content that the server sends as a response.

Note: If you need more advanced security around calling particular endpoints, you can also use a Custom Integration in addition to this HTTP Request action. This allows for enhanced security and customization when interacting with your external APIs.

Create & Await Webhook Actions

Create Webhook: Allows for the creation of a one-off webhook for which can then be used by the Await Webhook action.

  • Parameters: This action requires the methods allowed to access the webhook, the response status, response headers, response body, and an expiration timeout.

  • Output: The output of this action is the webhook ID and the full URL of the webhook.

Await Webhook: Waits for a request to a created one-off webhook. Once a request is received, the workflow continues.

  • Parameters: This action only requires the ID of the webhook created from the Create Webhook action.

  • Output: The output includes the HTTP method, query params, headers, JSON or form/multipart data in the body of the request, and the timestamp when the request was received.

Email, SMS & Confirmation Actions

Send Mail: Allows for the sending of an email.

  • Parameters: This action requires a sender prefix (sender), with multiple options available, the recipient's email address (to), the subject of the email (subject), the title of the email (title), and the message body (message). It also has the option to render markdown as HTML (render_markdown).

  • Output: The task doesn't yield an output upon success. It will fail if there are any errors during the process of sending the email.

Send SMS: Allows you to send a text message to a specified phone number.

  • Parameters: This action requires the recipient's phone number (phone_number) and the text message (message) to be sent.

  • Output: The output of this action will depend on the implementation details. Usually, it will return a confirmation message or an error message.

Confirmation Email: Sends a confirmation email with reply options to a specified recipient.

  • Parameters: This action requires the recipient's email address (to), the subject of the email (subject), the title of the email (title), and the message body (message). It also offers user interaction buttons (buttons) and has the option to render markdown as HTML (render_markdown).

  • Output: If the action is correctly executed, a confirmation email will be sent.

Delay Workflow Actions

Delay Workflow For Period: Pauses the workflow for a specified duration.

  • Parameters: The number of days, hours, minutes or seconds to delay the workflow.

  • Output: No specific output, the workflow resumes after the specified delay.

Delay Workflow Until Date/Time: Pauses the workflow until a specified date and time.

  • Parameters: The date and time when the workflow should resume.

  • Output: No specific output, the workflow resumes at the specified date and time.

Mock Task

Overview

The Mock action is designed to provide you with the capability to simulate the result of a not yet implemented action. This is particularly useful during workflow development and testing phases as it allows you to simulate responses from services that are not yet available or are impractical to call during the development process.

When to Use

The Mock action comes in handy in scenarios such as:

  • When designing new workflows where certain steps are not fully implemented.

  • In testing stages, to simulate conditions without making actual calls to the services.

  • To create controlled conditions in your workflow for troubleshooting issues.

Input Parameters

The Mock action accepts the following parameter:

  • Mock Result: This parameter should contain the key / value pairs that you want to be returned by this action. You can press the + to add as many objects as necessary.

Example Usage

You are developing a workflow that is expected to interact with a service which is not yet implemented. You know the expected format of the response, and you want to build and test your workflow logic based on that response.

Let's say you know the response will look something like this:

{
  "name": "Rewsty",
  "valid": true,
  "message": "Successfully completed the task."
}

You can simulate this response using the Mock action as follows:

mock_result:
  name: {{ CTX.name }}
  valid: true
  message: Successfully completed the task.

While using the Mock action, the values can be literal Jinja expressions like {{ CTX.name }}above. The action will return this exact input structure wrapped inside a data object, and the Jinja expressions will not be evaluated but returned as is. The result of the action on the workflow results page would look like:

Result:

{
  "data": {
    "name": "{{ CTX.name }}",
    "valid": true,
    "message": "Successfully completed the task."
  }
}

This can be useful for catching issues early in the development phase such as incorrect Jinja expression usage, understanding how the workflow will handle dynamic data, or verifying that your workflow is properly constructed to handle the expected responses from services. It's a way to ensure that your workflow behaves as expected when it starts receiving actual dynamic data.

Debugging with Templates

Overview

The Debug action is a utility feature in our workflow system, specifically designed to assist with debugging and logging purposes. This action can help in understanding the flow of data within your workflows, troubleshoot problems, and generally help you understand what's happening at a certain point in the workflow execution. It logs the input parameters it receives and returns the same as its output.

When to Use

You might want to use the Debug action in the following scenarios:

  • When developing workflows, to see how data is flowing between tasks and actions.

  • If you're troubleshooting an issue, to inspect the data that's being passed around.

  • When you want to log specific information for auditing or reporting purposes.

Input Parameters

The Debug action accepts the following parameters:

  • text: This is a general-purpose text field that will be logged and returned by the Debug action.

  • template: This field takes a reference to a template in your environment that will be rendered and used as part of the action's input. The system will replace any variables in the template with its actual value at the time of template rendering.

Example Usage

Let's say we have a template named "Greeting Message" with content # Hey there {{ CTX.name }}.

We can use this template in the Debug action with the following parameters:

text: Testing Debug Action
template: Greeting Message

Assuming CTX.name is set to Rewsty, the rendered template would be # Hey there Rewsty.

The Debug action will log these parameters and also return them as its output. The results of the action on the workflow results page would look like this:

Result:

{
  "template": "# Hey there Rewsty",
  "text": "Testing Debug Action"
}

This tells us that CTX.name was set toRewsty, and the text provided with this action was Testing Debug Action. Using this, you can better understand the state of your workflow at the point this Debug action was executed.

Parse HTML Action

Overview

The Parse HTML action is a versatile tool within Rewst, geared to pinpoint and extract specific elements or data from HTML documents. It leverages the power of BeautifulSoup, a Python library recognized for extracting data from HTML and XML files effectively.

When to Use

This action is particularly beneficial in these situations:

  • Data Extraction: capturing specific information from the response of an HTTP request.

  • Content Clean-Up: sieving out only the necessary data from complex HTML content.

  • Web Scraping: automating the extraction of specific information from various web pages using defined tags, classes, or identifiers.

Action Parameters

The Parse HTML action accepts the following parameters:

  • HTML: The HTML content to be parsed. This could be HTML content from a webpage, obtained using the HTTP Request Core Action.

  • Class: Optionally finds HTML elements based on their class attribute.

  • ID: Optionally searches for HTML elements based on their ID attribute.

  • Query: Employs BeautifulSoup filters to specify the operation type:

    • find_all returns all instances of the defined HTML tag.