# Welcome to Rewst documentation Explore our guides and recordings to start automating in Rewst today. Click through our recommended shortcuts below, or use the nav menu to the left, organized to match the left side menu in Rewst.

			Cover image
Rewst Support	Contact and customer resources for help with using Rewst	/pages/sA4fcjhqwlu92LDunc0u	/files/5mbLuYxJafEHq5ngA6WH
Rewst Open Mic	Recordings and invites to our recurring live community hangouts	/pages/KDu7vPh8UKqjTLrNNK9a	/files/U6EielGqhQrEKgnAz0uu
Cluck University	Sign up for training in Cluck University to learn how to use Rewst	https://learn.rewst.io/	/files/KRcqEWcLJSRFl0XjagIL

			Cover image
Integrations	Setup and user instructions to integrate all your favorite tools with Rewst	/pages/MyVtJy4FSLxxZuApmytJ	/files/iOZFfHfsYoXjj9Q4Js0s
Crates	Browse available Crates in our collection of unpacking and user guides	/pages/kZqn2LpBU4jhFDuWXgJS	/files/MtIT6XqBuocBA05kIVgQ
Agent Smith	Our open-source command executor that fits into your Rewst workflows	/pages/fIpLMsRc6pvLNYaOvhWA	/files/o9XOhLMGvf8QvLeamvbx

## Get started with Rewst Not sure where to begin? We recommend these resources. Click on Cluck University links to launch that course in a new tab. Click on documentation links to take you directly to that page in this documentation site. ### Cluck University intro courses

		Cover image
Rewst crash course	Get oriented, get confident, get automating	/files/3F7e9pWxngNCaiNXzFr9	https://learn.rewst.io/rewst-crash-course
Automation Fundamentals	For MSP strategists and builders: Plan smart, build right, prove ROI	/files/ya5zXrgTHui2cDES9pXV	https://learn.rewst.io/path/automation-fundamentals
Cluck University catalog	View our total course catalog	/files/9EtPioINXjSuYpJ6WLFh	https://learn.rewst.io/page/course-catalog

### Documentation on Rewst platform basics


🤝 What is an integration?	/pages/OSnkx0SEHcbueeC19adV
🔀 What is a workflow?	/pages/yoHf2AVYDQJZiCRERlY8
✅ What is an action?	/pages/IgLWPsIO9ptzH8SN9qYe
📁 What is an organization?	/pages/MJ3qhY7mNpNU1O94ZhwK
📦 What is a Crate?	/pages/FLvdStgWDsLTcw5gA1vG
📝 What is a form?	/pages/Bd04lN8ZJ5yY9uJkNDRD
📄 What is a template?	/pages/Oo5ZGJt3Qt00dpcwtJ4V
⌨️ What is Jinja?	/pages/h4161dV8T01nADfw2O4K
🧑‍🤝‍🧑 What are users in Rewst?	/pages/gzxKSbCN6twFAlGzYgyr

# Coming soon to Rewst {% hint style="info" %} New Rewst features are currently in Beta with a planned general release for later in 2026. This documentation is regularly evolving to meet the needs of the changing product. We'll publish complete documentation for how to use the entire product upon general release. If you're one of our Beta users and want to submit feedback, please reach out via your dedicated Discord channel. This page is intended to act as a quick-start guide that points out the differences between existing Rewst and our new features. It will not help you use the current release of Rewst. RoboRewsty will not pull its information into his search and knowledgebase. {% endhint %} ## The Rewst Agent Whereas RoboRewsty referenced Rewst documentation to provide answers and follow directions, the Rewst Agent operates off of *playbooks*, structured procedures the agent must load before authoring workflows, forms, or apps. Each one enforces required reads, required contracts, ordered steps, and verification. Ask the Rewst Agent to build you anything that you could have built in Rewst before— only now, it will take the lead and do all the work for you. For anything the Rewst Agent builds, it will research, show a proposal with the exact nodes and field mappings, then ask once for approval. Nothing gets created, published, or run until you approve. If its proposal is off, just tell it what to change, and it will make adjustments and ask for approval again. Instead of having you manually build your automations to save time, new Rewst operates largely on you asking the Rewst Agent to build for you, for an even greater time savings.

## App Builder Like our previous App Builder, you can create sites in the new App Builder to suit your unique needs. But now, no coding knowledge is required to create and edit apps. Simply ask the Rewst Agent to make an app for you and let it create and refine the final product. For existing App Builder users, note that the new Builder has expanded components, offers full HTML editing capabilities without requiring you to add containers, and allows for greater thematic customization than its predecessor.

An app being worked on in the App Builder

## Form Builder Our new Form Builder has more than 40 components, a 4x increase in options from our original forms. In addition to two default themes of light mode and dark mode, MSPs can create unlimited custom themes. The Form Builder comes with multi-page support built in, including named pages and next/previous navigation at the form's runtime. Drag and drop components directly onto the Form Builder canvas for visually responsive form designing, no Jinja required. Or, ask the Rewst Agent to create a form for you, and watch as it picks the best components to achieve your desired goals.

A form being worked on in the Form Builder

Forms are now subject to *workflow binding*, where a form is 'bound' to a single workflow, from inside the form. Trigger setup for forms has also been relocated to within the Form Builder— no more back-and-forth navigating between two tabs to set up your form triggers. ### Options Builder Our new Options Builder replaces the original Options Generator and Options Filter features you're used to in Rewst and makes setting up forms to have options much easier. It supports hundreds of thousands of options There are two ways to populate options: * **Static** - for example, option A, option B, option C * **Workflow-backed** - choose a workflow that generates options and Rewst auto-maps label and ID using a heuristic, with manual override available * Workflow-backed components are disabled on public forms to prevent accidental exposure of internal data Filtering rules are built in to the Options Builder. Filter values populate from real data in the system, so MSPs select from actual identifiers instead of typing Jinja and risking typos. ### Access control Forms have four options for access, which can be set in the Form Builder. * **All suborganizations**, default: MSP owner and all suborganizations can authenticate at the runtime URL * **Owner only**: MSP only * **Selected suborganizations:** explicit allow-list * **Public forms:** no login required You can also create form-level exceptions per customer, without cloning the form. Add components that only exist for one organization, or hide specific components for select organizations. ## Workflow Builder The Rewst Agent can build your workflows and any associated forms or scripts for you, all stemming from your query. Alternatively, you can build and edit workflows manually in our new Workflow Builder, just like you always have in Rewst.

The left side menu of the Workflow Builder now contains *nodes*, the individual elements you can drag and drop onto the Workflow Builder Canvas. Nodes for particular integrations that you have already set up in Rewst will appear here, along with triggers, and any AI presence that Rewst has access to. ## Integrations Our new Integration Builder simplifies the existing Rewst integration process into one streamlined menu. Choose from verified Rewst integrations built by the Rewst team, or ask the Rewst Agent to add your own integrations for whatever apps you choose using that same process— no more Custom Integration setup like there has been in the existing Rewst platform.

Integrations are split into three components for easier reuse and sharing: authentication methods, credentials, and the integration itself. * Authentication methods are reusable across multiple integrations * Credentials are reusable across integrations and are stored as a managed entity * Custom authentication methods can be created ## Settings The next generation of Rewst has a robust permissioning system and granular settings that allow you to use Rewst the way that best suits you and your MSP. You'll still need to manually configure SSO setup and user invitations, but the Rewst Agent can guide you through what every setting means and how to adjust each to your particular situation. ### Agents Build your own agents to work in the platform. Custom agents allow end users to interact with Rewst automations in whatever way they desire, from platforms outside of Rewst. ### MCP server The Rewst MCP server gives your AI coding tool direct, authenticated access to your Rewst tenant in the live platform. Create tokens for AI tools like Claude Code to access Rewst APIs. After creating a token, add the Rewst MCP server to your AI coding tool to: * Build and edit automations from your editor * Let the server can see what's actually connected in your tenant: integrations, workflows, forms, apps, real field names, etc. * Debug runs without leaving your tool ## Security The Rewst Agent has been designed with modern security practices and approaches in mind. Updated security documentation and architectural details will be released shortly before general access for the platform. The new Rewst features are included in our currently running SOC 2 audit and GDPR compliance audit, with our updated, full reports available in Q4 of 2026. {% hint style="info" %} Do you have questions or want to learn more about the new changes coming to Rewst? Reach out to for more information if you're not an existing Rewst customer, or if you are a current Rewst customer. {% endhint %} # AI basics If you're newer to AI, read through this document to get up and running with some of the terms you'll need to be familiar with to properly use Rewst. For more information on how our existing AI chatbot RoboRewsty works, see his documentation [here](/documentation/roborewsty). ## What is AI? How is it different from automation? *Automation* follows predefined rules and specifically set instructions to perform repetitive tasks exactly the same way every time. *Artificial Intelligence*, or *AI*, is designed to learn from data, adapt to new information, and make decisions in unpredictable situations. *Generative AI* produces content like text, images, or code from learned patterns but can't reason its way through a problem or initiate action on its own. Rewst is moving towards using both AI and automation together as a joint solution, which will offer MSPs the greatest possible benefits in agility and efficiency. ## What is an LLM? An *LLM*, short for *Large Language Model*, is a type of AI designed to understand, process, and generate human language. It functions as a highly advanced autocomplete system, trained on vast amounts of data to predict and produce coherent, contextually relevant text. ## What is an agent? How is it different from RoboRewsty? An *AI agent* is an autonomous software system that uses artificial intelligence to perceive its environment, make decisions, and take actions to achieve a specific goal. Unlike basic chatbots like RoboRewsty that only respond to prompts, agents can plan multi-step workflows, use external tools, and remember past interactions. * RoboRewsty is reactive. He answers specific questions or executes predefined commands, requiring continuous human direction. * The Rewst Agent is proactive. You give it an end goal and it will plan and execute the necessary actions on its own. ## What is Agentic AI? *Agentic AI,* related to agents, relies on LLMs to carry out tasks on behalf of users. Imagine that you need to reset a password and simply describe what you want in plain language. The AI agent can understand that goal, interpret the intent behind the request, develop a plan for achieving it, and call on the right tools to see it through— all without you the MSP manually involving yourself beyond your request. This ability to process natural language, reason through problems, and make decisions in order to act independently is what sets agentic AI apart from other forms of AI and automation. Rather than waiting for human oversight at each step, AI agents can manage entire workflows, respond to changing conditions, and adapt to new tasks and information as they arise. Where basic AI automations follow predefined rules and stop there, agentic AI goes further by interpreting instructions and taking action based on real-time input. ## What is a prompt? A *prompt* is an instruction, question, or input you give to an AI system to guide its response. It's the primary way humans communicate with AI tools and can be a simple sentence, a detailed paragraph, an image, or uploaded files. When you entered a question about your workflow into RoboRewsty, you were prompting him to guide his response. You'll make similar prompts to The Rewst Agent. ## How do I make good prompts? The Rewst Agent needs quality instructions to know exactly what you want it to do and act intelligently on your behalf. Start with a solid objective, break complex instructions into step-by-step formatting, give any necessary background or constraints for what you are trying to achieve, and include specific examples to guide the output. For The Rewst Agent in particular, a successful prompt includes: * Outcome, not just steps * "When a ticket closes, post a summary to Slack" tells more than "use the Slack node." It can pick the right nodes if it knows the goal. * The trigger * What kicks this off: A manual run, a form submission, a schedule, or an event like a new email or new ticket? * The systems involved * Name the actual integrations — ConnectWise, Microsoft Graph, HaloPSA, Slack, etc. * The Rewst Agent verifies what's actually installed on your organization before proposing anything. Naming them lets it check and respond to your prompt more quickly. * Scope * Do you want one workflow, or a form and a workflow? Is your goal an app in App Builder? Include whether you want the creation run and tested after building, or just created. * Information that's specific to external systems * This is where vague prompts cost the most time. The Rewst Agent is strict about not guessing external contracts. * Include the exact business subset, in your words — "Only active agreements," "tickets in the triage queue," "users licensed for E3." It will map your phrasing to the real status values by checking the integration contract and sample data, but needs to know the intent. * Consider required record selections. If a mutation needs a company, board, queue, status, or member, indicate whether you want to (a) provide an ID/name, (b) have The Rewst Agent show you a picker, or (c) build a reusable form. It won't enumerate your records unless you ask. * Values it can't infer are things like a target ticket priority or a specific channel. If it's a closed choice, The Rewst Agent will either look up the valid options or ask you for the exact value. #### Example prompt > "When a new email hits our shared mailbox in Microsoft, create a ConnectWise ticket on the Service Board, and only if the sender is from an existing company. Build it and run a preview so I can check." This gives The Rewst Agent a trigger, systems, outcome, a conditional, and how to verify. It contains enough to research and propose without a round of clarifying questions. ## What is an MCP? The *Model Context Protocol (MCP)* was open sourced by Anthropic in November 2024 to provide users and developers with an easy way to extend the capabilities of AI-powered apps by integrating them with data sources and applications. An *MCP server* is a small program that acts like a bridge between an AI tool and another piece of software. It provides context for language models— like Claude or ChatGPT— to interact with resources, run tools, and do whatever else you can think of. Instead of having the model to guess how a tool works or what data would be needed, the MCP server presents information in a format the AI tool can understand and interact with.\ In Rewstʼs case, the MCP lets approved AI tools see and use specific Rewst workflows that you choose to expose. Think of it as a safe, controlled way for an AI tool to call your Rewst workflows. Our MCP server can help you by:\ • Discovering eligible workflows using natural language\ • Running approved automations directly from supported AI tools\ • Retrieving workflow results and insights without logging into the platform\ • Using conversational AI to explore and understand how your workflows operate # Rewst Dashboard The Rewst Dashboard is the home screen you'll see when you first log into the platform. Click the drop-down organization selector in the top right to choose which org's information will be displayed in the dashboard at any given time. Use the dashboard to easily digest key metrics for every workflow executed within a selected timeframe and better understand how Rewst is bringing you value. Identify usage patterns, success rates, and estimated time savings.

Screenshot of the Rewst dashboard analytics view showing February 2026 metrics, including charts for tasks performed, time saved, and workflow status. The dashboard is depicted in three shades of dark blue, with bar graph in the center of the screen to display the month's information. — The top of the Rewst Dashboard screen

Choose to view the data in your desired timespan by clicking the relevant button at the top right of the dashboard for either **Weekly** or **Monthly** views. Note that the default for the dashboard timeline is monthly. Click **<** or **>** next to the indicated date to skip between date ranges. Click **Download CSV** to export the report to a file. {% hint style="info" %} Additional options to view metrics on a daily basis are coming soon! {% endhint %} The **Tasks Performed** chart shows all tasks performed in the prior month or week for your selected organization. The **Time Saved** chart shows the total time saved by using your Rewst automations in the prior month or week for your selected organization. {% hint style="info" %} This estimate is generated from the time saved number entered in your workflow's settings, as well as Rewst's baseline assumption of the manual effort required without automation for prebuilt automations like Crates. An estimate of zero means your estimate was never filled out. To resolve a zero estimate, navigate to the workflow and enter the time saved estimate there.\ \ If you have a workflow that has been running without a time saving value, and you add that value later, your dashboard won't retroactively update to reflect that time savings. Calculation and tracking begins when you add a time savings value. {% endhint %} The **Workflows** menu shows stats for how many workflows in your selected time period were running, as well as how many executions were successful and how many errors were given. The time period selected at the top of your dashboard will determine the time period displayed in the widget. Scroll further down the Rewst Dashboard page to see the **Workflows** widget. The data in this section updates daily.

A user interface displaying a table of word counts with columns for total words, word generations, and other related metrics. The table has a dark background with light text, showcasing various entries and pagination controls at the bottom. — The lower workflow widget, viewable at the bottom of the Rewst Dashboard page

This section of the dashboard provides a centralized view of individual workflow usage metrics in separate columns: **Success Rate**, **Total Executions**, **Total Tasks**, and **Time Saved**. Click on any individual workflow in the widget's workflow list to open that workflow in the workflow builder canvas. Use the fields at the top of each column to enter search and filtering parameters to find your desired workflows. Click **Download CSV** to export the workflow data to a file. # Automations # Workflows ## What is a workflow? *Workflows*, made up of [actions](https://docs.rewst.help/documentation/workflows/actions-in-rewst) and [triggers](https://docs.rewst.help/documentation/intro-to-triggers), are the main component of Rewst's automated business processes. They gather relevant data from integrated tools such as a PSA or RMM, process it using conditional logic, and execute automated actions relating to that data. Workflows are the key to unlocking automation in Rewst. [Crates](https://docs.rewst.help/prebuilt-automations/crates) contain pre-built workflows. Workflows can also be built from scratch, or edited to match your custom needs. {% hint style="warning" %} We recommend you only edit the pre-built workflows that come in Crates after taking our courses in [Cluck University](https://learn.rewst.io). This is a more advanced way to use Rewst. Before building any workflow, remember to sketch out what you'd like the workflow to look like, and identify the trigger that will kick it off. {% endhint %} {% hint style="info" %} As of mid 2025, Rewst also offers *kits.* A kit is a collection of pre-built, pre-defined actions that provide a quick start to setting up solutions to specific business needs, or to demonstrate all available actions within a given integration. For example, if you have a Halo PSA kit, there will be actions or automations Rewst has identified that are smaller use cases compared to our larger Crates. Kits are a newer feature of our Crate Marketplace. Check back as the collection grows. See our up-to-date list of available kits [here](/documentation/automations/kits). {% endhint %} ## Why build workflows? While the pre-built workflows in Crates are the quickest way to get started, a workflow built custom to your situation can offer powerful, personalized efficiency measures that fit your particular MSP and customer needs. ## Find and use workflows in Rewst Access workflows in the Rewst platform by navigating to **Automations > Workflows** in the left side menu. Click **Create Workflow** to create a new workflow from scratch.\

Screenshot of the Workflows list view in the Rewst Automations section, showing a dark-themed interface with a left navigation menu, a top search bar and Create Workflow button, and a table of workflows with colored tags, attributes, update details, and configuration actions. — The workflows list page, without any filters applied

The list of workflows that appears in the center of your workflows list screen will include both the workflows you create and the workflows unpacked from Crates. As you continue to set up automation in Rewst, this list can grow quite a bit. The **Updated At**, **Updated By**, **Attributes**, and [**Tags**](https://docs.rewst.help/documentation/workflows/tags-in-rewst) columns each offer the option to filter your results by relevant criteria, with attributes and tags filters operating for both inclusion and exclusion of desired parameters. Use **Search** in the top center of your screen to find a particular workflow, and the

icon to the right to choose which columns you'd like to see in your workflows list.

Rewst will notify you when we make changes to actions that affect your workflows. These notifications will appear in the workflows page. Learn more about those notifications in our documentation for our [action version log](/documentation/automations/actions-in-rewst#action-version-updates). Once you create a workflow, you'll be taken to the [*Workflow Builder*](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow), a Canvas for assembling your workflows. See our documentation for how to use the Workflow Builder [here](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow). ## Synced versus unsynced workflows Synced workflows unpacked from Crates can't be edited, and automatically update when Rewst makes changes. You have the option to unsync a workflow, which can be useful for using a Crate workflow as a building block for creating your own customized workflow. For more on synced workflows, including how to identify them, see our documentation on Crates and syntonization [here](/documentation/crates#synced-versus-unsynced-crates). ## View specific workflow results The general results page will show you the results of every workflow that has run in your organization. Apply a date range filter to view execution results from a specific time period, up to 30 days prior. To see all results for a specific workflow, you can do the following: 1. Navigate to **Automations > Workflows**. 2. Search for the specific workflow. 3. Select

in the far right corner for that specific workflow. This will take you to a new page that will show all the results of that workflow.

A user interface displaying a 'Workflows' section with a dark background. It includes search and filter options, a list of workflows, and buttons for actions such as 'Configure' and 'Trigger' beside a specific workflow titled 'Integration Checklists and WBS.'

{% hint style="info" %} When you delete the result of a workflow, consider it to be fully deleted. Only delete results when you are confident that they will not be needed. The result will remain in Rewst's database backup snapshots for a short length of time until it is past the retention period, at which point it will be purged. Meta data and stats about the deleted workflow execution remain in the system. Deleting a workflow execution will not affect time saved or remove time saved. {% endhint %} ## View triggers for a specific workflow From the workflows page, you can view triggers associated with each workflow, without leaving that page. Hover over the workflow's **triggers** count in the **Attributes** column to see a list of every trigger linked to your workflow, and toggle each on or off to suit your needs.

The dialog that appears when hovering over trigger counts

### Export and import workflows You can export a workflow to share with other Rewst customers, or create your own hard copies of workflow backups. To export a workflow as a JSON bundle, navigate to the [Workflow Builder Canvas](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow#workflow-builder) and find the export option under the **Workflow Options** menu. To import a workflow bundled as a JSON file, click **Import Bundle** in the top right navigation bar of the workflows page. Then, drag and drop your file into the upload dialog that appears.

## Subworkflows A *subworkflow* is a workflow that is also a part of another workflow. In Rewst, every automation can function as either a larger executing workflow or a smaller subworkflow. Subworkflows help you simplify complex processes, reuse logic, and manage error handling and data gathering cleanly in your Rewst automations. You can create your own subworkflows, or use one of our pre-built subworkflows, cataloged in [this section of our documentation site](/documentation/automations/subworkflows). In the example below, you have a main workflow called **Create Ticket**. In it, you choose which PSA the organization has. Once that has been decided, you then go to a subworkflow, which encompasses the actual creation of the ticket. Note the light teal border and

icon on the action, denoting that it is a subworkflow. Click **⋮** on a subworkflow to navigate directly to it or delete it from the Canvas. You can also view subworkflows on the main workflow page, indicated by the green **Subworkflow** button under the **Attributes** column. Clicking will reveal which workflow the subworkflow is a part of.

An image of a small subworkflow, flowing out of a larger executing workflow. The subworkflow is composed of actions, via rectangles outlined in pink. The flow of subworkflow out of larger workflow is communicated via blue directional arrows. Under each subworkflow action, there's the option to click a blue plus button to add additional actions on success or failure of that action. — An example of subworkflows, flowing out of a larger executing workflow

The Subworkflow button, under the **Attributes** column of the workflows list page

To create your own subworkflow from scratch, simply create a new workflow in the Workflow Builder and publish it. That new workflow will appear in the **Workflows** section of the Workflow Builder's actions menu, and you can drag it onto any other Workflow Builder canvas to be used as a subworkflow.

A moving image of a user scrolling down a left side rectangular menu to find their selection. The user then clicks and drags the desired item from a menu titled 'Workflows' onto the right side of the screen, where it rests and appears as a new rectangle. It contains a pink circular icon to identify itself as a subworkflow. — Remember, subworkflows will appear on your Workflow Builder canvas with a teal color to help
you keep track of your action types.

There are a few reasons to set up subworkflows. * Ensure a tidy workflow. Rather than having 20 steps per PSA on a single workflow, we can split it up for convenience and ease of understanding. * When addressing various objects, the equivalent of a [for each](https://docs.rewst.help/documentation/workflows/configuring-your-workflow-tasks/advanced-workflow-operations#with-items), we can pass all of the objects to a sub-workflow and get the output back of each object. * Run logic inside a subworkflow to isolate errors, apply retry or skip logic, and handle failures cleanly while using [with items](/documentation/automations/workflows/advanced-workflow-operations-menu), without failing your parent workflow. * This is typically the best method for using with items loops inside Rewst. This allows you to run checks and balances on each iteration to prevent or handle possible failures on a per-item basis. * Subworkflows allow you to write a workflow once and reuse it multiple times. Subworkflows also accept parameters, making them adaptable for different use cases. * Smaller, self-contained workflows are easier to test and debug individually. ### Configure the subworkflow inputs and output 1. Click **⋮ > Open Subworkflow** on the dragged subworkflow to open it in the Workflow Builder Canvas. 2. Click

to open the workflow settings. 3. Configure which data comes into the subworkflow, and which data you want returned to the parent workflow upon completion— your [inputs and outputs](/documentation/automations/workflows/data-input-and-output-input-variables-and-context-variables). There are a variety of input types, which will differ depending on your subworkflow.

A screenshot of a sub-workflow configuration screen. At the top, there are sections labeled "Variable Configuration" and "Input Configuration" with a plus icon. Three input fields are defined: list (type: List) with default value {{ [ ] }}, description "used for passing JSON object," optional required checkbox. boolean (type: Boolean) with default value {{ true }}, description "true or false," optional required checkbox. input_configuration (type: Text) with description "configure Inputs in the sub-wf," optional required and multiline checkboxes. Below, an "Output Configuration" section contains a field: output_data with value {{ "The sub-wf test data" }}. Each entry includes text fields for name, label, type, default value, and description, along with a red "Remove" button. At the bottom, there are "Cancel" and "Submit" buttons. Highlighted in red boxes are the "Input Configuration" and "Output Configuration" headers, as well as a pencil icon in the top-right toolbar. — An example of the **Input** tab of a subworkflow's workflow settings

{% hint style="info" %} *Workflow wrapper* is an informal term sometimes used colloquially by the ROC to describe a situation where a primary workflow is used in a separate workflow as a subworkflow. More information on workflow wrappers can be found [here](broken://pages/fm8eIBTHO3CnDr23CZjX). {% endhint %} ### Enable publish results in the parent workflow This setting publishes the configured output, allowing your parent workflow to use the results of the subworkflow immediately. 1. Find your desired subworkflow in the **Workflows** actions menu in the left side of the Workflow Builder. 2. Drag your subworkflow from the actions list to the Workflow Builder Canvas within your parent workflow. 3. Click on the subworkflow to open its settings in the right side menu. 4. Enter `sub_wf_results` in the **Publish Results As** field. 5. Click **Deploy**.

### Access subworkflow data Results for subworkflows are nested inside published results for workflows. For example, the following Jinja would contain the subworkflow data. ```django {{ CTX.sub_wf_results.output_data }} ```

## Additional workflow documentation {% content-ref url="/pages/LxXpAXU9SC77w7l2zCeD" %} [Workflow builder: How to set up a workflow](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow) {% endcontent-ref %} {% content-ref url="/pages/IgLWPsIO9ptzH8SN9qYe" %} [Actions](/documentation/automations/actions-in-rewst) {% endcontent-ref %} {% content-ref url="/pages/Xxy8F0zJJD7iXAXaLy1p" %} [Task transitions](/documentation/automations/workflows/task-transitions) {% endcontent-ref %} {% content-ref url="/pages/tycqCa6n1r9V0j7kqERO" %} [Data aliases](/documentation/automations/workflows/data-aliases) {% endcontent-ref %} {% content-ref url="/pages/PEwFqA4KStYUjn677hg1" %} [Best practices for designing workflows](/documentation/automations/workflows/best-practices-for-designing-workflows) {% endcontent-ref %} {% content-ref url="/pages/9SdRfd65iSwDE2J8wZKy" %} [Advanced workflow operations menu](/documentation/automations/workflows/advanced-workflow-operations-menu) {% endcontent-ref %} {% content-ref url="/pages/6LhkPJebg1zmkMdT9ejM" %} [Data input and output: Input variables and context variables](/documentation/automations/workflows/data-input-and-output-input-variables-and-context-variables) {% endcontent-ref %} {% content-ref url="/pages/sRoXnINfQMRBHYE6aeHT" %} [Option generator workflows](/documentation/automations/workflows/option-generator-workflows) {% endcontent-ref %} {% content-ref url="/pages/AKizolU9D5moj0PmITRM" %} [Boolean logic in Rewst workflows](/documentation/automations/workflows/boolean-logic-in-rewst-workflows) {% endcontent-ref %} {% content-ref url="/pages/LmbPpKzrF3RsUtknUtvs" %} [Kits](/documentation/automations/kits) {% endcontent-ref %} {% content-ref url="/pages/BNgwED5SFXGx9NU8Mzjr" %} [Subworkflows](/documentation/automations/subworkflows) {% endcontent-ref %} # Workflow builder: How to set up a workflow {% hint style="info" %} Remember, the [Core](/documentation/automations/actions-in-rewst/core-actions) actions category contains your base actions that apply for all integrations. The [Rewst](/documentation/automations/actions-in-rewst/rewst-actions) actions category holds actions form the foundation of your interaction with the platform. The [workflows](/documentation/automations/actions-in-rewst/workflows-actions) actions category contains any existing workflows in the workflow list for the related child organization. The other categories contain actions that apply to that particular brand of integration. {% endhint %}

A blank workflow builder canvas, as seen for a freshly created workflow

The start screen of the Workflow Builder Canvas has three quick start tiles, which will disappear as soon as you drag any element onto the Canvas. ## The Workflow Builder toolbar {% columns fullWidth="false" %} {% column %} ### ![](/files/kf5RjEiYOPcxT7XJLC3R) {% endcolumn %} {% column %} Use the top left toolbar to open, view, and use the features of the workflow builder. {% endcolumn %} {% endcolumns %} * Click

to expand or collapse the general left side menu of the Rewst platform. * Click

to reveal the **Library**, where all your actions, triggers, subworkflows and favorites can be found. Read more about it in the [**Library**](#library) section of this document. * Click

to undo or redo your last change. * Click

to open the **Settings** menu for your workflow. See more about this menu in the [**Settings**](#settings) section of this document. * Click

to open the additional **Canvas** controls menu. * Zoom in, out, or to fit. * Enable compact auto layout to reduce spacing between nodes. Toggling the setting on doesn't immediately re-layout the canvas. The setting only takes effect the next time you run auto-layout. This preference carries across sessions and workflows. * Choose from vertical or horizontal layout for your canvas. * Check the view on and off for **Snap to Grid**. * Click

to **Show All Comments** or **Hide Comments**. * For seasoned Rewst users: Our feature previously called Notes has been renamed to Comments. * Comments are a great way to jot down your thinking behind workflow aspects, and an essential step to building workflows for any team that has multiple employees editing workflows. They save in the workflow itself, and can be viewed by anyone who has permissions to edit that workflow. Adding notes is disabled for synced clone workflows. Center screen, the toolbar contains a drop-down selector for additional options for your workflow. This is also where you can toggle back to the legacy view of the Workflow Builder. * Click **Rename** to change the name of your workflow. * Click **Edit Workflow Attributes** to add a new tag or choose an existing tag from the drop-down **Tags** selector.

* Click **Edit Workflow JSON** to open the JSON editor in the right of your screen. * Click **Version History** to open a menu on the right side of your screen displaying the record of when the workflow was created and edited. You also have the option to revert back to a previous version of your workflow, or view previous versions to compare changes. * Click **Execution History** to view the list of execution results for the workflow, including their success or failure status. * Click **Export** to [export a workflow](https://docs.rewst.help/documentation/automations/workflows#export-and-import-workflows). * Click **Clone** to create an exact copy of your workflow without changing the original. The window that appears is the failsafe to confirm that you want to clone the workflow. In it, you can do the following: * Give your clone a different name from the original * Choose the organization where the workflow will be cloned to with the drop-down **Organization** selector * Choose to **Synchronize Changes** with the original workflow - any changes you make to the original workflow will be reflected in the clone if this is toggled on * Click **Delete** to delete your workflow entirely.

## Publish a workflow In the top right corner of the Workflow Builder Canvas, you'll find the options to test and publish your workflow. Click **Run** to test the workflow via an execution. This will open a new dialog where you can choose the organization for your test.

Click **Deploy** to deploy the workflow fully. Before you deploy you'll be asked to confirm that you wish to make this decision.

## Library {% columns fullWidth="false" %} {% column %}

{% endcolumn %} {% column %} The **Library** menu contains three distinct tabs: 1. **Actions** holds a complete list all available actions and subworkflows. At the very bottom of the list is **+ Add Integrations**, which launches the option to add a new integration to Rewst. Note that this is intended to allow you to add an integration quickly and facilitate the completion of workflow design, not to replace the full integrations menu. Any integration added through the library that requires [organization mapping](/documentation/integrations#what-is-organization-mapping) will need to be mapped from its full integration page.\ Integration actions are divided by categories, viewable after you click into the integration. If you search within an integration, results will be scoped to that integration only. This rule applies for custom integrations in addition to Rewst-native integrations. 2. **Flow Control** contains the option to add a new Trigger, as well as a list of all triggers already added to your workflow.

3. **My Library** stores your bookmarked, favorite actions. Click the bookmark icon on any action to add it to the My Library list.

{% endcolumn %} {% endcolumns %} At the very bottom of the menu you have the option to add a new custom integration. 1. Click **Add Integrations +**. 2. The dialog that appears contains many fields for information needed to set up the integration. Pull that relevant information from the partner app you wish to integrate. 3. When finished, ## Canvas view settings {% columns %} {% column %} The canvas view menu is located on the left side of the Workflow Builder canvas. **+** and **-** zoom the view in or out. ![](/files/PoDy6xAqST8EjLXwgQcE) snaps the view to fit the entire workflow into the center frame of your screen. ![](/files/VCWE5yTjWrnS1oYQnCoV)toggles the visualization interactivity of the workflow on or off. See more about this in the [#view-task-flow](#view-task-flow "mention") and [#view-trigger-flow](#view-trigger-flow "mention")sections of this document. {% endcolumn %} {% column %}

{% endcolumn %} {% endcolumns %} Compact view ## Add transitions between actions To add a transition, hover over your desired starting action. Note the circles on the right and bottom on the action. These represent the action’s outputs, and are where you can create transitions to following. The triangle on the top and left of the action are inputs into the action, and where you can connect a transition. Click on the circle under or to the right of the action, drag, and release on the top of the ending action where you would like the transition to conclude.

The diamond that appears between the two actions is the *transition indicator*. Click on it to open the transition settings menu. {% columns fullWidth="false" %} {% column %}

{% endcolumn %} {% column %} \ From this menu you can: * Optionally add a **Custom Transition Label.** * Choose the **Condition** of your transition. - note the appearance and meaning of the condition statuses in the table below, the symbols of which will appear in your transition indicator once chosen. * Add a data alias.

{% endcolumn %} {% endcolumns %} | Transition indicator symbol | Label | Meaning | | --------------------------- | ----------- | --------------------------------------------------------------------- | | ✓ - Check mark | **Success** | The transition will only be followed if the preceding action succeeds | | ✗ - X mark | **Failure** | The transition will only be followed if the preceding action fails | | ↻ - Circle/always | **Always** | The transition will be followed regardless of the action outcome | | { } - Braces/custom | **Custom** | The transition uses a custom Jinja condition | ## View action flow View the relationship between actions via the animation depicted on their transitions. Note that the way the animation flows depicts the order of the actions in the workflow. You'll need to to run the workflow or pull up an execution histoy and select an execution for the animation to kick on. It automatically turns off when you return to the edit view in the Workflow Builder Canvas.

## View trigger flow Triggers appear directly on the Workflow Builder Canvas, and have an arrow to visually indicates which action the workflow will start executing when that trigger fires.

## General settings The **Settings** menu has distinct tabs, each with its own configuration options.

* **General** provides a field to view and edit the **Workflow Name**, as well as the **Workflow Timeout** in seconds, the **Time Saved** in seconds, and a drop-down selector for the **Workflow Type** - either Standard, Option Generator, or Stream Output. Here you can also choose to **Delete Workflow** or **Download Workflow as JSON** file. * **Data Aliases** displays a list of all defined [data aliases](/documentation/automations/workflows/data-aliases). * **Input** displays existing input configuration, as well as options to **Add Schema** or **+ Add Input**. * **Output** displays existing output configuration, as well as options to **Add Schema** or **+ Add Output**. * **Variables** displays existing variables, as well as an option to **+ Add Variable**. * **Triggers** displays existing [triggers](/documentation/automations/intro-to-triggers), as well as an option to **+ Add Trigger**. * Click **+ Add Trigger** to reveal the **Trigger Settings** menu. Each of the tabs contains the following options. Remember to click **Save Trigger** at the bottom of the menu when finished making your selections. * In the **General** tab: * Here you can update the fields for **Trigger Name**, **Trigger Mode**, and **Trigger Type**. * Under the **Mock Results** and **Workflow Input Parameters** menus, the **Query Conditions** fields allow for the entering of string values only. * Any previously set trigger variables will appear here in the **Trigger Variable** section. * In the **Overrides** tab: * **+ Integration Override** reveals a list of all integrations and allows you to specify which integration configurations should be used. Otherwise, the default integration configuration for the triggering organization will be used. * **+ Add All** will add integration overrides for all installed integrations in the organization. * In the **Criteria** tab, set up your [trigger criteria](/documentation/automations/intro-to-triggers/trigger-criteria). * In the **Run For** tab, choose your [Activate Triggers to Run For](/documentation/automations/intro-to-triggers#activate-trigger-to-run-for) settings. * **Edit JSON** provides three separate code editors, including one each for **Trigger Outputs** and **Action Parameters**.

## Action settings Click into your action to open the **Action Settings** menu, which contains four tabs. **General** - This includes: * **Task Name** - A user-editable field for the action's identifier * **Description** - A user-fillable text box for additional action information * **Output -** Specifies where the action's output gets stored in the task logs * **Publish Result As** - A friendly name you assign for the action's results that you can use as an a context variable for calling it's content in future actions * **Time Saved**: - This is for just the time saved by that action- see more about total workflow time savings in [this section](#add-time-saved-to-a-workflow) of the document * **Edit Task JSON** - Opens the action's code editor

**Parameters** - Unique to each action, this tab houses options for defining the action's behavior during execution. Think of them like fill-in-the-blank options that make workflows adaptable. **Testing** - This tab provides the option to simulate the action's function with a user-defined result, useful for testing and debugging. Toggle **Mock this action** on or off. Click **Add Mock Result** to add additional guidelines for JSON content to be returned by this action to the **Mock Results** list.

**Advanced** - Here you'll find settings for several advanced action properties. The use and purpose of each is more fully documented [here](https://docs.rewst.help/documentation/automations/workflows/advanced-workflow-operations-menu#integration-overrides). * [**Integration Overrides**](/documentation/automations/workflows/advanced-workflow-operations-menu#integration-overrides) * [**Task Transition Criteria**](/documentation/automations/workflows/advanced-workflow-operations-menu#task-transition-criteria-sensitivity) * [**Run as Org**](/documentation/automations/workflows/advanced-workflow-operations-menu#run-as-org) * [**With Items**](/documentation/automations/workflows/advanced-workflow-operations-menu#with-items) * [**Items Concurrency**](/documentation/automations/workflows/advanced-workflow-operations-menu#items-concurrency) * [**Task Timeout**](/documentation/automations/workflows/advanced-workflow-operations-menu#task-timeout) * [**Security Features**](https://docs.rewst.help/documentation/jinja/jsonpath-for-data-redaction-in-rewst) * **Redacted Input Parameters** * **Redacted Output Parameters** ## Trigger settings Click and drag **Trigger** under the Flow Control tab of the Library to add a new trigger to your Workflow Builder Canvas. This will reveal a new menu to the right with your **Trigger Settings** that contains four tabs. **General** - Set your **Trigger Name**, choose the **Trigger Mode** and **Trigger Type**, and toggle your trigger to **Enabled** or **Disabled**. Under the **Trigger Parameters** menu, set your timezone, Cron Schedule, and [Critical Timing](/documentation/automations/intro-to-triggers#critical-timing). Under the **Trigger Variables** menu, any workflow variables set in the workflow settings will appear. **Overrides** - Add [Integration Overrides](/documentation/automations/intro-to-triggers#integration-overrides) for the trigger. **Criteria** - Add [trigger criteria](https://docs.rewst.help/documentation/automations/intro-to-triggers/trigger-criteria#save-trigger-criteria) to filter trigger events. **Run For** - Choose which organization or organizations to activate the trigger to run for. Here you can also choose tags to select activation. ### Completion handlers: Inbound and outbound triggers In the new Workflow Builder, the concept previously known as a completion handler is treated as triggers instead. Find these in the trigger menu under the **Trigger Mode** drop-down selector. Read more about how to use inbound and outbound triggers in our [triggers documentation](/documentation/automations/intro-to-triggers).

An **Inbound** selection will set the workflow to trigger by another workflow. An **Outbound** selection will trigger another workflow to run when this workflow completes. ## Test workflows

In the dialog that appears after clicking **Deploy**, click **Show Detailed Changes** to expand the accordion and display a side-by-side comparison of your original workflow and all changes that would be published.

Click **Run** to initiate your test, then click to confirm that you want to **Run Test** in the dialog that appears.

After your test is complete, view the workflow execution results in the right side menu. Click on any of the events in the execution log to expand and view information. Click **View Results** to launch a new browser tab with the complete results, in the Rewst platform outside of the Workflow Builder. When satisfied with your workflow, then click **Deploy** and **Submit** to save your changes and implement them on all future runs.

{% hint style="success" %} Inbound and outbound trigger data is hard to fake for testing, as it's represented as `COMPLETED_WORKFLOW.` instead of `CTX.COMPLETED_WORKFLOW.` Rather than running an entire workflow multiple times to test just this one element, create a [noop action](https://docs.rewst.help/documentation/workflows/actions-in-rewst/core-actions#no-operation-noop) that sets the test data, and use it to trigger your inbound our outbound trigger. In the noop, set all of the variables that will be used in the On Success transition as data aliases. It’s important that the names of the data aliases you create in the On Success transition of the noop match both: * the names of the variables that will be used in your inbound or outbound trigger * the names of the variables that will be used in the live parent workflow that your trigger is triggered by Add static values that represent a good test case for ensuring that your related workflow functions the way you expect. {% endhint %} ## Build a workflow ### Create the workflow 1. Click **Create**. 2. Give your workflow a **Name**, and add any tags you would like via the **Tags** drop-down selector. 3. Click **Submit**. This will launch the Workflow Builder. ### Set up the trigger {% hint style="success" %} Recall that every workflow is kicked off by a trigger. Which trigger you choose will depend on the goals of your workflow. There's no right or wrong order to build your workflow as long as it contains all the correct parts at the time of publication. You could start with adding actions to your canvas first, then set up your trigger. If your trigger is form, you'll need to create and set up that form first before pulling it into your workflow. {% endhint %} 1. If you have not yet added any triggers, click **Add a Trigger > + Add Trigger** to add a new trigger. 2. If you have already added a trigger and want to add an additional trigger, click the yellow **Triggers** bar on the Workflow Builder Canvas **> + Add Trigger**. Note that if you have one trigger or many triggers, all will show up in this right side menu in a list, which is always accessible by clicking the yellow bar. The number of total triggers will appear in a counter box in the far right of the dragged yellow bar. 3. Name your trigger something simple but descriptive, and unique. Depending on your trigger, new **Trigger Parameters** will appear as a new section in the setup menu with additional selections to be made to set parameters for the trigger. For example, if your trigger is a [form](https://docs.rewst.help/documentation/forms), you would be asked to select the name of an existing form to use as the trigger.

Note the Flow Control tab on the left, and the trigger settings on the right.

3. Fill out the **Trigger Settings** menu as follows: 1. Enter a descriptive name into the **Trigger Name** field. 2. Toggle the trigger to **Enabled** to use it in the workflow. 3. Use the **Trigger Mode** drop-down selector to choose the mode for your trigger: 1. **Integration**: The workflow is triggered by an integration with Rewst. 1. **Inbound**: The workflow is triggered by another workflow. 2. **Outbound**: The workflow triggers another workflow. 4. Use the **Trigger Type** drop-down selector to chose the type from the list of all available triggers in your Rewst instance. Depending on your trigger, new **Trigger Parameters** will appear as a new section in the setup menu with additional selections to be made to set parameters for the trigger. For example, if your trigger is a [form](https://docs.rewst.help/documentation/forms), you would be asked to select the name of an existing form to use as the trigger. 4. If needed, add an [integration override](/documentation/automations/intro-to-triggers#create-a-trigger).\ \ ![](/files/XjAyQCHai3w9ruOTqCEg) 5. Set your trigger criteria, if required for your workflow.\ \ ![](/files/tK5BXit7dh095uBHK1N7) 6. Think about which organizations you want the trigger to run for. 1. **Selected Organization (Org Name)** will be toggled on by default. Toggle to off if desired. 2. If you want the automation to work for your main org as well as all child organizations, toggle **All current and future managed organizations** to on. 3. If you want the automation to apply only for certain organizations, select them manually in the **Organizations** selector field.\ \ ![](/files/SoDb4fFnCRGT7WZPcTLU) 7. Click **Save Trigger** at the bottom of the menu to save the trigger. {% hint style="info" %} A workflow can be called by multiple forms through the use of triggers. All that is required is to open the workflow and create a new trigger with **Core - Form Submission** selected for the Trigger Type. {% endhint %} ### Drag the action 1. Search for your desired action in the library. You can do this via the **Search** field or by scrolling down the library to your known integration and clicking its category to expand and view all its available actions. 2. Click on the action, drag it, and drop it onto the Workflow Builder Canvas. 3. Repeat this process to add all needed actions to your workflow. ### Configure actions 1. Click on the placed action, which will open its settings in the right side menu. 2. Fill out all fields and tabs for your desired task setup. 3. Remember to add [transitions](https://docs.rewst.help/documentation/workflows/configuring-your-workflow-tasks/navigating-between-tasks-with-transitions) between your tasks. 4. Click **Run** **> Run Test** to see if your workflow executes as desired. 5. Click **Deploy** to save your changes and push them to the desired effect. ### Add time saved to a workflow One of the key metrics you can use to understand the value added by your automations is time saved. You can configure this in Rewst by identifying how long it takes to manually work through your process before automating it and adding it into your workflow. {% hint style="info" %} **Considerations for time saved** * When determining how much time to set for any given process, it's a good practice to consider not only how much time it may take you or your most experienced tech to go through that process manually, but also how much time it takes to fix any human errors that may happen during this process. * Action-level time-savings are not included in calculations. Workflow-level time-savings drives reporting on time saved in Rewst. * Time saved in seconds can only be manually reported on by using our [GraphQL](/documentation/automations/actions-in-rewst/generic-graphql-request-action) action. To do so, you would pulling the information via the GraphQL action and compute time saved based on values entered and execution history. {% endhint %} 1. Click on the workflow that you want to configure to open it in the Workflow Builder. 2. Click

to edit the workflow settings. 3. Enter the number of seconds it takes a human to complete the manual version of the process in the **Time Saved** field.

### Add, edit, or delete workflow comments {% hint style="info" %} Rewst now also offers our [RoboRewsty](/documentation/roborewsty#document-with-roborewsty) note taking feature, to automate your documentation. Choose to document manually, or with RoboRewsty. {% endhint %} Comments are a great way to jot down your thinking behind workflow aspects, and an essential step to building workflows for any team that has multiple employees editing workflows. They save in the workflow itself, and can be viewed via the

button by anyone who has permissions to edit that workflow. These boxes provide a title and a markdown editor. {% hint style="warning" %} Adding comments is disabled for synced clone workflows. {% endhint %} 1. Right-click the canvas and select **Add Comments**. Alternatively, press and hold the **control** key to expose the menu.\ \ ![](/files/VJa9HJcOidkkkUoFlHV2) 2. Click and drag it to the desired location on the canvas. 3. Click

to edit a comment's content in the right side menu. Click ⋮ to expose options to **Edit Markdown**, **Edit Attributes**, or **Delete**.

4. To delete comments right from the comment on the Canvas, right-click the comment and click **Delete***.*

5. Comments may also be pinned to the canvas so that you can navigate without accidentally moving notes around. Click **Pin** to enable or disable pinning. ## Additional Workflow Builder features ### Select multiple elements on the Canvas Select multiple workflow actions and comments simultaneously by drawing a selection box around them. 1. Hold shift and drag your mouse, or hold the middle-mouse button and drag your mouse. 2. Once you’ve selected multiple actions or comments, move them by dragging the selection box to the desired location. Commonly used actions can be favorited to easily find and add actions to workflows. When favorited, actions can be found in the **favorites** section and added on the Workflow Builder Canvas by right-clicking. ### Clone and synchronize a workflow Custom-designed workflows can be cloned to create an exact copy without changing your original. 1. Click

. 2. Click **Clone**. 3. The dialog that appears is the failsafe to confirm that you want to clone the workflow. In it, you can do the following: 1. Give your clone a different name from the original 2. Choose the organization where the workflow will be cloned to with the drop-down **Organization** selector 3. Choose to **Synchronize Changes** with the original workflow - any changes you make to the original workflow will be reflected in the clone if this is toggled on 4. Click **Clone**.

{% hint style="info" %} Creating a clone of your workflow is a great way to make a siloed test environment for your custom workflow. Make upgrades, fixes, or updates to your original workflow with synchronized changes toggled off. {% endhint %} ## Retrieve the name of a workflow Run the command `{{ WORKFLOW.name }}` . Similarly, if you're searching for the name as it relates to completion handlers, run the command\ `{{ COMPLETED_WORKFLOW.WORKFLOW.name }}` . {% hint style="info" %} Information for the **Advanced** tab of tasks and actions in a workflow can be found in our documentation for the [advanced workflow operations menu](/documentation/automations/workflows/advanced-workflow-operations-menu). {% endhint %} ### Workflow wrappers *Workflow wrapper* is an informal term to describe a parent workflow that "wraps around" a subworkflow, where a primary workflow is used in a separate workflow as a [subworkflow](https://docs.rewst.help/documentation/automations/workflows#subworkflows). Whereas a completion handler only runs when a workflow completes, a workflow wrapper can run before or after completion. You apply this strategy when you want certain tasks to run before or after the tasks within a subworkflow, and want to visualize the process on one workflow canvas. For example, you might create a workflow wrapper to handle custom input from a Rewst form, prior to a Crate running. The visual below shows this strategy, running a few tasks before the Microsoft User Onboarding subworkflow. ![](/files/yM2nWkQs6IuRybgZKiK3)
# Task transitions ## **What are task transitions?** *Task transitions* are the bridges that connect different action, ensuring that workflows move forward as designed. Each action has two circular nodules on its side and bottom. Click on either and drag to the next action to set up the transition. Depending on the criteria set, one action might branch out to multiple subsequent actions.

An action with no set transition - note the two circular **Add Transition** bubbles

The diamond that appears between the two actions once the transition has been created is called the *transition indicator*. Click on it to open the transition settings in the right side menu.

The transition indicator for a dragged action that has had its transition created

### **Task transition order** The Workflow Builder will evaluate transitions on the Canvas for follow-first actions. Order is shown by the number on the transition, but can be reordered to preference. 1. Right on the related action. This will open the right side menu. 2. Click the **Advanced** tab. 3. If **Follow First** is selected, the option to edit the order of transitions will appear, and order of the transitions can be dragged to preference. If **Follow All** is selected, order does not matter.
{% columns %} {% column %}

{% endcolumn %} {% column %} ![](/files/kDZMi9VDQ6UF0tKzuNrw) {% endcolumn %} {% endcolumns %} ## **Transition settings options**

* **Edit Transition**: Buttons beside the **Edit Transition** title give you options to either clone the current transition or remove it if it's no longer needed. * **Custom Transition Label**: This is an editable field allowing you to give a meaningful name to the transition, aiding clarity as your workflow grows. * **Condition**: This criteria governs the action's progression based on the options defined below. Depending on the outcome of this action, this rule determines which path to follow next. Left to right, these are: * **On Success**: Progress if the action succeeds. * **On Failure**: Progress if the action fails. * **Always**: Progress regardless of the outcome of the action. * **Custom Condition**: This is set custom, with Jinja. * [**Data Aliases**](/documentation/automations/workflows/data-aliases): Click the **+ Add Data alias** button to define an easy-to-use variable that stores the results of the action transition. {% hint style="success" %} In the advanced options in the workflow body, you can opt to either follow the first left to right transition condition that returns true, or to follow all transitions from the action. {% endhint %} Right click on any transition indicator to open a submenu to **Duplicate Transition,** **Delete Transition**, or **Edit Transition Order**. Duplicate will recreate the exact transition and place it next to the original on the Workflow Builder Canvas. Edit Transition Order controls the sequence in which transitions are evaluated and executed. Transition order at any given time is indicated by numbers on the transition indicators. Learn more about this setting in our [Advanced Workflow Settings](/documentation/automations/actions-in-rewst) documentation.

## Transition modes Settings for transition modes exist in the **Advanced** tab of the workflow's settings. For information on how these work, see our documentation for [advanced workflow operations](/documentation/automations/workflows/advanced-workflow-operations-menu#transition-modes). # Data aliases {% hint style="info" %} To understand this topic, you'll need to first complete Lesson 3 of the Cluck University course Automation Basics. This will introduce you to JSON and teach you how to both understand and use JSON in Rewst. If you haven't done your coursework yet, start there, then come back to this document. {% endhint %} ## **What are Data aliases?** A *data alias* is a shortcut that extracts specific pieces of information from a JSON response and stores them in an easy-to-use *variable*. Instead of navigating the entire JSON structure every time, a data alias pulls out exactly what you need—like a user’s name or email—and makes it accessible throughout your workflow. Think of data aliases as custom labels you assign to specific data. Recall that *the context* is where all data generated, captured, or used in a workflow is stored. Think of it as a shared memory for a specific workflow. Data aliases are stored in the context, making them available for reuse at any step in your workflow without re-fetching the data. For example, imagine that you've set up your Microsoft Graph integration. You send a request via API call to get info about a user. The response comes back to you in JSON format, which can be lengthy and time consuming to search through. A data alias would let you get all of the information, or pinpoint specific information like the user's name or email address, and store it in a simpler variable in the context for use. Together, variables, data aliases, and the context make your workflows in Rewst more efficient, organized, and adaptable. These tools help you reuse workflows, reduce manual work, and customize data handling to fit any automation need. ### Data alias requirements When adding a new data alias, you'll need the following: * **Key**: The name you assign to specific data. * **Value**: The actual data it corresponds to. The code editor button allows for the use of Jinja customization for intricate data or expressions. ### Data alias context example If you set an alias such as `my_task_result -> {{ RESULT }}`, tasks can later refer to this data using `{{ CTX.my_task_result }}`. You can also use a data alias to extract specific information and manipulate data. Expanding on our example from above, take the input from the Microsoft Graph get user action and extract the user's name and user principal name for ease of use.
1. Drag the Microsoft Graph **Get User** action onto the Workflow Builder Canvas. 2. Click on the action, then its **Parameters** tab. 3. Add your user into the **User ID** field.

4. Click the **General** tab. 5. Set your context variable name under **Publish Result As.** The workflow action results will be stored as this value.

6. Open the Jinja editor and set up your data alias. 7. Use the following Jinja to create a new dictionary object and set the `displayName` and `userPrincipalName` keys.
``` {{ { "displayName": CTX.user_details.data.value.displayName, "userPrincipalName": CTX.user_details.data.value.userPrincipalName } }} ``` 8. Run the workflow. Then, click **View Results** 9. Click **Load Context.** 10. Expand the context to see our data alias `filtered_user_details` now only showing the `displayName` and `userPrincipalName` .

## Add a data alias to a workflow Data aliases are added via transitions. See more about how to use [transitions in workflows here](/documentation/automations/workflows/task-transitions). 1. Click on the transition in your workflow in the Workflow Builder Canvas.\ \ ![](/files/M5rGHEadNrGZWkdSJwzw) 2. Click **+ Add Data Alias** in the right side menu. 3. Paste the key into the **key** field. Click ![](/files/yRhzrk2xPyH045czZ3PH) to open the Jinja editor and set up your data alias. 4. Click ![](/files/FJxFktN4V7ooGXjZKj4Q)to remove a data alias. 5. Click ![](/files/Q8G2ewL7jnYBcXIcoQFl) and drag it as desired to move multiple data aliases up and down in the data alias list.

## Access data aliases in a workflow 1. Navigate to **Automations > Workflows**. 2. Search for your desired workflow. 3. Click **>** to the far right of that workflow to open its Workflow Builder Canvas.\

4. Click

in the top navigation bar to open the **Settings** in the right side menu. 5. Click the **Data Aliases** tab. This will show a complete list of all existing data aliases for that workflow. # Best practices for designing workflows ## Design principles When designing workflows, keep these three guiding principles in mind. 1. Simplicity: Create workflows that are user-friendly and easy to understand. 2. Modularity: Break down workflows into smaller, reusable components. 3. Maintainability: Build workflows that are straightforward to update and maintain. ## Automation build standards A good workflow should meet all of these requirements. * Consistency: Standardized practices lead to a consistent experience across different workflows. * Quality assurance: Adhering to standards makes quality checks more efficient. * Reusability: Modular design enables the reuse of components, speeding up development. * Scalability: Design your workflows to handle increased complexity as your needs grow. * Efficiency: Avoid redundancy by following a standardized approach. * Knowledge Transfer: Standards foster collaboration and knowledge sharing within your team. * Flexibility: Rewst's standards allow easy integration of new features without major rework. ## Design, test, and document workflows {% hint style="info" %} For more on templating in Rewst, see our documentation [here](/documentation/automations/templates-and-scripts). {% endhint %} * Use pre-defined templates to speed up development and ensure adherence to best practices. * Develop and test your workflows in a sandbox or development environment. Make necessary changes, test, and sync to your live environment. Always test a workflow before publishing. * Document workflows manually or with RoboRewsty to keep track of the intent of each action and subworkflow. * When publishing a workflow, document the changes made in that update to help with version control of your workflow. ## Workflow naming and categorization {% hint style="info" %} You can also use [tags](/documentation/settings/tags-in-rewst) within Rewst to organize your automations effectively. {% endhint %} Properly naming and categorizing your workflows is essential for clarity and navigation, especially as the number of workflows you use in Rewst grows over time. Adhering to a consistent naming convention helps in understanding the purpose and function of each automation. {% hint style="success" %} **Proper example**: `List Disabled User Accounts` **Improper example:** `Steve's Workflow` {% endhint %} * Put the name of the service in square brackets at the beginning - for example, `[servicename]` * Put the name of the project in the square brackets if you're building a larger workflow - for example `[projectname]` * Add `— OG` if the workflow type is an option generator * Use a name that describes exactly what the workflow does - for example, `List Active Contracts in AT` ## Manage variables and actions ### Organization variables * Employ descriptive and straightforward wording using `snake_case` for clarity. * Prefix integration-specific variables appropriately, like `psa_` for PSA-related variables. ### Work with data aliases * Separate complex [data alias](/documentation/automations/workflows/data-aliases) creation or modification into `Set Variable` tasks rather than creating them on the actual task doing the API call. This helps with easier troubleshooting should you encounter errors, such as determining if the API is experiencing issues versus if there is a Jinja error in your variable assignment. * Separating the data aliases makes debugging easier, allowing you to test your code with real data. ### Naming actions * Use snake case - for example, `this_is_snake_case` . * Use descriptive names that help explain what the action does. * For example, you may have an action to list templates, with the intent to extract a specific template. The action shouldn't be `rewst_list_templates` or even `list_templates`, it should be closer to `get_ai_prompt_template`*.* * Descriptive naming makes readability much easier when checking the results of your workflow. * Use BEGIN and END for noops at the beginning and end of the workflow. ### Naming variables: data aliases * Use snake case - for example, `snake_case` . * Names should be descriptive about what the data alias is storing - for example, `excluded_user_age` is more descriptive than `age`*.* * JSON and dictionaries should use camel case for keys - for example, `{"userName": "thomas"}` rather than `{"user_name": "thomas"}`. * Lists should use a plural name. All others should use singular - for example, `active_users` instead of `active_user` for a list of active users * Don't use the variable type in the name as in `active_contracts_list`*.* Instead, it should be `active_contracts`*.* * Don't abbreviate in names. The benefits of abbreviating variable names are negligible compared to the readability of using full descriptive names. ### Work with task transitions {% hint style="info" %} For more on transitions, see our documentation [here](/documentation/automations/workflows/task-transitions). {% endhint %} * Use conditions like `{{ SUCCEEDED and CTX.list_of_things|d }}` to control the flow based on task success or failure. * Transitions are evaluated from left to right, so order them carefully. * Follow All/Follow First: * **Follow All**: The task will follow every path that meets the criteria. * **Follow First**: The task will follow the first criteria that it matches and then stop. Use this when you expect only one condition to be met or when, as soon as a condition is met, you do not want the process to use other workflow branches. ## Limit API field results Limiting the API field response to only the data you need helps in building clean workflows that are easy to understand, without overloading your tools. * If unsure about the fields you need, consider running the query without any filtering initially. This approach lets you explore the available fields and understand what information is at your disposal. * Once you've identified the necessary fields, be sure to limit the response to include only those. For instance, if you're listing users in Microsoft Graph and only require the UPN (User Principal Name) and User's ID, you should select the `userPrincipalName` and `id` fields. # Advanced workflow operations menu {% hint style="info" %} This document assumes that you've mastered earlier workflow building concepts from Cluck University and our introduction to the workflow builder [here](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow). If you haven't yet completed that reading, come back to this page later. {% endhint %} These operations can be found inside each task's **Advanced** tab. ## Integration overrides For more on integration overrides and how to use them, see our documentation [here](https://docs.rewst.help/documentation/automations/intro-to-triggers#integration-overrides). Add an integration override to the task by clicking ![](/files/NgWXghDJGhgu569Dq4EK). This will expose a new submenu for **Configuration Selection Mode**.

## Transition modes: Saved configuration *Transition modes* in Rewst are responsible for determining how transitions attached to a workflow action are followed. There are two primary modes:

Note the two different colored transitions arrows

* **Follow All**: This is the default mode. If your task has multiple conditions attached, the Follow All mode attempts to follow all of the specified transitions. In the workflow visualization, this mode is represented by the standard color blue. * **Follow First**: In this mode, conditions are evaluated from left to right and as soon as the first condition is satisfied, the remaining conditions are disregarded. To differentiate these transitions in the workflow visualization, they are color-coded orange. * When Follow First is selected, a second option will appear to **Edit Transition Order**. Learn more about transition order in our [transitions documentation](/documentation/automations/workflows/task-transitions).\ \ ![](/files/ruiOtrJCKi92jKUDxGNn)![](/files/fn70Apvja1LiCsvKS6qT) ## Task transition criteria sensitivity

This setting is used to indicate how many parent tasks need to be satisfied. For example, `0` would indicate all tasks. If the workflow has two tasks with arrows pointing to a third task, that sensitivity is the number of tasks above it which need to be complete before it runs. This is particularly important when building workflows that contain [subworkflows](/documentation/automations/workflows#subworkflows). ## Run as org

The *Run as Org* option allows the workflow action to run in the context of another organization. {% hint style="warning" %} You can only run as org going from a parent organization to child organization. The workflow will fail when attempting to run as the parent organization, when the workflow is running in the child organization context. {% endhint %} The purpose of `Run as Org` is to temporarily pass the execution of a workflow task into the context of another organization. This is something you may see done when you have a task— be it an individual action or a subworkflow— that needs to be executed as if it were for a different org than the one the workflow is running for. For example, if you wanted to have something run once for the parent organization that needed to also reference items for a child organization, a Run as Org option would solve this issue. Start by listing all organizations. Then, using `Run as Org` on a subworkflow, do things within that subworkflow for one or many of your managed organizations. Or, when a form has an organization picker on it, where the organization ID is passed into the workflow from the form, `Run as Org` is used to have the actions in the workflow run as if they were for the selected organization, instead of the organization for which the form was loaded.

## With items

*With Items* is the equivalent to a `foreach` statement in other languages. With this, you can pass a number of objects into a certain action and collect the results from each and then do something. {% hint style="warning" %} When using with items in Rewst, it's important that you make the name of the task unique, and different from any other task name in that workflow. {% endhint %} In the example below, you're going to list every user that is enabled in the child organization, and create or update a contact for each one. List all enabled users, then output this to a data alias called ```django {{ CTX.all_users }} ``` The data alias has the following Jinja: {% code overflow="wrap" %} ```django {{ [ user for user in TASKS.m365_list_users.result.result.data.value if user.enabled ] }} ``` {% endcode %} You then have a subworkflow that creates or updates a contact. As per the best practice, use a subworkflow with your **With Items**. In the **Advanced** tab, set the **With Items** field with this data alias. The action now has the additional icon indicating that it has a `With Items` set on it. During testing, or for example if creating tickets from an alert, you may sometimes want to limit the amount of alerts you get during this phase. Test the workflow on a subset of your total users initially to make sure it works as expected. To achieve this, you could create an input variable on the workflow called `max_tickets_to_create_per_action`and set it to the maximum number of times you want that **With Items** to run. If set to 1, it will only run on a single object within CTX.all\_users. The below code is what you would use in the **With Items** field in the **Advanced** tab. ```django {{ CTX.all_users[:CTX.max_tickets_to_create_per_action | int] }} ``` ### Use inputs after creating With Items Iterating through CTX.all\_users on the action means you can't use {{ CTX.all\_users.X }} as the property for the input. Instead, you must use `{{ item() }}` Say you want to get the first name of each user as an input. On your **`With Items`** action you would execute: ```django {{ item().firstName }} ``` ## Items concurrency

If you're running a workflow task using With Items, this allows you to set how many of these processes run at the same time. It's recommended that no more than 10 concurrent actions be performed at a time to guarantee performance. ## Task timeout

This allows you to adjust the number of seconds to wait for a task to complete. The default value is 10 minutes. ## Shallow clone a workflow *Shallow cloning* is a feature of the Rewst platform that allows you to create a copy of an existing workflow or form. This is useful if you have a workflow that is very similar to another workflow, but which requires a few small changes. Standard cloning copies the entire resource *pack—* workflow, forms, templates, triggers, etc— and when cloning into your own org, you end up with multiple duplicates of the same resource. Shallow cloning copies that single selected resource, but re-uses all of the dependencies that it has. If you have a subworkflow that's part of a main workflow, and you shallow clone that subworkflow, you will end up with a copy of the subworkflow. This lets you make changes to the subworkflow without affecting the original workflow. There is no difference between the steps to clone or shallow clone a resource. Rewst will automatically detect if you are cloning something into your own org. If so, the platform will shallow clone it instead. Note that this removes the **Synchronize** button on the dialog, and instead shows a text to explain. # Data input and output: Input variables and context variables {% hint style="success" %} To understand this topic, you'll first need to learn the difference between an input and an output. An *input* is information that will be put into Rewst automations. This could be the contents of a form, or information sent via integration, for example. Knowing what your input is will help you determine what to use when crafting your automations. An *output* is the expected result of the automation. {% endhint %} ### Workflow input: Input variables Workflow inputs are commonly known as *input variables*. The role of input variables is to provide data that can be used by tasks within the workflow, or into a subworkflow. Input variables can be broken down into two parts: 1. A key 2. The specific data or values that vary This is an example of a variable where \[first\_name] is the key and Ashley is the value: \[first\_name] : "Ashley" {% hint style="warning" %} Input variables can only be modified or added on the source workflow, not clones of workflows unpacked from Crates. {% endhint %} You can add new variables, or modify existing ones, by navigating to your **Workflow >**

**> Input**. Click **+ Add Input** to see a number of new fillable fields and checkboxes.

1. **Name:** This can be a unique entry relevant to what the aim of the input is going to be. This should not contain spaces. 2. **Label:** This text field is used to set a friendly name. It's the field name visible at the time of input. 3. **Type:** Short for data type, this field defines what format the data will be in. The most common types are Text (general string), Integer (whole number), and String (a combo of characters). 4. **Default:** You can specify a value that will be used if no other input is specified manually. 5. **Description:** You can give a better description of what the field is used for. 6. **Required** checkbox: When checked, this marks the input parameter as mandatory. The workflow will expect a value to be provided for this input when it's executed. This is especially relevant when the workflow is called as a sub-workflow: the parent workflow must supply a value for any required input, or the execution will fail. It essentially enforces that the parameter cannot be left empty or omitted. 7. **Multiline** checkbox: When checked, this changes the input field from a single-line text box to a larger, multi-line text area. This setting affects how the input appears when configuring the workflow— for example, when setting up a subworkflow action that calls this workflow. It's useful for inputs that expect longer content like Jinja expressions, JSON blobs, descriptions, or any text that benefits from more editing space. It doesn't change the data type, and only gives you a bigger box to type in. Input variables get their values in a Rewst workflow through the workflow's initial trigger event. Any data type that is valid in JSON can be used as an input variable. ### Workflow action inputs When variables are created within the workflow, they become context variables, and can be used directly in action inputs. {% hint style="info" %} Recall from your Cluck University training that *the context* is where all data generated, captured, or used in a workflow is stored. {% endhint %} In the example below, creating a user in Microsoft 365 using three variables: 1. First Name 2. Last Name 3. Domain For now, these are all specified directly on the workflow rather than being submitted via a form.

Create an action by dragging it from the integration list on the left menu.

Click on this action to reveal a number of input parameter fields in the right side menu. Click ![](/files/yRhzrk2xPyH045czZ3PH) to the right of the field to open up a Monaco editor. Click ![](/files/aPgXyVSjbdkTjcW9DSub) to the right of the field to open up a Monaco editor, the same type that VSCode uses. Learn more about the [code that Rewst uses, called Jinja, here](broken://pages/Xie1v7V1Vqm4kxsoGpiM). Use the variables by using CTX, which stands for context, and then the name of the variable, as outlined in the code block below. This will autocomplete to make it easier to reference.

```django {{ CTX.first_name }} {{ CTX.last_name }} {{ CTX.domain}} ``` Despite the data being static at this point, the process is the same regardless of where the data is coming from. ### Workflow output Similarly to the above, you can configure an output of a workflow. These are generally used in two situations: 1. In an [Options Generator](/documentation/automations/workflows/option-generator-workflows#create-an-option-generator-workflow) workflow, the output is what is passed through to the form. For example, if you have a workflow that lists users in a variable called `{{ CTX.users }}` - you would configure an output variable of options mapped to this variable, as per the below image. This then, in the form, would list the users in a dropdown field. This is how dynamic data works in form. Read more about that in [types of workflows](/documentation/automations/workflows/option-generator-workflows).

2. The other time this would be used is if you have a [subworkflow](/documentation/automations/subworkflows). A subworkflow is no different from a standard workflow, except for the fact it lives within another workflow. If you were passing data back from the subworkflow into the main workflow, this would be done via an output variable. ### Workflow action outputs One of Rewst's ultimate purposes is to integrate various platforms into a workflow and use data from each to do something else. In this example, you'll get a list of users where the userPrincipalName matches X, then create a ticket using information from that request. First, take the action of **List Users** from the Microsoft Graph integration in the action menu of the workflow builder. There are no inputs required here, and it will list every user on the tenant that it is integrated with, or that the [trigger](/documentation/automations/intro-to-triggers) is set for. If you ran this action as-is, you would get the list of users, but wouldn't be able to use that data anywhere. This is where [task transitions](/documentation/automations/workflows/task-transitions) come into play. Click the **On Success** transition on the action. This gives you the option to create a [data alias](/documentation/automations/workflows/data-aliases). A data alias allows you to create a variable, similar to an input variable, but with data direct from an action API request. In our example below, we are creating a variable with the key called `user_details` and populating it with the data of the user using Jinja. {% code overflow="wrap" %} ```django {{ [ user for user in TASKS.m365_list_users.result.result.data.value if user.userPrincipalName == "RewstDocs@rewst.io" ] }} ``` {% endcode %} Take your **create\_ticket** action from your respective PSA from the actions menu of the Workflow Builder. Using your newly created data alias, add the inputs onto that `create_ticket` input. ```django User Exists {{ CTX.user_details.displayName }} ``` This would create a ticket with the title `User Exists RewstDocs@rewst.io`. # Troubleshoot workflow executions and results {% hint style="success" %} If the issue involves another platform like your [RMM](/documentation/integrations/top-5-integration-types-get-started-with-integrations-in-rewst#rmm-integrations),[ PSA](/documentation/integrations/top-5-integration-types-get-started-with-integrations-in-rewst#psa-integrations), or email system, check that platform's documentation or status page for recent changes or requirements. {% endhint %} ## Workflow executions for troubleshooting {% hint style="info" %} See our documentation for how to view workflow results [here](https://docs.rewst.help/documentation/automations/workflows#view-specific-workflow-results). To learn the fundamentals of troubleshooting in Rewst, sign up for our course in [Cluck University](https://learn.rewst.io/troubleshooting-in-rewst). {% endhint %} * Use the organization-level view to see all workflow executions for one organization. * Use the workflow-level view to focus on one workflow across all organizations. * Both paths lead to the Workflow Execution Summary, where troubleshooting begins. {% embed url="" %} ## How to read the workflow execution summary The inputs and context sections of the summary tell the story of what data your workflow received and what the workflow did with that data. Learning to scan these two areas quickly is one of the most important skills in Rewst troubleshooting. * The **Inputs** section shows the raw data that entered into the workflow, usually via form, webhook, or parent workflow.\

* The **Context** section shows variables created or passed between actions. [Context variables](/documentation/automations/workflows/data-input-and-output-input-variables-and-context-variables) can change over the execution of the workflow, and each new iteration of variables will be in this list in chronological order.\

* Common issues which lead to failed workflow tasks include typos, casing mismatches, missing values, or broken Jinja. ## Task results Task results give you a detailed view of what happened in a workflow, and why something may have failed. By learning to read the request, the response, and the action logic, you can identify the issue and know where to work next. Task results display two key pieces of information: * The request Rewst sent—such as a JSON payload or API call to an integration * The response that came back—typically with a status code and message body Reading both helps you determine if the failure came from your setup, your data, or the external system. ### **How is data stored in context?** * `{{ RESULT.result }}` stores a specific part of the action’s output, often the core data value. * **Publish result as** saves the full response object to a named key in a context variable. * These outputs can be reused in later actions through Jinja. For example, by using `Publish result` on one action to create the context variable `user_list`, you can reference that action's output on a future task with the Jinja syntax `{{ CTX.user_list }}`. ### Most common action failures | Failure type | What the failure means | How to resolve the issue | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Jinja error` | Rewst couldn’t evaluate the action due to bad syntax, missing data, or invalid filters | Use the live context editor to test the Jinja expression and verify available values | | `Integration not authorized` | 401 or 403 errors mean the integration is either not connected or lacks permissions | Recheck integration settings and scopes. If you change permissions in the external tool, reauthorize the integration in Rewst to apply the updates. | | `Request rejected by API` | 404, 405, or other 4XX/5XX errors mean the request structure is incorrect—or you may not have access to view the item being requested | Compare the request to the integration’s documentation—check the endpoint path, HTTP method, and resource IDs | | `200 OK, but no result` | The request was accepted, but didn’t return useful data. This may mean no results matched the query, or the operation isn’t designed to return a response | Review the request parameters and expected output. Check if the API is designed to return a result for this operation, or if it executed successfully with no output | | `Transition criteria not met` | The action was skipped because a transition condition wasn’t met—often due to logic that didn’t evaluate as expected or pathing that skipped this action |

Review the transition logic and action flow. Check for incorrect conditions or action paths that prevent the transition from executing

If the issue isn’t obvious, look at the last successful action—errors upstream often cause transitions to fail silently.

| ## Use contextual tools to troubleshoot your workflow Rewst gives you three powerful tools: the [live editor](/documentation/automations/the-live-editor), which lets you test Jinja expressions using real context data without re-running the full workflow, the **re-run** button, which lets you re-run the full workflow using the same inputs, and the test button, which offers a quick way to demo the workflow. ### Use the [live editor](/documentation/automations/the-live-editor) when: * You’re troubleshooting a Jinja error * You’re checking if a context variable exists or is formatted correctly * You want to preview loops, filters, or logic before adding it to a workflow * You need to manipulate or explore context safely without running the workflow ### Use the [test button](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow) in the workflow editor when: * You’re building or editing a workflow * You want to test changes as you go by running a true execution, not just testing data * You need a fast feedback loop while adjusting actions ### Use the re-run button when: * You’ve fixed something and want to confirm the outcome * You’re testing workflows with consistent inputs like forms or webhooks * You want to validate that a change resolved the issue end-to-end {% hint style="warning" %} If you do plan to re-run the workflow but want to avoid unintended changes, take steps to isolate it for safe testing. That might include: * Temporarily commenting out actions that make changes * Using a test org or test input values * Adding conditional logic to skip sensitive steps during testing {% endhint %} ## Know when to escalate your failure to Rewst support {% hint style="info" %} This four step model is introduced and outlined in our Cluck University training. For details on these steps with visual examples, see our course [**Troubleshooting in Rewst**](https://learn.rewst.io/troubleshooting-in-rewst). {% endhint %} Remember to ask yourself the following questions while troubleshooting your results. {% stepper %} {% step %} ### Where did it run? Check the org-level vs. workflow-level execution. Use ![](/files/E0VyPaGNj1MrpuFwS7ug) **> Execution History > Executions** from the Workflow Builder, or **Automations > Results** in the left side menu of your Rewst platform. {% endstep %} {% step %} ### What data came in? Review the **Inputs** section to confirm trigger values or parent workflow data were passed correctly. {% endstep %} {% step %} ### What was created in context? Open the **Context** tab and look for expected variables. Check for typos, nulls, or casing mismatches. {% endstep %} {% step %} ### What failed, and why? Click into the failed action. Read the error message and check: * Jinja issues * Transition criteria * Integration authorization * API request and response details * External system behavior - check platform documentation if the action involves an outside service {% endstep %} {% endstepper %} If you've dealt with each of these points and still can't resolve the issue, [escalate to Rewst's support team](/support-and-community/roc-support). Include the following in your ticket: * The organization and workflow name * A link to the workflow execution summary * Action result screenshots * What you've tried so far # Option generator workflows When automating certain processes, it's important to use dynamic options that adjust based on the input. Using the same list of options every time can lead to errors by applying choices that don't fit the situation. When an automation gets information from a form, it's important that the data on the form be dynamic, and adjust based on previous inputs or selections on that same form. An *option generator* workflow will always be connected to a form, and allows you to provide tailored, dynamic options for specific fields in that form. For example, in an automation that updates a user's group memberships, the list of groups is tailored to the input. You wouldn't want to add an individual to a group that they're already a member of, nor would you want to remove them from a group that they're not a member of. To add a user to a group, you would generate a list of groups that are not already part of the user's group memberships. To remove a user from a group, you would generate the user's current list of group memberships. {% hint style="info" %} The order of operations for creating the pieces needed to pull off an option generator is flexible. You can create the option generator workflow first, or the form that connects to the option generator workflow. In the below example, the workflow is made first. Ultimately, an option generator workflow needs three things: 1. A workflow designated as an option generator in the workflow configuration. 2. Workflow output configuration that sets the value of options to the relevant workflow context variable. 3. A Rewst form that contains a form field connected to the option generator workflow and its trigger. [RoboRewsty](/documentation/roborewsty) can also help you generate option generator workflows, but the order of operations for how you make your ask and generate the pieces is important. If you ask for his help to make the option generator workflow from scratch, you'll be required to manually set up the form he uses before asking for his help. If you build the option generator yourself, then ask RoboRewsty to build a form for use with the option generator, he can generate the form for you. {% endhint %} ### Create an option generator workflow Before you begin, decide which options need to be displayed based on the user’s selection. For this example, the list of groups will change depending on whether the action is to add or remove a user. 1. [Create a new workflow](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow). 2. Click

in the top menu bar of your workflow's Workflow Builder Canvas. 3. Click the **Workflow Type** drop-down selector. 4. Select **Option Generator**.

5. Click the **Output** tab. 6. Click **+ Add Variable** to create an output variable. Name the variable `options`. Every option generator workflow must have an [output variable](/documentation/automations/workflows/data-input-and-output-input-variables-and-context-variables#workflow-output) called `options`, which will contain the context variable that holds the data that you want to display.

7. Set up a [trigger](/documentation/automations/intro-to-triggers) for the workflow. We recommend using an always pass trigger, to allow the corresponding form to 'always' be available to use. When you attach the trigger, you have the ability to add an integration override, which allows you to choose which organizations will run that specific option generator. ### Create a form to be used with the workflow Remember, workflow generated options allow forms to be highly dynamic. When a form field is connected to an option workflow, it will return a list of options based on the input. See the documentation for how to use our form builder to achieve this step [here](/documentation/automations/forms/intro-to-forms#option-two-workflow-generated-options). ### How the form and workflow come together to generate options 1. When the workflow runs, it should result in a context variable `{{ CTX.options }}` that contains a list of items with key-value pairs that will be referenced in the form editor.

An example of an options generator workflow for one of our unpacked Crates

2. The values here will be used in the **Label Field** an **Value Field** for a form field*.* 1. The **Label** is what gets shown to the user who fills out the form as an available choice. 2. The **Value** field will be set to the value of the **Field Name** when that form is submitted. Workflows will reference this as `{{ CTX. }}` 3. Using the **Default Selected Field** will evaluate an attribute of the `options` list for truthiness. Items which evaluate `true` will be selected by default when this field populates.

# Keyboard shortcuts for the Workflow Builder ## **Workflow**

Action	Mac	Windows and Linux
Save	Cmd+S	Ctrl+S
Rename workflow	F2	F2
Edit Workflow JSON	Cmd+J	Ctrl+J
Export	Cmd+Shift+E	Ctrl+Shift+E
Clone workflow	Ctrl+Shift+D	Ctrl+Shift+D
Version History	Cmd+Shift+V	Ctrl+Shift+V
Execution Viewer	Cmd+Shift+X	Ctrl+Shift+X

## **Layout** | Action | Mac | Windows and Linux | | ---------------------- | ------ | ----------------- | | Auto-layout vertical | Ctrl+G | Ctrl+G | | Auto-layout horizontal | Ctrl+H | Ctrl+H | ## **History** | Action | Mac | Windows and Linux | | ------ | ------------------- | --------------------- | | Undo | Cmd+Z | Ctrl+Z | | Redo | Cmd+Shift+Z / Cmd+Y | Ctrl+Shift+Z / Ctrl+Y | ## **Navigation** | Action | Mac | Windows and Linux | | -------- | ------------- | ----------------- | | Zoom in | Cmd+= / Cmd++ | Ctrl+= / Ctrl++ | | Zoom out | Cmd+- | Ctrl+- | | Fit view | Cmd+1 | Ctrl+1 | ## **Selection** | Action | Mac | Windows and Linux | | ------------------------ | ------------------ | ------------------ | | Duplicate selected tasks | Cmd+D | Ctrl+D | | Delete selected tasks | Delete / Backspace | Delete / Backspace | ## **Overlays and panels** | Action | Mac | Windows and Linux | | ------------------------------ | ------------------ | ------------------ | | Close Execution Viewer overlay | Esc | Esc | | Close Notes panel | Esc | Esc | | Delete selected note | Delete / Backspace | Delete / Backspace | ## **Modifiers** | Action | Key | | ------------ | ------------ | | Multi-select | Shift (hold) | # Boolean logic in Rewst workflows ## Boolean values and their role in automation *Boolean* values represent simple yes/no conditions, like on/off or true/false. They define rules and logic in workflows by evaluating conditions. Boolean values are fundamental in automation workflows, controlling decision-making and process flow. Understanding Boolean logic helps ensure that workflows are efficient, reliable, and easy to maintain. ## Key boolean concepts * **Boolean values**: Represent `true` or `false`, similar to `1` (on) and `0` (off). * **Logical operators**: `and`, `or`, `not` determine conditions in workflows. * **Comparison operations**: Evaluate conditions (e.g., `user_role == "admin"`). * **Custom conditions in workflows**: Enable transitions based on Boolean evaluations. ## Boolean operators in Rewst workflows Boolean logic controls workflow decisions using these key operators: * **`and`** – Requires both conditions to be true. * Example: `user_logged_in and is_admin` * **`or`** – Requires at least one condition to be true. * Example: `is_manager or is_admin` * **`not`** – Inverts a Boolean value. * Example: `not user_logged_in` (returns `true` if `user_logged_in` is `false`). ## Boolean logic in action * **True and false = false** – Both conditions must be true for `and` to return `true`. * **True or false = true** – Only one condition needs to be true for `or` to return `true`. * **Not false = true** – Flips the Boolean value to its opposite. ## Best practices for boolean logic in Rewst To ensure efficiency and maintainability, follow these best practices. ### Structuring logical conditions * **Group logic with parentheses**: Ensures conditions execute in the correct order. * Example: `(is_admin and is_active) or is_super_admin` * **Use `in` for cleaner conditions**: * Before: `if role == "admin" or role == "super_admin"` * After: `if role in ["admin", "super_admin"]` ### Simplifying boolean expressions * **Use ternary operators for concise logic**: * Syntax: `variable = value_if_true if condition else value_if_false` * Example: `status = "Active" if is_active else "Inactive"` * **Leverage short-circuit evaluation**: * Skips unnecessary checks by placing the most likely condition first. * Example: `if user_logged_in and is_admin:` (Skips `is_admin` check if `user_logged_in` is `false`.) {% hint style="info" %} For more on how boolean values relate to Rewst, complete our Clean Automation course in Cluck University. {% endhint %} # Triggers ## What is a trigger? *Triggers* initiate [workflows](https://docs.rewst.help/documentation/workflows) in Rewst. Every workflow must have a trigger to define when and how it starts. Essentially, triggers put the automate in automation. Choosing the right trigger ensures that your workflows execute at the right time, with the right data, to drive efficiency and consistency in your operations. A trigger is also used on any [form](https://docs.rewst.help/documentation/forms) input that requires a workflow. If a form uses the **Dynamic** button, then you must also create a trigger on the workflow associated with that form. For more on how to see which triggers appear on a specific workflow, view our documentation [here](/documentation/automations/workflows#view-triggers-for-a-specific-workflow). ## View all triggers Navigate to **Automations > Triggers** in the left side menu of Rewst to view the total triggers page, which contains a sortable list of all triggers in your Rewst instance, organized by tabs labeled with automation type. This includes triggers from your custom-built workflows and from unpacked Crates. Click on any of the column headers to sort the list by that criteria. Use the **Tags** drop-down selector to filter the list by specific tags.

Toggle any trigger to enabled or disabled in the **Status** column. Once toggled on, the slider will turn green, and a green checkmark will appear to the right to let you know that the enablement is complete. {% hint style="warning" %} We're currently working on a feature limitation that prevents the last activity display for Always Pass and Interval triggers. Instead of listing the last activity, the trigger will show that it has never been activated. For these particular trigger types, confirm the last time the trigger was activated directly in the trigger rather than in the triggers page. {% endhint %} ## Three trigger modes in Rewst {% hint style="info" %} Rewst launched the new Workflow Builder in May of 2026. Prior to that product change, the term *completion handler* was used to refer to the interlinking of workflows. If you're a seasoned Rewst user, note that completion handlers are now achieved via inbound and outbound triggers. {% endhint %} There are three trigger modes in Rewst. All are selected when creating your trigger in the trigger settings of the right side menu. Trigger modes can't be edited after a trigger is created. Click each type below to expand and learn about different modes.

Integration mode: Workflow triggered by an integration

his is the default choice for standard events within the Rewst platform. The workflow waits for specified events to happen in your partner tools, if those partner tools are integrated with Rewst. Examples include ticket updates in your PSA, or user creation alerts. When you choose integration mode, the **Trigger Type** drop-down selector appears with a complete list populated to include all of your Rewst integrations.

Inbound mode: Workflow triggered by another workflow's completion

This enables the workflow to start when another workflow completes, pulling in the data from each run. The workflow you're currently setting up is the first, enabling workflow in this scenario. Examples include alerting for failed workflow executions, like kicking off the trigger based on a failed status. These workflows have a [context variable ](/documentation/automations/workflows/data-input-and-output-input-variables-and-context-variables)that can be used to reference previous contexts from the workflow that was completed. Select one or more status conditions that will trigger the target workflow

Contexts from the previously run workflow can be accessed with the `COMPLETED_WORKFLOW` variable. You can access most info via the context including ORG and CTX such as: 1. `{{ COMPLETED_WORKFLOW.ORG.VARIABLES.cw_manage_company_id }}` 2. `{{ COMPLETED_WORKFLOW.CTX.user.username }}` Inbound and outbound triggers will always run in the context of the parent organization. If you are taking actions on a suborganization in the workflow, then you must use the run-as-organization functionality and overrides set at the trigger level. The organization ID that was used in the previous workflow context can be referenced with the following Jinja: `{{ COMPLETED_WORKFLOW.ORG.ATTRIBUTES.id }}` ### Test inbound triggers Inbound trigger data is hard to fake for testing because it's represented as `COMPLETED_WORKFLOW.` instead of `CTX.COMPLETED_WORKFLOW.` Rather than running an entire workflow multiple times to test just this one element, create a [noop action](https://docs.rewst.help/documentation/workflows/actions-in-rewst/core-actions#no-operation-noop) that sets the test data, and use it to trigger your inbound trigger. In the noop, set all of the variables that will be used in your inbound trigger in the On Success transition as data aliases. It’s important that the names of the data aliases you create in the On Success transition of the noop match both: * the names of the variables that will be used in your inbound trigger * the names of the variables that will be used in the live parent workflow that your inbound trigger is triggered by Add static values that represent a good test case for ensuring that your inbound trigger functions the way you expect. #### **Example:** Test inbound triggers In the example below, we’ve created a workflow with a single noop. In the **On Success** transition, we’ve added several data aliases that represent user data that could be used to test a completion handler, which could be used after a user is onboarded or offboarded.

The noop action, its On Success transition, and the corresponding data aliases

Once you’ve created the noop and added the correct data, attach this workflow to your other workflow's inbound trigger as another parent workflow that will trigger the the inbound trigger. This will enable testing. If you need to run your test workflow for organizations other than your parent MSP organization, add a trigger to the workflow which will allow you to select which organization the test workflow runs for.

Outbound mode: Workflow's completing triggers another workflow

This enables another workflow to start when your workflow completes, pulling in the data from each run. The workflow you're currently setting up is the second, completing workflow in this scenario. These workflows have a [context variable ](/documentation/automations/workflows/data-input-and-output-input-variables-and-context-variables)that can be used to reference previous contexts from the workflow that was completed. Select one or more status conditions that will trigger the target workflow

{% hint style="warning" %} Inbound and outbound workflow triggering should be linear, never circular. Don't set two workflows to continually run when the other completes. This will cause the workflows to trigger each other in an infinite loop. {% endhint %} ## Create a trigger Depending on your workflow, you may have one trigger or multiple triggers— for example, a webhook trigger and a trigger that runs when a ticket gets saved in your PSA. In either case, to begin: 1. Click ![](/files/17lCeuoq6HByl9lrLING) to open the library. 2. Click the **Flow Control** tab. 3. Drag the yellow **Triggers** bar onto your Workflow Builder Canvas. 4. Click on the bar to open trigger settings in the right side menu. Note that if you have one trigger or many triggers, all will show up in this right side menu in a list, which is always accessible by clicking the yellow bar. The number of total triggers will appear in a counter box in the far right of the dragged yellow bar.

5. Click + **Add Trigger**. 6. Fill out the **Trigger Settings** menu as follows: 1. Enter a descriptive name into the **Trigger Name** field. 2. Toggle the trigger to **Enabled** to use it in the workflow. 3. Use the **Trigger Mode** drop-down selector to choose the mode for your trigger: 1. **Integration**: The workflow is triggered by an integration with Rewst. If this is selected, choose a **Trigger Type** from the drop-down selector. Read more about trigger types in the [later sections of this document](#core-triggers). 2. **Inbound**: The workflow's start is triggered by another workflow. 3. **Outbound**: The workflow's completing triggers another workflow. 4. Fill out the fields that appear depending on your trigger mode selection. For more on trigger modes and their required fields, see the [trigger mode section](#three-trigger-modes-in-rewst) of this document. 7. Optional: Click the **Overrides** tab and add [integration overrides](/documentation/automations/intro-to-triggers). 8. Optional: Click the **Run For** tab and add or [tags](/documentation/settings/tags-in-rewst). 9. Click **Save Trigger**. 10. Follow the process again to add additional triggers.

### Trigger criteria When you're comfortable with the basics of triggers, learn more about [trigger criteria here](#trigger-criteria). It's a separate submenu tab the trigger menu, and has its own documentation page. The below table outlines the fields in the trigger criteria configuration menu.

Item	Description
Name	Whatever you would like to name your trigger, with a descriptive word or phrase for what it does.
Enabled	Toggle this on or off.
Organizations	Select all the organization that exist within Rewst that may need to use this workflow. If you add a new client, they will have to be added in that workflow trigger.
Integration Override	To give the workflow access to integrations and credentials owned by the parent organization, that default behavior must be explicitly overridden. In the above example image, the trigger allows your clients to use your PSA, RRM and licensing integration. See more about integration overrrides in the next section of this document.
Trigger Type	There are a number of types to choose from, such as a webhook, form submission, ticket saved, M365 alerts. See #core-triggers for more information on common trigger types.
Form	If your trigger type is a form submission, you would select the form that links to the workflow.

### What are integration overrides *Integration overrides* allow selection between multiple versions of the same integration at both the trigger and action levels, enabling granular control over workflow execution. When a workflow is triggered by and running within the context of a child organization, by default it only has access to the org's own integrations and configurations. To give the workflow access to integrations and credentials owned by the parent organization, that default behavior must be explicitly overridden. Rewst recommends adding more integration overrides rather than fewer.

Choose the integration for which to apply configuration overrides to by clicking
**+Add Integration Override** and selecting from the list.

1. Click

next to integration overrides. 2. Choose your desired integration or integrations from the drop-down selector that appears. This will populate the options for that integration below the selector. Each selected integration will have its own accordion menu added to the trigger configuration page. 1. Configuration Selection Mode options 1. **Use Default** - The default configuration for the workflow owner will be used 2. **Use Selected Config** - Select a specific integration configuration to use: choosing this option reveals a new **Integration Configuration** drop-down selector where you'll choose an existing configuration 3. **Use Name Search** - Search the workflow owner's integration configurations by name: choosing this option reveals a new **Configuration Name** field where you'll enter the name 2. **Configuration Fallback Mode** - The behavior to be used if the selected configuration is not found, available for all Configuration Selection Mode options excluding Use Default 1. **Use Org Mapping** - Use the organization mapping defined in the integration settings page to select the configuration to use 2. **Fail Workflow** - If the matching configuration is not found, the workflow will fail with an error \
### Add an integration override 1. Click the **Overrides** tab. 2. Choose your desired integration from the selector that appears. You may select multiple integrations, but must choose one at a time. Click **+ Add Integration Override** each time to add another integration, and **Edit Integration Override** to return to the list for additional selections. This will populate the options for that integration below the selector. Each selected integration will have its own menu added to the overrides list. {% columns %} {% column %}

{% endcolumn %} {% column %}

{% endcolumn %} {% endcolumns %} 3. For each integration override, choose from the following settings: 1. **Use Default** - The default configuration for the workflow owner will be used 2. **Use Selected Config** - Select a specific integration configuration to use: choosing this option reveals a new **Integration Configuration** drop-down selector where you'll choose an existing configuration 3. **Use Name Search** - Search the workflow owner's integration configurations by name: choosing this option reveals a new **Configuration Name** field where you'll enter the name 4. **Configuration Fallback Mode**, available for Use Selected Config and Use Name Search only - The behavior to be used if the selected configuration is not found, available for all Configuration Selection Mode options excluding Use Default 1. **Use Default** - If the matching configuration is not found, the default configuration for the workflow owner will be used 2. **Fail Workflow** - If the matching configuration is not found, the workflow will fail with an error 4. Click **Submit**. {% columns %} {% column %}

{% endcolumn %} {% column %}

{% endcolumn %} {% endcolumns %} {% hint style="warning" %} Note that when you unpack a Crate, it will automatically look at your installed integrations to decide which integration overrides to apply to your particular unpack. If you add additional integrations or change integrations after a Crate has been unpacked, and want that integration to be recognized and used with integration overrides for the Crate's workflow, you'll need to go to the trigger for that workflow and manually add the new integration to the integration overrides field. {% endhint %} #### Integration override on an action While integration overrides mainly live on and apply to triggers, you can also add them to actions under the **Advanced** tab of their right side configuration menu. The main use case for an action-based integration override is when you use [multi-instance integration](/documentation/integrations/multi-instance-integration) in Rewst. The process and selections for this integration override are the same as for those set on a trigger.

{% hint style="info" %} If you've set integration overrides on both the trigger and an action in a workflow, the action override takes precedence over the trigger override and will cancel it out. {% endhint %} ### Activate trigger to run for This submenu controls which organization**s** a workflow trigger is enabled for. When a triggered, it determines which organizations the workflow can execute in the context of. Each trigger on a workflow has its own Activate Trigger To Run For settings. They aren't shared between multiple triggers on the same workflow. 1. **Selected Organization** toggle 1. Toggled on by default, this enables the trigger for the organization that owns the workflow, usually the parent organization 2. Toggle off if you don't want the workflow to run for the owning organization 2. **Organizations** drop-down selector 1. Manually select specific organizations 2. Choose individual child organizations that should have this trigger active 3. **All Current and Future Managed Organizations** toggle 1. Toggle on to automatically enable the trigger for: 1. All currently existing child organizations 2. Any new organizations added in the future - automatically included 4. Click the **Run For** tab. 5. Choose your settings: 1. **Selected Organization** toggle 1. Toggled on by default, this enables the trigger for the organization that owns the workflow, usually the parent organization 2. Toggle off if you don't want the workflow to run for the owning organization 2. **All Current and Future Managed Organizations** toggle 1. Toggle on to automatically enable the trigger for: 2. All currently existing child organizations 3. Any new organizations added in the future - automatically included 3. **Organizations** drop-down selector 1. Manually select specific organizations 2. Choose individual child organizations that should have this trigger active 4. **Tags** drop-down selector 1. Choose to activate organizations which have been given the specified tags 2. Any future organizations tagged will be pulled in via the tag

{% hint style="warning" %} * If you don't enable All current and future managed organizations, you must manually add new clients to the trigger when they're onboarded. * You can't filter organizations by tags in this menu - it's either individual selection, all, or all plus future. * Even if a trigger is activated for an organization, the workflow will only work if that organization has the required integrations configured and mapped. * If the workflow uses parent organization integrations like your PSA, you must configure integration overrides on the trigger to give child orgs access to those credentials. {% endhint %} ### Critical timing {% hint style="warning" %} Starting on May 2, 2026, all workflows will default to their critical timing set as **False**. If you want a workflow to run at a specific time without flexibility, be it a new workflow or an existing workflow, you'll need to manually indicate this in the Critical Timing selector. {% endhint %} *Critical timing* is Rewst's setting for indicating if a workflow with a cron trigger must be run at a certain time or if there can be allowed variation in when the workflow is triggered. Choose **true** if the workflow must run at the same time each day. Choose **False** or **None** if the workflow's schedule has flexibility. This will adjust the start time, but maintain the frequency of when the workflow is triggered. By default, triggers that share the same schedule are spread across a short window to reduce load spikes and improve performance.

The time window will depend on your schedule's frequency, capped at 30 minutes:\ `*/5 * * * *` : every 5 min — within \~1 min\ `0 * * * *` : hourly — within \~15 min\ `0 10 * * *` : daily at 10 AM — within \~30 min\ `0 0 1 * *` : 1st of each month — within \~30 min ## Modify an existing trigger To modify an existing trigger, click on the yellow trigger bar. Then, click on the individual trigger in the trigger list. Update any of the settings in the tabs as desired, then click **Save Trigger**. ## 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. The requirements for this[ can be found here](/documentation/automations/workflows/option-generator-workflows).

The above is a screenshot 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. ## Core triggers There are seven 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 - 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. It's mostly used with the **Test** button in the Workflow Builder Canvas, and options generators for forms that need an override for its fields. 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: running a workflow on demand * Subworkflows or completion handlers: workflows triggered by other workflows * Testing automation: verifying workflow functionality * Option generators: dynamically populating form fields in Rewst {% hint style="info" %} For more information on option generators, refer to [Rewst Foundations](https://learn.rewst.io). {% endhint %}

Core - App Platform

This trigger functions the same as Core - Always Pass. By using this trigger type, you create a clear indication that the intended use case is for Rewst's [App Builder](/documentation/app-builder). Note that it is only useful in locations where you can select a trigger— Data Tables and Charts.

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](https://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: clearing stale data, running audits * Recurring notifications: sending reminders, generating reports * Automated check-ins: verifying system statuses, updating dashboards This trigger also uses [critical timing](#critical-timing).

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: access requests, service requests * Intake processes: user registrations, issue reporting * Approval workflows: leave requests, expense approvals {% hint style="info" %} For help building a form, refer to [Conditional fields](/documentation/automations/forms/form-best-practices). {% endhint %}

Core - 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 {% hint style="info" %} Check out our [Use webhook triggers](/documentation/automations/intro-to-triggers/use-cases-and-examples/using-webhook-triggers) page for a more detailed example. {% endhint %}

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 like 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: responding to new leads, updating records on status changes * Real-time notifications: escalating high-priority tickets, alerting teams to critical updates * External system integrations: syncing data between platforms, processing incoming requests {% hint style="info" %} For more information on webhook triggers, refer to [Use webhook triggers](/documentation/automations/intro-to-triggers/use-cases-and-examples/using-webhook-triggers). {% endhint %}

PSA: Ticket record saved

{% hint style="info" %} Note that this is the only common trigger type that does not start with Core, as the trigger name will be specific to your brand of PSA. Search for that in the trigger type list instead. {% endhint %} 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: escalating high-priority tickets, auto-assigning technicians * SLA enforcement: sending reminders for unresolved tickets, auto-responding to specific cases * Status-based automation: triggering follow-up workflows when a ticket is created or reaches a certain stage {% hint style="info" %} For more detailed information on PSA triggers, refer to [Customize PSA ticket triggers](/documentation/automations/intro-to-triggers/use-cases-and-examples/customizing-psa-ticket-triggers). {% endhint %}

## Rewst triggers *Rewst* triggers are additional triggers that can be used across all integrations and relate directly to the Rewst platform. Type `Rewst` into the **Trigger Type** field to isolate most of these trigger types from the total list.

Rewst - Added User

The Rewst - Added User trigger starts the workflow when a new user is added in Rewst. The triggering event is when the user signs in for the first time, not when the invite is sent. This trigger is useful for: * Onboarding automation when new users are added to Rewst * Sending welcome notifications to new users * Syncing new user accounts to external systems * Auditing and logging new user creation events * Automatically assigning resources or permissions to new users When this trigger kicks off, it provides the following data in `triggering_user_data`: | Field | Type | Description | | -------------- | ---------------- | --------------------------------------- | | `id` | string | The user's unique identifier | | `role` | string | The user's role | | `org_id` | string | The organization ID the user belongs to | | `role_ids` | array of strings | List of role IDs assigned to the user | | `username` | string | The user's username | | `created_at` | datetime | When the user was created | | `updated_at` | datetime | When the user was last updated | | `is_superuser` | boolean | Whether the user is a superuser |

Rewst - Added User in Whitelist

The Rewst - Added User in Whitelist trigger starts the workflow when a user is whitelisted, or invited, in Rewst. This trigger is useful for: * Sending custom welcome emails when users are invited to Rewst * Logging and auditing user invitation events * Triggering approval workflows before invites are finalized * Syncing invite information to external ticketing or documentation systems * Tracking who is inviting users and to which organizations When this trigger kicks off, it provides the following data in `triggering_user_invite_data`: | Field | Type | Description | | --------------- | ---------------- | ------------------------------------------------ | | `id` | string | The invite's unique identifier | | `email` | string | The email address of the invited user | | `org_id` | string | The organization ID the user is being invited to | | `role_ids` | array of strings | List of role IDs assigned to the invited user | | `created_at` | datetime | When the invite was created | | `updated_at` | datetime | When the invite was last updated | | `accepted_at` | datetime | When the invite was accepted - if applicable | | `is_accepted` | boolean | Whether the invite has been accepted | | `created_by_id` | string | The ID of the user who created the invite |

Rewst - Crate Published Trigger

The Rewst - Crate Published Trigger kicks off the workflow when a Crate is published in Rewst, allowing you to react programmatically. This trigger is useful for: * Automating notifications when new crates are published to the Rewst marketplace * Triggering review or approval workflows when crates are published * Logging and auditing crate publication events * Syncing crate publication information to external documentation or communication systems * Automating post-publication tasks like announcements or version tracking The Crate will include the following in the workflow execution once triggered. `CTX.triggering_crate_data.crate_id` ID of the Crate `CTX.triggering_crate_data.workflow_id` ID of the parent workflow in the Crate

Rewst - Deleted User

The Rewst - Added User trigger starts the workflow when an existing user is removed in Rewst. This trigger is useful for: * Offboarding automation when users are removed from Rewst * Auditing and logging user deletion events for compliance * Syncing user deletions to external systems (e.g., removing access elsewhere) * Sending notifications when users are removed * Cleaning up resources or permissions associated with deleted users When this trigger kicks off, it provides the following data in `triggering_user_data`: | Field | Type | Description | | -------------- | ---------------- | ----------------------------------------------- | | `id` | string | The deleted user's unique identifier | | `role` | string | The user's role (at time of deletion) | | `org_id` | string | The organization ID the user belonged to | | `role_ids` | array of strings | List of role IDs that were assigned to the user | | `username` | string | The user's username | | `created_at` | datetime | When the user was originally created | | `updated_at` | datetime | When the user was last updated | | `is_superuser` | boolean | Whether the user was a superuser |

Rewst - Deleted User in Whitelist

The Rewst - Deleted User in Whitelist trigger starts the workflow when a user is deleted from a whitelist, meaning that their invite is removed in Rewst. This trigger is useful for: * Auditing and logging when user invites are revoked or removed * Sending notifications when pending invites are cancelled * Syncing invite deletions to external ticketing or documentation systems * Tracking invite lifecycle events for compliance purposes * Cleaning up any resources or pending actions associated with revoked invites When this trigger kicks off, it provides the following data in `triggering_user_invite_data`: | Field | Type | Description | | --------------- | ---------------- | ------------------------------------------------------- | | `id` | string | The invite's unique identifier | | `email` | string | The email address of the invited user | | `org_id` | string | The organization ID the user was invited to | | `role_ids` | array of strings | List of role IDs that were assigned to the invited user | | `created_at` | datetime | When the invite was originally created | | `updated_at` | datetime | When the invite was last updated | | `accepted_at` | datetime | When the invite was accepted - if applicable | | `is_accepted` | boolean | Whether the invite had been accepted | | `created_by_id` | string | The ID of the user who created the invite |

Rewst - Managed Organization Added

The Rewst - Managed Organization Added trigger starts the workflow when a new parent organization is added in Rewst. This trigger is useful for: * Automating client onboarding workflows when new managed organizations are added * Sending notifications to internal teams about new clients * Automatically provisioning resources or configurations for new organizations * Syncing new organization data to external PSA, documentation, or CRM systems * Triggering initial setup tasks like creating default users, permissions, or integrations * Auditing and logging new organization creation events When this trigger kicks off, it provides the following data in `triggering_organization_data`: | Field | Type | Description | | ----------------- | -------- | -------------------------------------------- | | `id` | string | The organization's unique identifier | | `tid` | string | The tenant ID | | `name` | string | The organization's name | | `domain` | string | The organization's domain | | `is_msp` | boolean | Whether the organization is an MSP | | `created_at` | datetime | When the organization was created | | `updated_at` | datetime | When the organization was last updated | | `customer_id` | string | The customer ID | | `roc_site_id` | string | The ROC site ID | | `managing_org_id` | string | The ID of the managing (parent) organization | | `subscription_id` | string | The subscription ID |

Rewst - Managed Organization Deleted

The Rewst - Managed Organization Added trigger starts the workflow when an existing parent organization is removed in Rewst. This trigger is useful for: * Automating client offboarding workflows when managed organizations are removed * Sending notifications to internal teams about client departures * Cleaning up resources, configurations, or integrations associated with the deleted organization * Syncing organization deletions to external PSA, documentation, or CRM systems * Auditing and logging organization deletion events for compliance * Revoking access or permissions tied to the deleted organization * Archiving data or records related to the removed client When this trigger fires, it provides the following data in `triggering_organization_data`: | Field | Type | Description | | ----------------- | -------- | -------------------------------------------- | | `id` | string | The deleted organization's unique identifier | | `tid` | string | The tenant ID | | `name` | string | The organization's name | | `domain` | string | The organization's domain | | `is_msp` | boolean | Whether the organization was an MSP | | `created_at` | datetime | When the organization was originally created | | `updated_at` | datetime | When the organization was last updated | | `customer_id` | string | The customer ID | | `roc_site_id` | string | The ROC site ID | | `managing_org_id` | string | The ID of the managing (parent) organization | | `subscription_id` | string | The subscription ID |

Rewst - Managed Organization Updated

The Rewst - Managed Organization Added trigger starts the workflow when an existing parent organization is updated in Rewst. This trigger is useful for: * Syncing organization changes to external PSA, documentation, or CRM systems * Sending notifications when client organization details are modified * Auditing and logging organization update events for compliance * Triggering workflows when organization settings or configurations change * Updating related resources or integrations when organization data is modified * Tracking changes to organization names, domains, or other key attributes When this trigger kicks off, it provides the following data in `triggering_organization_data`: | Field | Type | Description | | ----------------- | -------- | -------------------------------------------- | | `id` | string | The organization's unique identifier | | `tid` | string | The tenant ID | | `name` | string | The organization's name | | `domain` | string | The organization's domain | | `is_msp` | boolean | Whether the organization is an MSP | | `created_at` | datetime | When the organization was originally created | | `updated_at` | datetime | When the organization was last updated | | `customer_id` | string | The customer ID | | `roc_site_id` | string | The ROC site ID | | `managing_org_id` | string | The ID of the managing parent organization | | `subscription_id` | string | The subscription ID |

Rewst - Updated User

The Rewst - Updated User trigger starts the workflow when a user is updated in Rewst. This trigger is useful for: * Auditing user changes within Rewst * Syncing user updates to external systems * Triggering notifications when user roles or permissions change * Logging user modifications for compliance purposes When this trigger kicks off, it provides the following data in `triggering_user_data`: | Field | Type | Description | | -------------- | ---------------- | --------------------------------------- | | `id` | string | The user's unique identifier | | `role` | string | The user's role | | `org_id` | string | The organization ID the user belongs to | | `role_ids` | array of strings | List of role IDs assigned to the user | | `username` | string | The user's username | | `created_at` | datetime | When the user was created | | `updated_at` | datetime | When the user was last updated | | `is_superuser` | boolean | Whether the user is a superuser |

Rewst - Updated User in Whitelist

The Rewst - Updated User in Whitelist trigger starts the workflow when a whitelist is updated in Rewst. This trigger is useful for automating actions when user invitations are modified in Rewst, such as: * Logging changes to user access * Notifying administrators of whitelist updates * Triggering onboarding or offboarding workflows based on invite status changes When this trigger kicks off, it provides the following data in `triggering_user_invite_data`: | Field | Type | Description | | --------------- | -------- | -------------------------------------------- | | `id` | string | The unique identifier of the user invite | | `email` | string | The email address of the invited user | | `org_id` | string | The organization ID the invite belongs to | | `role_ids` | array | List of role IDs assigned to the user | | `created_at` | datetime | When the invite was created | | `updated_at` | datetime | When the invite was last updated | | `accepted_at` | datetime | When the invite was accepted (if applicable) | | `is_accepted` | boolean | Whether the invite has been accepted | | `created_by_id` | string | The ID of the user who created the invite |

## Other triggers Rewst offers additional triggers for some of our integrations tailored to different automation needs. Explore the available triggers in the trigger type list to find the best fit for your specific processes. Try asking [RoboRewsty](/documentation/roborewsty) what each integration-specific trigger does to learn more about how it can be used, or read more about included triggers on each integration's info page in this site.

A moving GIF image depicting scrolling through the trigger type list in an example organization in Rewst. Various integrations' actions are shown. — The contents of the complete trigger type list will depend on your particular integrations

# Trigger criteria *Trigger criteria* are 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. In simple terms, you're setting up the automation to only trigger when certain conditions are met or values are present. This can be helpful to customize when you want a workflow to run. For example, rather than having it run for all incoming tickets, you would use trigger criteria to set a workflow to run for just tickets related to password reset requests. The trigger criteria tab of the trigger menu will only appear if you've chosen a trigger type that works with criteria. This includes [core webhook](/documentation/automations/intro-to-triggers#core-webhook) triggers and any integration-type triggers.

An animated image of the user choosing a trigger typed ConnectWise PSA. As the user clicks, a new section of the menu appears titled 'Trigger Criteria.' The test is white on a dark blue screen. — Scroll down to the bottom of the trigger menu once you've chosen your trigger type to see the trigger criteria submenu.

## Trigger criteria submenu

1. Click **+Add Criterion** to add new trigger criteria. This will reveal a new set of fields. You can only add one set at a time, but may add multiple criterion. 2. Click **Test Criteria** at the bottom of the right side menu to open the trigger criteria test dialog. This option will only appear after you've saved both your trigger and your trigger criteria. The dialog allows you to use past events in your relevant tool to test out conditions for future events. From this dialog, you can also add new trigger criteria. Note that the trigger must be set to **enabled** for this dialog to work. Learn more about this dialog in the [Trigger criteria test dialog](#trigger-criteria-test-dialog) section of this document. 3. The **Key** 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. 4. Click

to open a Monaco editor dialog. 5. The **Operator** drop-down is used to compare the value of the Key field with the **Value** field. Click the arrow to open the drop-down list of all possible operators. 1. Equals 2. Equals (case sensitive) 3. Not Equals 4. Contains 5. Starts With 6. Ends With 7. Greater Than 8. Less Than 9. Exists 10. Does Not Exist 11. In - be sure to press the `Enter` key to convert the value into a list 12. Not In - be sure to press the `Enter` key to convert the value into a list 13. Jinja Evaluation 6. The **Value** field contains the text parameter of the **Key** field to compare with the value of the trigger context. Note that only string values are supported in this field. If you need to evaluate non-string values, you can use Jinja Evaluation to do so. 7. Click **Delete Condition** to remove the related trigger criteria.

## Trigger criteria test dialog The dialog can be viewed in the right side menu in condensed form, or via a full dialog that appears in the center of your screen by clicking

The full dialog is made up of two panels. The right panel shows all prior triggering events in a list, with the most recent events displayed at the top. You must enable the trigger to receive trigger events, and also slide the **Test Trigger Criteria** toggle to play, not pause. The system will approximately log the latest 10 events for one day. There is no throttling on the logging system.

Click on the value of the trigger context for any of these events to generate and display its criteria in the left panel. This will automatically map the field accessor and the selected value of the trigger context. Note that the events in the right panel list have color coded headers at the top of each, with the color denoting a different status for that event. Each trigger type may have different trigger context data or formatting. | Status | Meaning | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | VALID - Blue![](/files/zBgaSmwq0MF9j784yDbI) | 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. All valid trigger events should have a corresponding workflow execution. | | FILTERED - Yellow![](/files/BWOHlTMAxkrNJKNFSMkC) | A filtered trigger will not start the workflow, typically for one of the following reasons: a condition is logically unmet by design, a condition is malformed and unparseable, or the trigger request itself is malformed and rejected by the system. A filtered trigger event may show warnings if errors are found while processing the trigger event. | {% hint style="warning" %} If no criteria are set, anything will be considered a valid triggering event. {% endhint %} Alternatively, click **+ Add Criteria** to create a new set of fields for a new criteria. {% hint style="success" %} You can’t set more than one condition on the same field. Rewst will adopt the first condition and destroy any future conditions without giving a warning message. Though you can only have one condition on specific field at a time, you can have as many conditions as you wish, as long as they are each on a different field. {% endhint %} ## Trigger context examples

Basic example: Apple, orange, banana

In plain speak, we want to set the criteria to be that a fruit is an apple, where all possible fruits are apple, orange and banana. The price of the apple is $1.99. The colors corresponding to each type of the fruits are red, orange, and yellow respectively. Now let's look at it in Rewst. Given the following trigger context: ```javascript { fruit: "apple", fruits: ["APPLE", "orange", "banana"], price: 1.99, types: { colors: ["red", "orange", "yellow"], } } ``` The following trigger criteria will be valid, and match our statement:

* For this example, note that while you could have each of the types of fruits with an operator of Equals and the value set to the entire text name of each fruit, using the alternative operators such as contains, Starts With and Ends With allow you to pull in more results for your criteria. If you only know that the domain you want to act as a trigger ends in co.uk, you could use an operator other than Equals, to pull in results that contain those few letters rather than requiring it to match an entire address' exact text. * The field accessor uses dot notation to access the value in the trigger context: apple = fruits,0, orange = fruits.1, banana = fruits.2, etc. * If you are making use of the In or Not In operator, be sure to press the **Enter** key to convert the value into a list. * You can't have identical field accessors in the same trigger criteria, with the exception of Jinja criteria. * We make use of simple Python operators to compare the values of the trigger context and the field value. For more information, please refer to the [Python Operators](https://www.w3schools.com/python/python_operators.asp) * Default conditions are And conditions. If you want to use Or conditions, you can use the Jinja criteria. Please see the advanced examples below.

Advanced example: Jinja evaluation

Given the following trigger context: ```javascript { fruit: "apple", fruits: ["APPLE", "orange", "banana"], price: 1.99, types: { colors: ["red", "orange", "yellow"], } } ``` The following Jinja evaluation will be valid: ```jinja2 {{ CTX.fruit == 'apple' or CTX.price < 2 }} ``` Jinja evaulations do not require a field accessor, and the entire trigger context is available under the CTX variable.

## Save trigger criteria You'll need to save your updates for the trigger criteria to take effect. How you do this will depend on if you are adding criteria directly under the **Trigger Criteria** submenu or within the Trigger Criteria Test dialog. Click **Save Trigger** under the Trigger Criteria submenu to save your added or updated trigger criteria.

Click **Save Trigger Criteria** in the Trigger Criteria Test dialog to save and close the dialog. {% hint style="success" %} While the Trigger Criteria Test dialog is open, you can press the **`F8`** key to save the trigger. {% endhint %} # Trigger use cases and examples {% content-ref url="/pages/5Ii4gMurr7uwZWcWzCUN" %} [Customize PSA ticket triggers](/documentation/automations/intro-to-triggers/use-cases-and-examples/customizing-psa-ticket-triggers) {% endcontent-ref %} {% content-ref url="/pages/FVzl5mmXgVzAHfdwKEb0" %} [Use webhook triggers](/documentation/automations/intro-to-triggers/use-cases-and-examples/using-webhook-triggers) {% endcontent-ref %} {% content-ref url="/pages/ic8ny1cJnkRdK2pv82da" %} [Configure a webhook trigger for CORS requests](/documentation/automations/intro-to-triggers/use-cases-and-examples/configure-a-webhook-trigger-for-cors-requests) {% endcontent-ref %} # Customize PSA ticket triggers 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. ## Get started with trigger setup ### Create the workflow In the Rewst platform: 1. Navigate to **Automations > Workflows > Create Workflow**. 2. Enter a workflow name, like `My First Webhook Trigger`. 3. Click **Submit** to proceed to a blank Workflow Builder Canvas. 4. Add a single [no-op](/documentation/automations/actions-in-rewst/core-actions#no-operation-noop) action to the canvas. Name it `BEGIN` 5. Click **Deploy** to save your workflow. No other actions are needed, as you'll just be working with triggers. 6. Click

**> Flow Control**. 7. Drag the yellow **Triggers** to the Canvas. This opens up the new trigger's **Trigger Settings** in the right side menu. ### **Create the trigger** 1. Name your trigger. 2. Toggle **Enabled** on. 3. Use the **Trigger Type** drop-down selector to 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](https://docs.rewst.help/documentation/integrations/psa/autotask-datto-psa/webhook-configuration). 3. Halo PSA**:** **New Ticket Record**. 4. Click the **Criteria** tab. 5. Click **+ Add Criterion**. Add your[ trigger criteria](/documentation/automations/intro-to-triggers/trigger-criteria).

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.

## Test the trigger with a PSA ticket To see the trigger in action follow the below steps ### **Create 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. {% hint style="info" %} Once the ticket is visible in Rewst, click the pause button to stop more tickets from coming in while you're building your trigger criteria. {% endhint %} ### **Select 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.

## Finalize and implement trigger criteria ### **Save your criteria** * After selecting all desired criteria, click `Save` then `Close`. * Your trigger criteria are now set and visible. ### **Apply criteria to workflows** * Copy these criteria values. * Paste them into other workflows you are configuring.

# Use webhook triggers ## What is a webhook trigger? *Webhook triggers* are an effective way to kick off a workflow with context from external systems. By sending an API request to a webhook trigger, Rewst will fire the workflow and include any data and or queries included in the request. For example, when a customer submits a support ticket, a webhook instantly sends that information to Rewst and starts a workflow.
{% hint style="warning" %} When using webhook triggers, design your workflow with our [rate limiting policy](/security/webhook-trigger-rate-limits) in mind. {% endhint %} ### **Webhook trigger process** Webhooks follow a simple process: 1. An event happens, such as when a new ticket is submitted. 2. The webhook sends a message with data to a URL. 3. A workflow is triggered based on that message. ### **Webhook URLs** A *webhook URL* is a unique address where data is received for that particular webhook. It continuously listens for data, and kicks off the related workflow the moment data is received. Once that data is captured, we call it a *payload*, and it becomes usable inside the workflow. This allows you to do things like: * Assign tasks based on field values * Push updates to other systems * Send messages or alerts * Store or log information for reporting 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 }}` ## Create the workflow In the Rewst platform: 1. Navigate to **Automations > Workflows**. 2. Click **Create Workflow**. 3. Enter a workflow name, like `My First Webhook Trigger`. 4. Click **Submit** to proceed to a blank Workflow Builder Canvas 5. Add a single [no-op](/documentation/automations/actions-in-rewst/core-actions#no-operation-noop) action to the canvas. Name it `BEGIN` 6. Click **Deploy** to save your workflow. No other actions are needed, as you'll just be working with triggers. 7. Click

**> Flow Control**. 8. Drag the yellow **Triggers** to the Canvas. This opens up the new trigger's **Trigger Settings** in the right side menu.

## **Create the webhook trigger** 1. Name your trigger. 2. Toggle **Enabled** on. 3. Choose the trigger type **Core - Webhook**. This will reveal a new **Parameters** section in the right side menu.\ \ ![](/files/CbePLmKExpmwVthonfNR) ## **Set trigger parameters** *Parameters* are like fill-in-the-blank options that make workflows adaptable. Webhooks deliver data to workflows, and parameters use that data to customize actions. For example, instead of hardcoding a date, you could use a parameter called `ReminderDate` to customize it each time the workflow runs. The following parameters are available for editing in workflow trigger configuration: * **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** * Recommended to be used with 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, this calls to the trigger endpoint will redirect to a results endpoint that will return the output of the workflow.

{% hint style="success" %} When finished updating your parameters, remember to click **Save Trigger**. {% endhint %} ## **Access data in a webhook trigger request** When a webhook receives a request, it will include data received in the following schema: ```json { 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: ```json { "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 }}` #### Webhook payload example Below is a real webhook payload that was received in a Rewst workflow. You can view payloads in the [workflow results](/documentation/automations/workflows/troubleshoot-workflow-executions-and-task-results#workflow-executions-for-troubleshooting) for that particular workflow. ``` { "ticket_id": 67890, "customer": "Jamie Smith", "priority": "high", "issue": "Password reset not working" } ``` * The customer is named Jamie Smith. * The priority level of high indicates the urgency of the ticket. * The next logical step in a workflow might be to assign the ticket for resolution, since the issue is a password reset problem that must be solved by human intervention. ## Trigger criteria and webhook triggers Once you connect an external tool to Rewst with a webhook, you may run into a problem: too many workflows firing at once. Every webhook that hits your Rewst URL will start the workflow, even if the event isn’t important. That can quickly eat up task cost and make it harder to focus on what matters. [Trigger criteria](/documentation/automations/intro-to-triggers/trigger-criteria) solve this by acting as filters. They check the webhook data against conditions you set, and only start the workflow if those conditions are met. You can add as many conditions as you need, across any attributes available in the webhook data. # Configure a webhook trigger for CORS requests {% hint style="info" %} Though this is related to triggers, it's most often used in conjunction with App Builder. Learn more about Rewst's App Builder in our documentation [here](/documentation/app-builder). {% endhint %} ## What is a CORS request? When referencing a Rewst web hook in JavaScript in an App Builder page— or outside of Rewst— you may see the error `TypeError: Failed to fetch.` This happens when the browser blocks your request because it does not allow *cross-origin* requests by default. To make your webhook accessible from a web page, you must configure *CORS (Cross-Origin Resource Sharing)* headers and enable OPTIONS requests on your webhook. {% hint style="info" %} Note that **wait for webhook** cannot be set to `true` for this to work. Additionally, this webhook shouldn't use a secret key. {% endhint %} ## Add CORS headers to your web hook response 1. Open your webhook trigger inside the workflow. 2. Click ![](/files/yRhzrk2xPyH045czZ3PH) to open the response headers code editor. 3. Add the following headers: ```django { "Content-Type": "application/json", "Access-Control-Allow-Origin": "https://YOURDOMAINHERE", "Access-Control-Allow-Methods": "POST, GET, OPTIONS", "Access-Control-Allow-Headers": "Content-Type" } ```

{% hint style="warning" %} **Important -** Match the *exact* origin of your site. > ✅ > ❌ Avoid using \* unless the webhook is fully public and returns no sensitive data. {% endhint %} ## Reference table | Header | Description | Example | | ---------------------------- | ---------------------------------------- | ---------------------------------- | | Access-Control-Allow-Origin | Defines which site may call your webhook | | | Access-Control-Allow-Methods | Lists allowed HTTP verbs | GET, POST, OPTIONS | | Access-Control-Allow-Headers | Lists allowed custom headers | Content-Type | | OPTIONS | Preflight permission check | Must return 200 with headers | ## Handle OPTIONS preflight requests Browsers send an *OPTIONS* request before certain POST or PUT requests to confirm that CORS is allowed. Your webhook must allow OPTIONS requests for this to succeed. Add OPTIONS under the **Allowed Methods** field of your **Trigger Parameters** menu in workflow settings**.**

## Troubleshoot the CORS webhook trigger #### Trailing slash in origin Try removing the slash from the end of your domain. #### Missing OPTIONS handler Add the OPTIONS method to the webhook. # Forms ## What is a form? In Rewst, every automation starts with a single click. *Forms* are powerful tools used to collect the information your workflows need to start. They streamline the data collection process by gathering key details from users such as names, dates, or options. Forms can be manually created, or added as part of [Crate unpacking](https://docs.rewst.help/prebuilt-automations/crates#unpack-a-crate). Rewst's form functionality is designed to empower users with the tools to build interactive, responsive, and customizable forms. ## Why use forms? Forms collect data in one simple step, reducing manual data entry and saving you time. They can also function as triggers in Rewst when building workflows, allowing for seamless transitions and increased efficiency. Use a form submission in your workflow if user input is required for the automation to run. You wouldn't use a form, for example, if the all the information needed for the automation to run could be retrieved via webhook trigger. Expand the reach of your forms by embedding them into various web pages, providing increased accessibility to users. Tailor forms to specific scenarios through cloning and modification, ensuring the right fit for every situation. ## View forms in Rewst Access all forms, be they manually created by you or obtained as part of unpacking Crates, by navigating to **Automations > Assets > Forms** in the left side menu.

An example of what your forms page might look like

### Export and import forms You can export a form to share with other Rewst customers, or create your own hard copies of form backups. To export a form as a JSON bundle, **click ⋮ > Export** next to your relevant form in the total form list. To import a form bundled as a JSON file, click ![](/files/pSRxSYvjj8rtjxgRxLTC) in the top right navigation bar of the forms page. Then, drag and drop your file into the upload dialog that appears. ## Request a forms feature update We’re constantly adding new features to Rewst. If you have a suggestion for what we could add to our forms functionality, add a request or upvote other existing suggestion posts [in our Canny.](https://rewst.canny.io/integrations) {% hint style="success" %} Want to learn more? Search for the **How to build forms** course in Cluck University. {% endhint %} # Build a form with Rewst's Form Builder Learn how to build and customize your Rewst Forms ## Create a new form The part of Rewst you use to create and edit forms is called the *Form Builder*. To access it, navigate to **Automations > Assets > Forms**, and click ![](/files/BUQkmPYXmm8ZhrULwib4).

In the **Create New Form** dialog, give your form a descriptive name. Remember, as you build more in Rewst, your list of forms will grow significantly. Following proper naming conventions will save you time in finding your right form later on.

The Form Builder is similar to Rewst's Workflow Builder in that it has a list of options on the left, called *form fields*, which can be dragged and dropped onto the canvas in the center of your screen. Each of these options will relate to your *inputs***,** or the information that goes into the form. With the exception of the **Text/Markdown** field which is only used for presenting data to the end user, all other fields are used as data input and contain a field name, field label and field description. The field name is the variable name used within the workflow once the form has been submitted. The field label and field description are used to format the appearance of the form. Using the correct fields ensures your workflows receive clean, organized data. ### Form field options {% hint style="info" %} Click on any of the below form field options to expand and see its information. {% endhint %}

Text/Markdown

The **Text/Markdown** field lets you present text, optionally formatted with Markdown. You can also render Jinja in these fields, which can be useful for presenting organization variables, or rendering a Markdown table with data from elsewhere in the form.\ \

Drop-down

**Drop-down** fields let you select from multiple options, which can either be hard coded into the form or dynamically generated. Each option on the form has a *label* and a *value*, and default options can be preselected if specified. There are also options for: * **Auto-Populate**: if enabled, will always pre-populate the field if only a single option has been returned. * **Allow Custom Input**: lets the enduser write in the field and have that be the value passed into the workflow. * **Always Skip Cache**: causes the option generator to always run instead of pulling from a cache. Note that the cache for a form field invalidates every 8 hours. Typically the first run of the day will be slower than the rest. * **Always Override Option**: used when the auto-populate setting is enabled, this will cause the field to repopulate itself. This is needed in cases where the field is populated via an option generator and another field is being used as input for the option generator. In that case, you would need the option generator to run again, as the output would likely be different. These are used most commonly when the list of options is being generated via an options generator *.*\ Drop-down selection is limited to a single option. For multiple options for selection, see the multi-select form field option.\ \

Multi-Select

**Multi-select** is similar to the dropdown field, but lets you select as many options as you like, up to a maximum number of options which can be specified on the field.\ \ ![](/files/eM5kk8L3Xj68bv3Jy1QR) Here are two examples, one for returning a specific item within the list, and one for checking if values are provided: ``` {{ CTX.[0].value|d }} ``` ``` {{ CTX.|length > 0 }} ```

Checkbox

The **Checkbox** field provides a toggle with a true/false value for the form. You can also change the label positioning.\ \ ![](/files/gKyANwaWQofoJZMwfp1h)

Radio Buttons

The **Radio Buttons** field offers a selectable single option. It can also be dynamically populated in the same way as a dropdown or multi-select field, but doesn't allow for the additional options of auto-populate, allow custom input, always skip cache and always override option. For this reason, radio buttons are rarely used with dynamic options.\ \ ![](/files/QHqaANPJ2XuJUWXeLU3H)

Text Input

The **Text Input** field accepts a single line text string. You can also perform regex validation and error reporting, or populate the field with a default value.\ \ ![](/files/WNUqSWsktTg2SunCUTKm)

Number Input

The **Number Input** field accepts numbers, as long as they meet the Python definition of numbers: whole numbers or floats. Set a default value, as well as minimum and maximum values.\ \ ![](/files/WNUqSWsktTg2SunCUTKm)

Multi-Line Input

The **Multi-Line Input** field accepts large amounts of text. No validation is available for this field.\ \ ![](/files/zu14Ges4bNM2Uc3txtqo)

Date

The **Date** field can be set up to accept dates, or times and date times together. Note that the time zone or this field is based on your browser locale. Rewst converts the time into UTC when passed into the workflow without the time zone data. As an example, if you're in EST and you select 6pm, the workflow will receive this as 1pm UTC, due to the 5 hour offset. Adjust your submission for this time difference when you are submitting a form for a customer in a different time zone from yourself, and need to specify a time.\ \ \ ![](/files/tLiwUFsdWG8AaIhDtYF7)

File Upload

The **File Upload** field allows for the uploading of specific file types: .CSV\ .JSON\ \ If you are working with an XL or XLSX file format, [convert it to CSV ](https://support.microsoft.com/en-us/office/import-or-export-text-txt-or-csv-files-5250ac4c-663c-47ce-937b-339e391393ba)before uploading.\ \ ![](/files/y50FptFDbOd2DqIuwDLn)

## Dynamic options in forms *Dynamic options* automatically fetch data from integrations, thereby eliminating the need for manual data entry and keeping form options up-to-date with the latest data. For example, if you're managing hiring information within your PSA, dynamic options can automatically pull this data into the form, ensuring that users always have the most current information. There are two types of dynamic options: integration reference and workflow generated. ### Option one: Integration reference A *reference option* is a dynamic field pulled directly from predefined actions. It works well for straightforward data retrieval, but may require conversion to a workflow-generated option for data manipulation, as this doesn't give any filtering options and will pull directly from the API endpoint. #### Integration reference example Selecting the Microsoft Graph integration to list all users.

{% hint style="info" %} Pulling data straight from the integration like this only works at the top, parent level organization where the integrations are installed. This option won't work for dynamically pulling child organization data. To achieve this, you would require an options generator. {% endhint %} ### Option two: Workflow generated options If you want more flexibility around the output of the data your user is seeing, you may need to opt for a workflow generated option instead, which allows for in-depth data manipulation using [Jinja](/documentation/jinja). We cover what these are and how to use them in Cluck U’s [Rewst Foundations](https://learn.rewst.io) and [micro course](https://learn.rewst.io). If you’ve already taken our courses and want a refresher, see our documentation on option generators [here](https://docs.rewst.help/documentation/workflows/workflow-generated-options) and [here](https://docs.rewst.help/documentation/workflows/different-types-of-workflows#option-generator). Alternatively, dynamic forms use cases can be handled with our options filter feature. The options filter makes customizing drop-down fields within forms straightforward for those who want to add filtering without updating an options generator workflow. It takes inputs, filters them, and produces an output agnostic of the data source. See our separate [options filter documentation here](/documentation/automations/forms/options-filter-filtering-in-forms). {% hint style="info" %} This setup requires the workflow type be an option generator. See our [option generator workflow page](/documentation/automations/workflows/option-generator-workflows) for more details on this functionality. The below documentation is high-level only. {% endhint %} #### Options generator example In this image, what is shown to the user is what is set as the label for the list contents. Ultimately, it can be whatever you want it to be, using Jinja to manipulate that output correctly. The ID is the value or unique ID of what the workflow is referencing for its future actions.

#### **Set default options** Default options can be selected for a form field linked to a workflow by following these steps. 1. Add a boolean property to each option result. 2. Define the boolean property for the **Default Selected Field** value. Sample data returned by a workflow: {% code lineNumbers="true" fullWidth="false" %} ```json [ {"label": "Adam", "id": "1", "current_default": false}, {"label": "Matt", "id": "2", "current_default": false}, {"label": "Jareth", "id": "3", "current_default": true} ] ``` {% endcode %} Fields to be filled out in the form: * **Value Field**: `id` * **Label Field**: `label` * **Default Selected Field**: `current_default` ### Dynamic form links A *dynamic form link* is a special type of URL that automatically directs users to the form specific to the organization they belong to in Rewst. Rather than using a static form link that always goes to the same location, a dynamic form link adapts depending on who is accessing it.

When sharing a form, instead of clicking **View Direct URLs**, you can click **Copy URL**.\ This generates a dynamic link that looks like this: ``` https://app.rewst.io/form/ ``` When a user opens this link: 1. The system checks who is logging in. 2. It validates which organization the user belongs to. 3. The user is then automatically redirected to the correct form URL for their organization. This ensures that users always land on the right form instance without needing to know or select their organization manually. Use a dynamic form link whenever you have a form that multiple organizations or users need to access, or when you want to provide a single, easy-to-share URL rather than multiple specific links. ### Dates in forms {% hint style="info" %} Form date formats — DD/MM/YYYY) versus MM/DD/YYYY— are influenced by browser locale settings, not controlled by the application itself. IT admins could deploy the desired locale to all of their customers if they want to ensure consistent appearance. Setting it once in the browser will set it for all forms. {% endhint %} #### Set your browser's locale Your browser’s locale controls: * How dates and times appear * The language used in websites and spellcheck * The region format for numbers and currency Follow the steps below for your relevant browser to use only the region you need, and remove the others for consistent behavior.

Mozilla Firefox

**Open Language Preferences** 1. Navigate to **Settings > General > Language**. 2. Under **Language and Appearance**, click **Choose…** next to **Language for displaying pages**. 3. Add only your desired language region: * English (Australia) * English (United States) * English (United Kingdom) **Remove Others** * Highlight any extra languages and click **Remove** so only one remains. **Confirm Locale** (Optional advanced step) 1. In the address bar, type `about:config`. 2. Search for: `intl.locale.requested` 3. Set it to: * `en-AU` for Australia * `en-US` for United States * `en-GB` for United Kingdom 4. Restart Firefox.

Google Chrome

**Open language settings** 1. In the address bar, go to: ``` chrome://settings/languages ``` 2. Under **Languages**, click **Add languages**. 3. Search for and add **only one** of the following, depending on your region: * **English (Australia)** → `en-AU` * **English (United States)** → `en-US` * **English (United Kingdom)** → `en-GB` **Remove unused languages** * Click the **⋯** next to any other languages and select **Remove**.\ This prevents Chrome from using fallback locales. **Set as display language** * Click the **⋯** next to your chosen language. * Select **Display Google Chrome in this language**. * Restart Chrome to apply the change. **Check your date/time format** * Open your system settings to make sure the region matches your browser locale: * **Windows:** `Settings > Time & language > Language & region` * **macOS:** `System Settings > General > Language & Region`

Microsoft Edge

**Open Language Settings** 1. Navigate to: ``` edge://settings/languages ``` 2. Click **Add languages** and add only one: * English (Australia) * English (United States) * English (United Kingdom) **Remove Extra Languages** * Click the **⋯** beside any other languages and choose **Remove**. **3. Set Display Language** * Click the **⋯** next to your chosen language. * Select **Display Microsoft Edge in this language** and restart Edge. **4. Match Your System Region** * Go to `Settings > Time & language > Language & region > Regional format` * Choose the same region: Australia, United States, or United Kingdom.

Then, confirm your browser's locale: 1. Open the browser console by pressing `F12`, then navigating to **Console.** 2. Run: ``` console.log(navigator.language); console.log(new Date().toLocaleString()); ``` 3. Expected outputs are as follows. | Region | navigator.language | Date rxample | Format | | -------------- | ------------------ | ----------------------- | ------------------------- | | Australia | `"en-AU"` | `09/10/2025, 13:30:00` | DD/MM/YYYY | | United States | `"en-US"` | `10/9/2025, 1:30:00 PM` | MM/DD/YYYY | | United Kingdom | `"en-GB"` | `09/10/2025, 13:30:00` | DD/MM/YYYY, 24-hour clock |
### Workflow inputs *Workflow inputs* in Rewst offer a flexible way to define specific inputs to a workflow via a form. This functionality allows you to handle various client cases and attributes dynamically. By understanding these concepts and utilizing the provided examples, you can create versatile and dynamic forms tailored to your specific needs. Below are some key aspects of workflow inputs: #### **Use org variables for client-specific workflows** If you have a form used across multiple clients, each with distinct environments like Microsoft 365 or On-Prem, you can use an [org variable](/documentation/integrations/organization-variables) to dictate the source of the data. For example, by employing `{{ ORG.VARIABLES.primary_identity_provider }}`, which is set per client as either `on_prem` or `azure_ad`, you can use the same form for both client cases. The form will be pulled from the relevant system.

#### **Hard-code attributes for efficiency** Instead of creating separate workflows for various attributes such as department, userPrincipalName, or ID, you can use a single workflow with a hard-coded element. This approach takes your input and returns the desired property. For example, **t**he attribute `department` can be hard-coded to allow a single workflow to handle different returned properties. Here's a Jinja code snippet for achieving this: {% code overflow="wrap" %} ```django {%- set attribute_collection = [] -%} {%- set my_attribute = CTX.attribute -%} {%- set my_data = CTX.data|selectattr(my_attribute) -%} {%- for user in my_data -%} {%- if user[my_attribute] or false -%} {%- set value=user[my_attribute] -%} {%- set tmp = attribute_collection.append({my_attribute:value}) -%} {%- endif -%} {%- endfor -%} {{- attribute_collection | unique(attribute=my_attribute) | sort(attribute=my_attribute) -}} ``` {% endcode %} ## Test a form: How to get a form's URL Recall that you can access all forms in your form list in Rewst. Understanding how to test a form can sometimes be confusing due to its intrinsic link to a workflow. To get the Form URL for testing directly from a workflow: 1. Locate the [trigger](/documentation/automations/intro-to-triggers) on the workflow. 2. Click **View URL**. 3. Select the desired organization's form from the list. 4. Click **Copy**. 5. Paste the URL into a new tab and launch. ## Restrict form drop-downs The onboarding form includes a number of fields to be filled out when onboarding new users. The default behavior of all the drop-down fields is to pull the list of options from the API. This is because the drop-down fields have **Dynamic Options** toggled on.

While this may work in many cases, there are scenarios where it makes sense to limit the number of options based on the customer segment you're working with. An example of this might be that you need to limit which email domains each customer sees. You may also want to limit which locations customers can choose from. In any case, you can set specific values for the `default_form` organization variables to use in your forms. {% hint style="info" %} The example below is specifically for the User Onboarding Form and workflow, as it is currently the most likely use case. {% endhint %} ## Add an organization variable to a form You can add default values for any of the form organization variables below: {% hint style="info" %} To view the form org variables table, [click here](/documentation/automations/forms/form-organizational-variables). {% endhint %} ## Limit the email domains in the user onboarding form #### Add the organization variable to an organization 1. Navigate to **Settings > Organization Variables**. 2. Click **Add** at the top right. 3. Enter in the following for the new organization variable: * **Name**: `form_default_email_domain` * **Value**: `["email domain"]` * **Category**: General * **Organization**: Choose Your Organization

{% hint style="danger" %} Any value you add to a variable must exist in the list that the form value is pulling from. An example of this would be that any email domain added as a default must exist in the list that is pulled from the Microsoft API. {% endhint %} Next, the variable can be added to the form field. # Options filter: Filtering in forms ## What is options filter? The *options filter* makes customizing fields within forms straightforward for those who want to add filtering without updating an options generator workflow. It takes inputs, filters them, and produces an output agnostic of the data source. Options filter works for the following form field types: * [Dropdown](https://docs.rewst.help/documentation/automations/forms/intro-to-forms#drop-down) * [Radio Button](https://docs.rewst.help/documentation/automations/forms/intro-to-forms#radio-buttons) * [Multi-Select](https://docs.rewst.help/documentation/automations/forms/intro-to-forms#multi-select) Option generators are still a fantastic option for those who need a more powerful, in-depth, solution. We cover what these are and how to use them in Cluck University's [Rewst Foundations](https://learn.rewst.io/creating-an-option-generator) . If you’ve already taken our courses and want a refresher, see our documentation on option generators [here](https://docs.rewst.help/documentation/workflows/workflow-generated-options). ## Options filter guidance * Modifying a form using the options filter will work for both parent and child organizations, as long as data formatting is set up the same way for both organizations. * Add as many conditions as desired. * Access the options filter feature in our standard form builder. * Options filter works in the context of the current organization. ## Practical uses for options filter * Say you offer 10 different types of licenses, but your users only ever use a single Business Premium type. Filtering down to just that license would simplify the list, and leave no room for error. * Using a multi-select form field, present multiple licenses to a user to be filtered down to a specific set of licenses. * Filter out admins from a total list of users, to create a cleaner list for copying into user onboarding. * When offboarding a user, you may want to exclude a list of specific people to prevent accidental offboarding of key individuals, like the CEO. * Hide on.microsoft email domains that are purely administrative, to provide a cleaner list. ### Detailed options filter example You work at an MSP and are building a license request form for technicians. Your customer, XYZ Corp, only purchases Microsoft 365 Business Premium licenses, not E3, E1, or other license types. To prevent techs from accidentally selecting the wrong license type, which would lead to support tickets and billing issues, you want the drop-down in your form to only show Business Premium.

Building the form with the different license types

What is seen after clicking **filter options**

Filtering using the **simple** logic option. The $.label equals Microsoft 365 Business Premium. Note that you haven't clicked **apply filter** on the bottom right, so there are still 4 filtered options shown under **Dropdown Options**.

What you see after you click **apply filter**. Now, there's only 1 filtered option: Microsoft 365 Business Premium

A preview of the form, or a preview of what the end user would see. Only one option would display.

## Options filter dialog Click **Filter Options** under the **Dynamic Options** submenu of the right side forms menu. This will open the **Create Option Filters** dialog. In the dialog, you’ll see two submenus: **Dropdown Options** and **Options Filter**.

### All Options The **All Options** drop-down selector holds all of the options which you’ve set in the standard form builder right side menu. Adding more options in that menu will populate those options into your drop-down selector.

The **Filtered Options** drop-down selector holds a list of your selected options after applying the filter. It acts as a preview for what to expect from your filtering.

If your form field uses a custom options filter, there will be a badge indicator in the top right of the field.

#### The JSON interface Toggle from the default **Simple** view to the **JSON** view. This will switch to show the code of the filter. You may have a scenario where your desired filter is more complex than just label and value, such as ID. Using this code editor, filter out custom objects from complex queries.

#### Jinja for options filters If you manage many organizations, use Jinja in options filters to scale filtering logic without manually configuring filters for every suborganization. When simple boolean logic operators feel limiting, go straight to Jinja for greater customization. {% hint style="info" %} The CTX variable you want to reference will always be called `options`. {% endhint %}

### AND and OR conditional options filtering {% hint style="info" %} Using the options filter for forms will require a basic understanding of Boolean. If you’re new to the topic, be sure to complete our Clean Automation course in Cluck University before trying out this feature. {% endhint %} The options filter works off of two boolean operators, which are used to build queries for a variety of filtering situations. 1. **AND** sets that all conditions must be true to be filtered into the returned result. E.g., Red AND white would count only items with both those characteristics. 2. **OR** sets that either of several conditions can be true to be filtered into the return result E.g., Red OR white would count items with either of those characteristics.

Click **X** to the right of any added rule or group to delete it from your options filter list. Click **+Rule** to add a filter field, which is customizable by a list of parameters. Choose from either **$.value** or **$.label**, then choose from the long drop-down list of conditions. E.g., **$.value equals `15`** would filter all results with a value of exactly 15.

In Boolean logic, a *group* refers to a set of terms or expressions that are treated as a single unit by using parentheses, allowing you to perform Boolean operations on them together. Essentially, it defines the order of operations by grouping certain elements within a complex logical statement. When you want to combine multiple Boolean operations in a specific way, you enclose them within parentheses to indicate that these operations should be calculated first. By grouping terms, you can control the order in which Boolean operators like AND and OR are applied. Use the +**Group** button to define your conditions more precisely. For example: * Without grouping, A OR B AND C would be evaluated as: A OR (B AND C) due to precedence rules * With grouping, (A OR B) AND C forces OR to be evaluated before AND. ## Forms and options filter ### Use the options filter in a form 1. Navigate to **Automations > Assets > Forms > + Add**. 2. Name your form, and click **Submit**. 3. Drag one of the three applicable form fields onto the form builder canvas. Remember, options filter is only available for Radio Buttons, Dropdown, and Multi-Select. 4. Click on the dragged form field to open the right side menu. 5. Click on **Filter Options**. This will open the **Create Option Filters** dialog.

6. Set up your desired filters using the AND and OR options, with relevant use of the **+Rule** and **+Group** buttons. 7. Click **apply filter** at the bottom right of your screen. 8. Click **Close** when finished. The option filter will automatically save and be applied to your form. Note that you’ll still need to click **Save** at the top right of your form builder screen to update these changes within your form. ![](/files/aw2tNK5lIrXnJiQCSI7W) ### Options filter and syncing of forms The greatest advantage of the options filter is that it allows for the overriding of a form. Synchronized forms will block you from modifying attributes to prevent sync malfunction, by default. Under filter options in the form builder, you’ll find an **Override** button at the bottom right. Clicking will override this individual filter. Note that if you have multiple filters, and want to modify all of them, you’ll need to click **Override** for each filter.

### Org-based preview and org-specific instances Use the org context drop-down selector to choose the child organization that you'd like to preview, and see how the form will function for that specific organization. Previews don't require cloning, and won't affect the saved form configurations except for the options filter. The options generator will display data as if the form were triggered in just that specific organization. The default-set options filter will be used if no custom filters were provided for the selected organization. Click the drop-down selector to view and chose from your list of all total organizations.

Selecting the preview organization sets the context of the form builder. and opening the preview dialog will use that organization's context to generate the correct preview, tailoring filtering logic for each instance without duplicating forms or unsyncing fields. {% hint style="info" %} By default, a field will inherit the parent organization's filter unless if it explicitly overridden.
{% endhint %} # Embed a form into an iFrame ### Embed forms There is often a need to embed a form in an iframe to give users the ability to complete a form and trigger automation. The form can be embedded into other web pages that use iFrame links. {% hint style="success" %} To get the dynamic form URL, make sure your form is already set up as a trigger for a workflow. {% endhint %} ### Get an embeddable link Follow these steps to get the embeddable link: 1. Navigate to **Automations > Workflows**. 2. Click on the Workflow that includes the form trigger to open it in the Workflow Builder. 3. Click on the trigger to open its settings in the right side menu. 4. Click **Copy URL**. 5. Click **<>** **Copy Embeddable iFrame code**. This copies the embeddable Iframe code. Paste the code into your compatible webpage editor.

# Clone an existing form There may be times when you want to take an existing form and make slight modifications to apply it to another use case. For example, you may be using the Client: New Employee workflow to onboard new users, and want to have two different forms: 1. One for when you hire internal users at your organization 2. One for adding users for your customers ### How to clone and edit a form 1. Navigate to **Automations > Assets > Forms**. 2. Click **⋮** and select the **Clone** option on the form you want to clone.

3. Rename your form to something unique and define a few other fields: * **New Name**: the new name of the cloned form, make sure this is something unique and describes the use case for the form. * **Organization**: the organization that the form will reside under. * This doesn’t necessarily mean that you want to select the customer that the form will be for. The best practice is to have the form live at the top-level organization. The customers are tied to the relevant form by a trigger in the workflow. More information can be found in the Intro to Triggers article. 4. Click the **Clone** button to see your cloned form.

## Shallow clone a form *Shallow cloning* is a feature of the Rewst platform that allows you to create a copy of an existing workflow or form. This is useful if you have a workflow that is very similar to another workflow, but which requires a few small changes. Standard cloning copies the entire resource *pack—* workflow, forms, templates, triggers, etc— and when cloning into your own org, you end up with multiple duplicates of the same resource. Shallow cloning copies that single selected resource, but re-uses all of the dependencies that it has. If you have a sub-workflow that's part of a main workflow, and you shallow clone that sub-workflow, you will end up with a copy of the sub-workflow. This lets you make changes to the sub-workflow without affecting the original workflow. There is no difference between the steps to clone or shallow clone a resource. Rewst will automatically detect if you are cloning something into your own org. If so, the platform will shallow clone it instead. Note that this removes the **Synchronize** button on the dialog, and instead shows a text to explain. # Conditional fields You'll often have forms that you want to use across a multitude of clients, but sometimes fields may not be relevant to them all. Rewst has *conditional fields* that can be used to determine whether you show another field. ## Conditional field example In our example, we will look at the **Supervisor** field when creating a new user. In the image below, no Supervisor is set, and therefore the following field is another drop-down for further information.

You can then see that if we add content to that supervisor drop-down, which is a list of users pulled dynamically from Microsoft365, a new field appears.

This boolean field is then checked on, which gives access to another relevant field.

Rather than giving fields to a user that bear no relevance, you only give them fields they must fill in. These conditional fields are set by clicking the field on the form and clicking **Set Conditional Field**, which presents you with the below.

## Jinja for field conditions in forms There are times where you may need to use criteria for a form condition that is not accounted for by the available drop-down selections, such as when organization information or organization variables are part of the criteria. At these times, you might instead opt to use a Jinja condition, such as `{{ ORG.VARIABLES.variable_name == "value" }}`. Another case where the use of Jinja may be required is when multiple conditions need to be met, even if those conditions are normally available in the drop-down selections. An example of this would be `{{ (CTX.field_name_1 == "value_1") and (CTX.last_name != "value_2") }}` . # Troubleshoot unpacked Crate forms {% hint style="info" %} For more information on unpacking Crates, see our Crate documentation [here](https://docs.rewst.help/prebuilt-automations/crates#unpack-a-crate). {% endhint %} If a form field of a form unpacked from a Crate isn't populating with information, you have two options. 1. Identify the issue by digging into the form. 2. Open a support ticket with Rewst's support team and have them troubleshoot the issue for you. Either option will require you to collect information from the form by completing the following steps. As an example, we're using the **\[Rewst Master v3] User Onboarding Minimalistic** form. 1. Navigate to **Automations > Assets > Forms**. 2. Open the form in question. 3. Scroll down in the right side menu. Click on any field that's further down in the field list. 4. Click on the field. This will open its information in the right side menu.

The view of an expanded form field, open for editing

5. Scroll down to see if the field is a dynamic field. If it is, **Dynamic Options** will be toggled **on**. 6. Confirm if the field has **Workflow Generated** toggled **on**. If so, look at the options generator in the **Workflow** field beneath it. 7. Open the options generator by clicking ![](/files/klgauGlRlsON2g7gZPtW). 8. Click **View results for workflow**.\ \

9. View the list of all times the workflow has run. Errors will be denoted by **Failed**.\

10. Click on failed execution rows to see more information. 11. Click on any of the failed actions in the list at the bottom of the page to examine its **Workflow Execution** log. 1. If troubleshooting the issue yourself, find the errors in the workflow execution and correct them. 2. If creating a ticket for Rewst support, copy the URL of your browser while viewing this information, and paste it into your support ticket. 3. You can also ask [RoboRewsty](/documentation/roborewsty) to help you troubleshoot your execution results.

Click on ... under errors to expand error information

# Form organization variables Form [organization variables](/documentation/integrations/organization-variables) are implemented with specific forms that come from Crates. They can be used to set form\_org\_vars so that you can have specific default values for fields on a form.

Variable Name	Description	Valid Values
form_default_supervisor	Used so that if the form forces a default, this is the value supplied in the if statement	string
form_default_orgunit	Used so that if the form forces a default, this is the value supplied in the if statement. Example is [{"id": "fb53fb9f-208f-451c-9391-6092eb7c4e1b","label":"OU=Disabled Users,OU=Pedro Users,OU=Pedro Ltd,DC=ad2,DC=pedroaviary,DC=com"}]	list
form_default_location	Used so that if the form forces a default, this is the value supplied in the if statement	string
form_default_email_domain	Used so that if the form forces a default via workflow input, this is the value supplied in the if statement	string
form_default_selection_email_domain	Will return the domain specified as the default selection for the workflow [Rewst Master v2] M365: List Email Domains-Actual	string
form_default_licence_sku	Used so that if the form forces a default, this is the value supplied in the if statement	list
form_default_aad_groups	Used so that if the form forces a default, this is the value supplied in the if statement. Example is [{"id": "68c2878a-6739-438c-bf5a-d8c2bea39573","label": "AAD Group One"},{"id": "936eb764-36c4-4ac6-b264-c532caeb217c","label": "Group Me Up Buttercup - Group"}]	list
form_default_distribution_aad_groups	Used so that if the form forces a default, this is the value supplied in the if statement. Example is [{"id": "68c2878a-6739-438c-bf5a-d8c2bea39573","label": "Dist Group Two"},{"id": "936eb764-36c4-4ac6-b264-c532caeb217c","label": "Group Me Up Buttercup - Distribution"}]	list
form_default_onprem_groups	Used so that if the form forces a default, this is the value supplied in the if statement. Example is [{"id": "68c2878a-6739-438c-bf5a-d8c2bea39573","label": "Local AD Group One"},{"id": "936eb764-36c4-4ac6-b264-c532caeb217c","label": "Another Local AD Group"}]	list
form_default_security_aad_groups	Used so that if the form forces a default, this is the value supplied in the if statement. Example is [{"id": "68c2878a-6739-438c-bf5a-d8c2bea39573","label": "Security Group One"},{"id": "936eb764-36c4-4ac6-b264-c532caeb217c","label": "Security Group Two"}]	list
form_default_department	Used so that if the form forces a default, this is the value supplied in the if statement. Example is [{"department": "HR"},{"department": "Finance"}]	list
form_default_phone_number	Used in the workflow itself that if the org var is specified, it'll use it if none on the form	string

# Templates and scripts {% hint style="info" %} Templates and scripts are similar features in Rewst, though each is intended for a different purpose. Once created, they're separated by type into two sections in the platform for ease of organization and sorting. Both can be referenced in workflows. {% endhint %} ## What is a template? *Templates* are used to create a standardized set of text used in several places in Rewst. For example, if you want to create a ticket and always use the same HTML for the ticket description, you would create a template. In the input, you would reference the template instead of having to type that same text each time. To access templates, navigate to **Automations > Assets > Templates** in the left side menu of your Rewst platform. Write templates in either Markdown or HTML language. Common examples of templates include: Jinja templates * Data transformations - Manipulating and formatting data between workflow tasks * Dynamic field values - Creating dynamic inputs for action parameters * Conditional logic - Building expressions for transitions and decision-making * Text/message generation - Formatting emails, tickets, notifications, etc. * List/dictionary comprehensions - Processing collections of data Workflow templates * Task configurations and parameters * Transition logic between tasks * Error handling patterns * Sub-workflow integration * With-items (loop) configurations Trigger configuration templates * Webhook triggers * Scheduled/cron triggers * Integration-specific triggers - e.g., ticket creation, form submission App Builder templates * Component configurations * Data binding expressions * Workflow integrations for apps

Screenshot of the Templates list view in the Rewst Automations section, showing a dark-themed interface with a left navigation menu, a top search bar and Create Template button, and a table of templates with names, descriptions, dates, attributes, and action icons.

Write templates in either Markdown or HTML language. ### Create a template 1. Click **+ Create**. 2. Fill in the relevant fields with the information for your template. 1. **Name** 2. **Description** 3. **Tags** 3. Select the language you want to write your template in from the **Language** drop-down selector. 4. Click into your **Editor** panel on the left side of the screen to begin writing. View your progress in the **Preview** panel. 5. Scroll down and click **Submit** when finished.

An example of an in-progress template, written in Markdown

## What is a script? *Scripts* in Rewst enable you to write scripts in a straightforward and accessible manner compared to traditional programming languages. Scripting tasks can range from batch processes on a local computer to generating dynamic web pages on a web server. Scripts can be written, edited, and executed more quickly and easily than software programs. To access scripts, navigate to **Automations > Scripts** in the left side menu of your Rewst platform. Write Rewst scripts in any of the following languages: PowerShell, Python, YALM, Jinja. All scripts are assigned a unique URL (GUID).

Screenshot of the Scripts list view in the Rewst Automations section, showing a dark-themed interface with a left navigation menu, a top search bar and Create Template button, and a table of scripts with names, descriptions, dates, attributes, and action icons.

Write Rewst scripts in any of the following languages: PowerShell, Python, YALM, Jinja. ### Create a script 1. Click **+ Create**. 2. Fill in the relevant fields with the information for your script. 1. **Name** 2. **Description** 3. **Tags** 3. Select the language you want to write your script in from the **Language** drop-down selector. 4. Click into your **Text** panel to begin writing. 5. Scroll down and click **Submit** when finished.

## Jinja: Use templates and scripts within workflows While templates and scripts are written in HTML or Markdown, they can accept small elements of Jinja to set up their elsewhere in Rewst. They allow for context variables to be set within them, which can then be referenced in workflows to allow the eventual sent message to populate with dynamic information. In the example below, you're sending an e-mail to a new user that has been created. ```django Hi {{ CTX.first_name }}, Welcome to Rewst! Your email account has been provisioned and you should be able to access it at: https://outlook.office.com/mail/ username: {{ CTX.email }} password: {{ CTX.password }} We're excited to have you on the team! ``` In the input for the `Send Mail` action, you would enter `{{ template("")}}` into the action's **Message** field instead of typing out the intended message manually. This would pull your pre-written template into the body of the email when it is sent.

The template ID or script ID can be taken from the URL, when editing. As an example, let's look at the URL below.

The part of the URL underlined in yellow is the template ID. For this particular ID, your Jinja would read as `{{ template("768f5d45-5fe7-4c1f-b2c1-932dcbdcb1d7") }}`. ## Export and import templates and scripts You can export a template or script to share with other Rewst customers, or create your own hard copies of template and script backups. To export a template or script as a JSON bundle, ![](/files/6iNRi02bpc2y30rldVl1)next to your relevant template or script in its total list. To import a template or script bundled as a JSON file, click ![](/files/pSRxSYvjj8rtjxgRxLTC) in the top right navigation bar of the list page. Then, drag and drop your file into the upload dialog that appears. # Actions ## What is an action? *Actions* are the operations available for creating and automating, which live inside of a [workflow](/documentation/automations/workflows). You grab these actions from the left side library menu of the workflow builder, and drag them onto the Workflow Builder Canvas. When you run a workflow, Rewst is completing a series of actions specified within that workflow. Once you've set up an [integration](https://docs.rewst.help/documentation/integrations), 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 library 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](https://docs.rewst.help/documentation/workflows). {% hint style="success" %} Click through to any of the related action type pages to learn more. {% endhint %} Each action has a set of configuration options within it, editable in its right side menu of the Workflow Builder once dragged onto the Canvas. Learn more about settings for tasks [here](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow#configure-tasks) in our workflow documentation. ### Core actions These are the essential platform components like webhooks, email dispatching, and [noops](https://docs.rewst.help/documentation/workflows/actions-in-rewst/core-actions#no-operation-noop). {% content-ref url="/pages/ItLAL7BSFZkafcQPS6S6" %} [Core actions](/documentation/automations/actions-in-rewst/core-actions) {% endcontent-ref %} ### 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. See our [individual integration setup pages](/documentation/integrations) for more information on available actions. {% content-ref url="/pages/OSnkx0SEHcbueeC19adV" %} [Integrations](/documentation/integrations) {% endcontent-ref %} ### 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. {% content-ref url="/pages/5tKhys9AyA11Caej1cal" %} [Rewst actions](/documentation/automations/actions-in-rewst/rewst-actions) {% endcontent-ref %} ### Transform actions These actions help you shape and modify your data for efficient workflow execution, replacing the need for complex Jinja statements. {% content-ref url="/pages/wzApPvhqXx0qV57qBEbb" %} [Transform actions](/documentation/automations/actions-in-rewst/transform-actions) {% endcontent-ref %} ### 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. {% content-ref url="/pages/vIgZWGeoD6JWH1YqyITR" %} [Workflows actions](/documentation/automations/actions-in-rewst/workflows-actions) {% endcontent-ref %} ### Generic actions For each integration, Rewst provides a single action that isn't predefined like the other integration-related actions, but which can be used to define a URL path. Using that path for the endpoint you wish to reach in the partner's API allows you to specify data, cookies, headers, etc., for custom targeting beyond what Rewst's other predefined actions allow. Generic actions rely heavily on your reading the integration's API documentation and researching the endpoints yourself. Most frequently, we suggest this as a feature for more advanced users, though customers with specific goals might be required to use it early on in their onboarding process. Generic actions are typically named after the integration in the format of `[integration] API Request`. For example, for HaloPSA the action is called `HaloPSA API Request` .

{% hint style="warning" %} Note that the paginate request option in any generic action modifies how the request is formed. This can cause issues on the API's side, causing them to behave unexpectedly and return error messages. If your integration is missing a generic action and you'd like to see us develop one, add that feedback to our [Canny feedback collector.](https://rewst.canny.io/integrations) {% endhint %} ## Action version updates {% hint style="info" %} Note that this action version functionality won't appear for any actions related to your custom integrations. {% endhint %} From time to time, Rewst will make updates to existing actions. These updates may require customers who are using those actions in their workflows to make modifications or adjustments. View the changelog of an action's version history in the left side action list of the [Workflow Builder.](/documentation/automations/workflows/workflow-builder-how-to-set-up-a-workflow) If the action in the action list has logged changes, an icon will appear to the right of its name in the list. Click on that icon to expand the version history log.

### Action version log status and alert meanings | Label | Color | Meaning | | ---------------- | ------ | -------------------------------------------------------------------------------- | | Action Required | Red | One or more actions have breaking changes | | Attention Needed | Yellow | Actions need review, but aren't breaking | | Updated | Blue | Actions have been updated - no action is required and the alert is informational |

Click links in the action changelog to view additional
documentation or guides.

You'll see a red pulsing dot to the right of the **Workflows** section of your left side menu when there are unread breaking changes.\ ![](/files/yORL9vVaUAicn7BiuDwJ) When workflows in your current organization are affected by version changes, a toolbar will appear in your workflows list page with up to three buttons, each containing the total count of actions in the organization that fall into each alert category. A red pulsing dot will be present next to the Attention Needed category when unread breaking changes exist. Click on any of the categories in the toolbar to filter your workflows list to just that group of workflows. These statuses also apply to the **Attributes** column's filtering capabilities.

## 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. {% hint style="success" %} Click on any of the issues below to expand and see its solution or information. {% endhint %}

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](https://support.brave.com/hc/en-us/articles/360023646212-How-do-I-configure-global-and-site-specific-Shields-settings), 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](https://docs.rewst.help/security/security-policy), but it's something to consider if you run into any issues. Additional steps for whitelisting in ThreatLocker are outlined in this linked document.

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.\ \ ![](/files/QLjIa4WtEswk7o8wEdLH) {% hint style="info" %} 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. {% endhint %}

# Core actions *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. 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. {% hint style="info" %} Expand each of the action types below to see their individual information. Actions are listed alphabetically in both this doc and the Rewst platform. {% endhint %}

Await Webhook Request action

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. * To access the results of a webhook, publish a [data alias](/documentation/automations/workflows/data-aliases) with a value of `{/{ RESULT }/}.` You cannot merely publish the results as or use task.

Compare Strings Set Ratio action

This action calculates the ratio of how many words from the smaller string are found in the larger string. It's designed for measuring string similarity based on word overlap rather than character-by-character comparison. This action is particularly useful when you need to determine how similar two text strings are based on shared words, making it ideal for scenarios where exact string matching is too strict but you still need to measure content similarity. **Use Cases**: * Fuzzy matching between text strings * Duplicate detection in datasets * Content similarity analysis * Partial string matching scenarios **Parameters**: * **original\_string** (required): The original string to compare * **comparison\_string** (required): The comparison string that is being compared to **Output**: Returns an integer representing the ratio of word overlap between the two strings. Higher values indicate greater similarity.

Confirmation Email action

Send a confirmation email with reply options to a specified recipient.\ This action pauses the workflow and places it in an `Awaiting-User-Input` state. The workflow will not proceed until the confirmation email is interacted with via buttons, or the task times out. You can configure task timeout on the **Advanced** tab of the action. Task time out means that the action fails. Note that this setup means that buttons are required for the workflow to proceed.\ \ ![](/files/01UmlKilcZMFQ7QNBFf5) * **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`). * The parameters have several optional settings: * Custom Button CSS - Custom CSS to be applied to the buttons * Custom Footer - Custom footer to be displayed in the email. If not provided, this will default to the Rewst footer unless the footer is set to be removed. * Custom Title CSS - Custom CSS to be applied to the title * Logo Link - URL to go to if the logo is clicked. If not provided, this will default to [https://rewst.io](https://rewst.io/) * Logo URI - String value URI of the logo to be displayed in the email. If not provided, this will default to the Rewst logo image. This is essentially providing a value for the src param of a img tag. You could also provide a base64 encoded value. The file format for your hosted file will need to follow the guidance for your particular email client, which is independent of Rewst. For example, Outlook does not accept PNG formatted files. For broader guidance for all email clients, we recommend using this resource called [caniemail](https://www.caniemail.com/features/). * Remove Footer - Removes the Rewst footer from the email * Render Markdown - Renders markdown as HTML when set to **True** * **Output:** If the action is correctly executed, a confirmation email will be sent. Output variable `inquiry_result` is an output of the task and can be used to route the workflow in a specific path. `Inquiry_result` 's value is that of the button clicked, and is configured as a string value on the action itself in the workflow builder.

* **Confirmation email class and confirmation examples** * Button classes: * Primary; primary * Default; default * Danger; danger * Title class: * Title; title * **Example custom button CSS** ```css a, a:visited, a:hover, a:active { color: inherit !important; } table, td, div, h1, p { font-family: "Times New Roman", Times, serif; } .primary { background: #4d7c0f; } .default { background: #365314; } .danger { background: #dc2626; } ``` * **Example custom footer** ```

Order

Need Delivery?

``` * **Example custom title CSS** ``` .title { font-size: 20px; line-height: 16px; font-weight: 700; font-style: normal; color: #0c0a09; text-decoration: none; letter-spacing: 0px; padding: 25px 30px 0 30px; } ``` * **Example logo link** ``` https://google.com ``` * **Example logo URI** ``` https://www.svgrepo.com/download/533811/donuts-cake.svg ```

Create Pending Task action

This action creates a pending task that pauses workflow execution and requires manual intervention through the Rewst UI. It's designed for scenarios where human approval, confirmation, or decision-making is needed within an automated workflow. **Use Cases**: * Manual approval workflows * User confirmation before critical actions * Decision points requiring human judgment * Interactive workflow processes * Quality control checkpoints **Parameters**: * **message** (required): The message to display in the pending task that explains what action is needed from the user * **buttons** (required): An array of button objects that users can click to respond. Each button has: * **label**: The text displayed on the button * **style**: Visual style (`default`, `primary`, `danger`) * **value**: The value returned when the button is clicked **Output**: The workflow pauses at this task until a user interacts with it via the Rewst UI. When a button is clicked, the action returns the corresponding button value, allowing the workflow to continue based on the user's choice. This action is essential for creating interactive workflows that require human oversight or decision-making at specific points in the automation process.

Create Webhook action

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.

Debug action

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. **Use cases** 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: ```yaml 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: **Output:** ```json { "template": "# Hey there Rewsty", "text": "Testing Debug Action" } ``` This tells us that `CTX.name` was set to`Rewsty`, 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.

DNS Query action

Queries a nameserver for DNS records associated with a given URL. * **Parameters:** The URL to query the Nameserver for, the field to query from the nameserver, timeout for the DNS Query (optional, default 60), and the nameserver to use for the query (several options available including Google, Cloudflare, OpenDNS). * **Output:** The specified DNS records associated with the given URL from the queried nameserver.

Generate Password V2 action

An upgrade from the deprecated password generation action. It crafts a cryptographically secure password with user-specified values. (*This is recommended for use over the deprecated Password Action due to its upgraded structure.)* * **Parameters:** length, minimum counts of numeric and capital letter characters, and optional punctuation characters. * **Output:** the generated password is presented under the "password" key in the output.

HTTP Request action

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. {% hint style="info" %} *In most cases, we recommend that you use a* [*Custom Integration*](/documentation/integrations/custom-integrations) *instead of this HTTP Request action. This allows for enhanced security and customization when interacting with your external APIs. The* HTTP Request action will require building out all endpoints as individual actions/subworkflows. It is only recommended for when Custom Integration is not possible or repeatedly fails. {% endhint %} **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.

Delay Workflow For Period action

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 action

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 action

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. **Use cases** 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: ```json { "name": "Rewsty", "valid": true, "message": "Successfully completed the task." } ``` You can simulate this response using the `Mock` action as follows: ```yaml 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: **Output:** ```json { "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.

No-Operation (Noop) action

A noop action does nothing. It's often used for logic or as a placeholder in the workflow. * **Parameters:** None. * **Output:** None

Parse HTML action

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. **Use cases** 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](https://www.crummy.com/software/BeautifulSoup/bs4/doc/#kinds-of-filters) to specify the operation type: * `find_all` returns all instances of the defined HTML tag. * `find` returns only the first instance of the defined HTML tag. * `select` enables the use of CSS selectors for nested HTML tags. * **String**: Optionally searches for specific text within the HTML content. * **Value**: Identifies the tag or selector to search for in the HTML content. For example, `a` would find all anchor (``) tags in the HTML content. **Practical Use Case: Extracting Links from 'Hacker News'** This example involves making a `GET` request to the `Hacker News` website and parsing the returned HTML to extract all `` links. The first step uses the Core `HTTP Request` action to fetch the HTML content: ```yaml publish_result_as: news request_method: GET URL: https://news.ycombinator.com ``` You can then use the `Parse HTML` action to extract all `` links. The parameters for this action would be set as follows: ```yaml html: {{ CTX.news }} style: find_all value: a ``` **Example Workflow Results** Here's an example of how the `Parse HTML` action's input and output might look like on the workflow results page: **Input from the HTTP Request:** ```json html: { cookies: {}, data: "...", headers: {...}, status_code: 200 }, query: { style: "find_all", value: "a" } ``` **Result:** ```yaml [ "

", "Hacker News", "new", "past", "comments", "ask", "show", "jobs", "submit", "login" ] ``` This result contains all `` tags found in the HTML content. To further refine this output, returning only links for externally referenced pages, use the `select` query style, along with advanced CSS filters: ```yaml html: {{ CTX.news }}, style: select value: .titleline a[href^='https://'] ``` The result is a list of strings containing all `` tags that meet the newly specified criteria: ```json [ "Electronic Structure of LK-99", "A room-temperature superconductor? New developments", "Epicycle Clock", "Emacs is my new window manager", "Splitting the Web", "Unconfirmed video showing potential LK-99 sample exhibiting the Meissner effect", "Show HN: Magic Loops – Combine LLMs and code to create simple automations", "eGPU: A 750 MHz Class Soft GPGPU for FPGA" ] ``` To further understand CSS selectors, you can refer to this [w3schools article](https://www.w3schools.com/cssref/css_selectors.php). ***Tip**: Parse HTML's functionalities include finding elements by tags (`

`), class (`class_="abc"`), text (`string="The content"`), or id (`{"id": "abc"}`). When `string` is the sole argument, only the text is returned, not the whole element, which can help you fine-tune data extraction.*

Parse XML action

The Core Parse XML action in Rewst is designed to locate and extract specific elements or data from XML documents. This powerful tool, backed by an efficient Python library, facilitates precise data extraction from XML files, simplifying the process of parsing complex data structures. For additional understanding on XPath expressions, refer to this [w3schools article](https://www.w3schools.com/xml/xpath_intro.asp). **Use cases** Consider using the Parse XML action in these scenarios: * **Data Extraction and Content Clean-Up:** Capture specific information or filter out necessary data from XML-formatted content. This is particularly useful in processing responses from HTTP requests or handling complex XML documents. * **Web Scraping:** Automate the extraction of specific information from various XML sources using defined tags, attributes, or identifiers. It enables you to precisely target the data you need from web resources. **Action parameters** The Core Parse XML action requires the following parameters: * **XML**: The XML content that needs to be parsed. This could be XML content from an API response, obtained using the HTTP Request Core Action. * **Attributes**: (Optional) Allows you to find XML elements based on their attribute key. * **ID**: (Optional) Permits searching for XML elements based on their ID attribute. * **Selector**: Determines the operation type. Options include: * `find`: Returns only the first instance of the defined XML tag. * `find_all`: Returns all instances of the defined XML tag. * `select`: Enables the use of XPath expressions for nested XML tags or conditional searches. * **String**: (Optional) Allows you to search for specific text within the XML content. * **Value**: Specifies the tag or selector to search for in the XML content. **Practical Use Case: Extracting Books from a Bookstore's XML Data** Before diving into parsing XML data, you'll need to fetch the XML file. In this use case, the XML file is fetched from a public URL which contains bookstore data in XML format. The first task in the workflow, called `get_books`, uses the Core `HTTP Request` action to fetch this XML content: **Input parameters:** ```yaml url: http://books.toscrape.com/catalogue/category/books_1/index.html request_method: GET publish_result_as: get_books ``` The result from this task will look something like this: ```json { "cookies": {}, "data": "...", "headers": {...}, "status_code": 200 } ``` The `data` field contains the XML content, which is the input for the `Parse XML` action. The XML content is passed using the Context (`CTX`) object as `CTX.books.data`. **Finding the first book** In this scenario, we are using the `find` operation to return the first `book` element in the XML: **Input parameters:** ```yaml input: xml: {{CTX.books.data}} selector: find value: book ``` The result from this task will look something like this: ```json { "value": "Everyday ItalianGiada De Laurentiis200530.00" } ``` The output includes the first `book` element in the XML content. **Selecting all 'Children' category books** For a more complex operation, we can use the `select` operation with an XPath expression to extract all `book` tags where the `category` attribute is `children`. **Input parameters:** ```yaml xml: {{CTX.books.data}} selector: select value: book[category='children'] ``` **Result:** ```json { "value": "Harry PotterJ K. Rowling200529.99" } ``` The result includes all `book` tags where the `category` attribute is `children`.

Send Mail action

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`). You can also fully control the HTML of the email with `(Custom HTML)`. This can also reference a template using the `{{ template(“guid”) }}` function. * Note that if you're using the `Custom HTML` field, the message and title fields will be ignored.\ ![](/files/ccHxROlrGVVulBJRudAN) * You cannot upload images to Rewst, so any image will need to be externally referenced via URL. The file format will need to follow the guidance for your particular email client, which is independent of Rewst. For example, Outlook does not accept PNG formatted files. For broader guidance for all email clients, we recommend using this resource called [caniemail](https://www.caniemail.com/features/). * Emails will still be sent from the rewst.io domain. * **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 action

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. All phone numbers must be provided using the E.164 international format, which includes the country code. Improperly formatted numbers may result in validation errors or delivery failures. Example: `+14155552671` * **Output**: The output of this action will depend on the implementation details. Usually, it will return a confirmation message or an error message. **Sending number origin** The `core_send_sms` action sends messages from a US-based phone number owned and managed by Rewst. Due to this setup: * SMS delivery is most reliable for United States phone numbers * Some international carriers restrict or block messages originating from US long-code numbers * Certain countries require locally registered sender IDs or approved messaging routes These limitations are imposed by telecommunications carriers and regional messaging regulations. **When to use your own messaging account** If you need to send SMS messages to a region that is not supported by the shared Rewst sending number, you can set up your own messaging account and use it through Rewst’s [Twilio integration](/documentation/integrations/integration-guides/twilio-integration-setup). Using your own account allows you to: * Purchase local phone numbers in supported countries * Configure which countries your numbers can send messages to * Register country-specific sender IDs * Meet regional compliance requirements **Delivery behavior** When the `core_send_sms` action is executed, it returns the **current delivery status** for the message. This status reflects the system's understanding of the message state after it has been sent to the carrier networks. Even when a message is reported as sent, final delivery still depends on external telecom carrier networks and the recipient device. Because SMS delivery involves multiple third-party carriers, failures may still occur due to: * Carrier filtering * Regional messaging restrictions * Unreachable devices * Network congestion * Recipient opt-outs **Common SMS error responses** * SMS service is temporarily unavailable, please try again later * Invalid phone number format * SMS cannot be sent to this region - geographic permissions not enabled * This recipient has opted out of receiving messages * SMS cannot be delivered to this number due to carrier or regional restrictions * This number is a landline and cannot receive SMS messages * The phone is currently unreachable (switched off or no signal) * This phone number is unknown or may no longer exist * This number cannot receive SMS messages (likely a landline or unsupported carrier) * Network congestion - please try again in a few minutes **Error scenario: Carrier or regional restrictions** This situation occurs when the destination carrier or region doesn't allow messages from the sending number. Possible causes include: * Sender ID restrictions in the destination country – Some countries limit which numbers, shortcodes, or alphanumeric sender IDs can be used. * Sender ID restrictions on the destination network – Certain networks may block messages from shortcodes or restrict MMS messages from longcodes that originate outside the country. * Alphanumeric sender IDs – If you are using an alphanumeric sender ID, the destination country must support it, and some countries may require pre-registration. * Number formatting – The “To” or “From” number may not be in the proper international format (E.164). Check that numbers are correctly formatted. * Destinations with no connectivity – Some carriers or regions may not have messaging routes available for your sending number. * This error is more common when sending international messages from a US-based number. If you need to reliably reach a destination with restrictions, consider using your own messaging account via the Twilio integration, where you can configure allowed countries, local numbers, and sender IDs. **Error scenario: Messaging geo-permissions disabled** This situation occurs when an SMS or MMS message is sent to a country or region that the Rewst-managed sending number is not authorized to send messages to. Possible causes: * The destination country is not included in the allowed countries for the Rewst sending number * The region is not supported for SMS delivery from the Rewst-managed sending number * Messaging to that region is restricted by telecom regulations * If you need to send messages to a country that is not supported, consider using your own Twilio account via the Twilio integration, where you can configure allowed countries and sender IDs. **Error scenario: Recipient has opted out** The recipient has opted out of receiving messages from the sending number. **Error scenario: Landline number** The destination phone number is a landline and cannot receive SMS messages. **Error scenario: Phone unreachable** The destination device cannot currently be reached. Retrying later may resolve the issue. Possible causes: * Device powered off * No cellular signal * Temporary carrier network issues **Error scenario: Unknown or unreachable numbers** The destination number may not exist, cannot receive SMS, or is otherwise unreachable due to carrier restrictions. **Error scenario: Network congestion** The carrier network is currently congested. Retrying the message later may resolve the issue.

Test All Parameter Types action

This action serves as a comprehensive example and testing tool that showcases all the different input field types that can be used in Rewst actions. It's primarily used for: * UI testing and validation * Demonstrating parameter field capabilities * Training and educational purposes * Testing form rendering and validation **Inputs** The task accepts a wide variety of input parameters representing every field type available in Rewst: **Basic fields:** * `simple_string` (required) - Basic text input * `optional_string` - Optional text field * `string_with_default` - Text with default value "default\_value" * `simple_integer` (required) - Whole number (default: 42) * `simple_number` - Decimal number (default: 3.14) * `simple_boolean` - Toggle switch (default: false) * `required_boolean` (required) - Required toggle **Advanced string fields:** * `string_enum` (required) - Dropdown with options (option\_1, option\_2, option\_3) * `string_enum_objects` - Dropdown with custom labels and descriptions * `radio_selection` (required) - Radio button group * `secret_string` - Password/masked field * `multiline_text` - Large text area * `textarea_content` - Code editor area **Date/Time fields:** * `date_field` - Date picker * `time_field` - Time picker * `datetime_field` - Date and time picker **Array fields:** * `simple_array` - Array of strings * `array_with_enum` - Multi-select dropdown * `array_of_objects` - List of complex objects with name, enabled, and quantity fields **Object fields:** * `simple_object` - JSON object field * `nested_object` - Complex nested object with host, port, SSL settings, and credentials **Special fields:** * `number_with_range` - Integer between 1-100 (default: 50) * `local_reference_template` - Reference to local templates * `remote_reference_example` - Reference to remote API options * `remote_reference_with_dependency` - Dependent reference field **UI state fields:** * `tooltip_field` - Field with helpful tooltip * `hidden_field` - Hidden from UI * `disabled_field` - Cannot be edited * `readonly_field` - Read-only display * `deprecated_field` - Marked as deprecated * `staff_only_field` - Only visible to staff users **Outputs** The action returns a simple object with two properties: * `message` (string) - A test result message describing the outcome * `success` (boolean) - Whether the test execution was successful

UUID action

Generates a new UUID (Universally Unique Identifier). * **Parameters:** UUID type (options include `uuid1` and `uuid4`, defaults to `uuid4`). * **Output:** The generated UUID.

# Rewst actions ## Available Rewst actions *Rewst actions* provide you the tools to effectively manage and customize your environment. From setting up organizations and users to associating with multi-tenanted objects, these actions form the foundation of your interaction with the platform. This guide explores each of the available actions in detail, providing you a clear path to maximize the potential of your Rewst functionality. {% hint style="info" %} Click to expand each of the Rewst action accordions below to see its documentation. {% endhint %}

Associate External Object action

Linking external resources, like tickets from a PSA system, to your workflow executions can streamline management and enhance traceability. This action connects an external system's resource to your workflow. It optionally fails if a pre-existing link is detected, and runs under specified user or default user. **Parameters:** * **identifier:** Unique identifier of the external resource you'd like to associate. * **reference\_id:** Reference for the external resource that you will be able to call back on. * **run\_as\_user (optional):** Defined user's ID or default user's ID (if blank) for running the task. * **fail\_on\_conflict (optional):** Set this option to true if you don't want to overwrite any existing `reference_id`/`identifier` pair already exists. **Output:** The resulting task's output returns the verified information about the associated external object.

Bulk Create Organizations action

Create multiple organizations at once within Rewst. **Parameters:** * Managing **Organization ID:** The ID of the managing organization. If not provided, the organization that initiated the operation will be set as the managing organization. * Organizations (Required): List of organization details to be created. Each entry in the list should contain the following parameters: * Is Enabled: Boolean indicating if the organization should be enabled. * Name: The name of the organization in Rewst. The name must be unique. * Domain: The domain name of the organization's website, excluding protocol. **Output:** Outputs a list of newly created organizations, each with its corresponding Organization ID, Domain, Name, Managing Organization ID, and Enabled Status.

Bulk Upsert Organization Variables action

Performs a bulk operation to create or update organization variables. **Parameters:** * **Organization Variables:** A list of objects where each object represents an organization variable to be created or updated. Each object must include: * **Name:** The name of the organization variable. * **Value:** The value of the organization variable. * **Category:** The category used to define the organization variable. Options include: `general`, `contact`, `system`, `secret`. * **Use as default:** If true, this variable's value will be used as the default value for any managed organizations without a defined value. * **Organization ID:** (Optional) The ID of the organization. **Output:** Returns a list of objects. Each object represents an upserted organization variable and includes properties such as ID, name, value, organization ID, category, timestamps, associated organization, and more.

Create Organization action

Create a single organization within Rewst. **Parameters:** * Name (Required): The name of the organization to be created. This name must be unique within Rewst. * Domain (Optional): The domain of the new organization, excluding protocol. * Managing **Organization ID:** Identifier of the managing organization. If not provided, the organization that initiated the operation will be set as the managing organization. * Is Enabled (Optional, default is true): A boolean indicating whether the new organization is enabled or not. **Output:** Outputs the details of the newly created organization, which includes the Organization ID, Domain, Name, Managing Organization ID, and Enabled Status.

Create Organization Variable action

Creates a new organization variable that's available for use within an organization's workflow context. **Parameters:** * **Name:** The name of the organization variable. * **Value:** The value of the organization variable. * **Category:** The category used to define the organization variable. Options include: `general`, `contact`, `system`, `secret`. * **Use as default:** If true, this variable's value will be used as the default value for any managed organizations without a defined value. * **Organization ID:** (Optional) The ID of the organization. **Output:** Returns an object containing the new variable details including the ID, name, value, organization ID, category, timestamps, associated organization, and more.

Create Template action

Lets you create a new template. Template actions are used to manage templates that exist at the organization level of the workflow in which you are building. This action won't work for child orgs of the workflow's organization. **Parameters:** * **Name:** The name of the template. * **Description:** A brief description of the template. * **Body:** The actual template content. * **Content Type:** The type of content used in the template. * **Language:** The language used in the template. Options include: `html`, `markdown`, `powershell`, `python`, `yaml`. **Output:** The action returns the newly created template's information, including its `id`.

Delete Organization Variable action

Deletes a specific organization variable for a selected organization using the variable's name. **Parameters:** * **Organization ID:** The ID of an organization. * **Name:** The name of the organization variable to be deleted. **Output:** Returns an object indicating the success of the operation, including the name of the deleted variable and the ID of the organization from which it was deleted.

Delete Template action

This action lets you delete an existing template. Template actions are used to manage templates that exist at the organization level of the workflow in which you are building. This action won't work for child orgs of the workflow's organization. **Parameters:** * **Template ID**: The ID of the template you wish to delete. **Output:** The action does not return any specific output, but its execution status indicates whether the deletion was successful.

Delete User Invite action

Delete a user invite from your organization in Rewst. **Parameters:** * **Email:** Email address of the user invite to delete. **Output:** The returned object shows the number of invites deleted.

Export Object action

The `rewst_export_object` task is a Rewst platform action that exports Rewst objects— workflows, triggers, forms, templates, sites, or pages— into a portable bundle format that can be shared, backed up, or imported into other Rewst environments. The exported bundle includes cryptographic signing to ensure the integrity and authenticity of the exported data. **Parameters:** * **object\_type** - required: The type of object to export * Options: workflow, trigger, form, template, site, page * **object\_id** - required: The unique ID of the specific object to export * Uses a dynamic reference that populates available objects based on the selected object type **Outputs:** The action returns a bundle object containing: * objects: A mapping of serializable keys to their serialized objects (the actual exported data) * signing: Security verification details including: * cert: PEM-encoded X.509 public certificate for signature verification * hash: HMAC hashing algorithm name used for the signature * signature: base64-encoded signature for integrity verification * version: Version number of the export bundle format * exported\_at: Timestamp of when the bundle was created **Use Cases:** * Create portable backups of important workflows or other objects * Move objects between different Rewst environments * Share workflows or templates with other organizations * Create snapshots of objects at specific points in time

Generic GraphQL request action

This action has its own separate documentation page [here](/documentation/automations/actions-in-rewst/generic-graphql-request-action).

Get External Reference action

This action facilitates the retrieval of details about the any external integration or manually set references. You can use it to fetch all external integration references associated with a specific organization in Rewst or to find the organization and workflow execution associated with a specific external reference ID. It runs under specified user credentials or default user, but requires organization ID for context. **Parameters:** * **org\_id:** ID of the organization in Rewst. * **identifier:** Unique identifier of the external resource. * **reference\_id:** Reference ID of the external resource. * **run\_as\_user (optional):** Specify user credentials. **Output:** Returns detailed information about the external reference(s), such as the `org_id` in Rewst linked to it, the type of `identifier`, and the external `reference_id`. This information is helpful for cross-system data synchronization and management. ***

Get Form action

Retrieves details about a specific form in the system. **Parameters:** * **Name:** The name of the form. * **ID:** The ID of the form. **Output:** The action returns information about the specified form.

Get Microsoft CSP Customer action

Get data for a single Microsoft CSP customer in Rewst. **Parameters:** * **CSP Integration Configuration ID**: The ID of a Microsoft integration configuration in Rewst.

Get Organization action

Retrieve data for a single organization in Rewst. **Parameters:** * **Organization ID:** Identifier of the organization to fetch data for. This ID is unique for each organization within Rewst. **Output:** Outputs the details of the organization, which includes the Organization ID, Domain, Name, Managing Organization ID, and Enabled Status.

Get Organization Variable action

Retrieves a specific organization variable for a selected organization using the variable's name or value. **Parameters:** * **Name:** (Optional) The name of the organization variable. * **Organization ID:** (Optional) A dropdown list of the labels that correlate with the ID of an organization you'd like to retrieve. * **Value:** (Optional) The value of the organization variable. **Output:** Returns an object (or list of objects) representing the organization variable, including the ID, name, value, organization ID, category, timestamps, associated organization, and more.

Get Template action

Lets you retrieve the details of an existing template. Template actions are used to manage templates that exist at the organization level of the workflow in which you are building. This action won't work for child orgs of the workflow's organization. **Parameters:** * **Template ID**: The ID of the template you wish to retrieve. **Output:** The action returns the requested template's information, including its `name`, `description`, `body`, `content_type`, and `language`.

Get Trigger action

Retrieves details about a specific trigger in the system. **Parameters:** * **Name:** The name of the trigger. * **ID:** The ID of the trigger. * **Enabled:** A boolean value that indicates whether the trigger is enabled or not. **Output:** The action returns information about the specified trigger.

Get User action

Get user by email or ID in Rewst. **Parameters:** * **ID:** The ID of a user in Rewst. * **Organization ID:** The ID of an organization in Rewst. * **Email address:** The email of a user in Rewst. **Output:** The returned object includes the user's details like ID, role, organization ID, assigned role IDs, username, and a boolean indicating superuser status.

Invite User to Rewst action

Invite a user to your organization in Rewst. **Parameters:** * **Email:** Email address of the user to invite. * **Roles:** Role IDs to assign to user. **Output:** The returned object includes the invite details such as ID, email, organization ID, assigned role IDs, a boolean indicating acceptance status, and the ID of the inviter.

Link Microsoft CSP Customer action

Link one or more Rewst organizations to a microsoft CSP customer in Microsoft **Parameters:** * **CSP Integration Configuration ID**: The ID of a Microsoft CSP integration configuration in Rewst. * **Microsoft CSP Customer ID**: The ID of the Microsoft CSP Customer in Rewst that you want to link your organization or organizations to. * **Organization IDs**: The list of Rewst organization IDs to link. **Output:** The returned object lists a confirmation of the linked organizations

List Apps action

Lists all apps, also known as sites, associated with the current organization in Rewst. **Parameters:** * **Run as user - optional:** The ID of the user to run the query as. If omitted, defaults to the workflow's context user. **Output:** Returns a list of apps, including details such as ID, name, and organization association.

List Forms action

Retrieves a list of all forms in the system. **Parameters:** No parameters are required for this action. **Output:** The action returns a list of all forms, each item including information about a form.

List Forms With Granular Permissions

The rewst\_list\_forms\_with\_granular\_permissions task retrieves a list of all forms in your Rewst organization that the specified user has permission to access, taking into account granular permission settings. If run\_as\_user is set to null, it will use the default organization user. This action is useful for building dynamic interfaces or workflows that need to work with forms based on user permissions, ensuring users only see forms they have access to. **Parameters:** run\_as\_user - required: The user ID that the action will run as. If not specified, the default user for your organization will be used. **Outputs:** The task returns an array of form objects, where each form contains: | Field | Type | Description | | -------------------- | ------- | -------------------------------------------------------------------------------------------- | | **id** | String | Unique identifier for the form | | **name** | String | Display name of the form | | **description** | String | Form description | | **org\_id** | String | Organization ID that owns the form | | **created\_at** | String | Timestamp when the form was created | | **updated\_at** | String | Timestamp when the form was last modified | | **is\_synchronized** | Boolean | Whether the form is synchronized | | **tags** | Array | List of tags associated with the form (each tag has `id` and `name`) | | **triggers** | Array | List of triggers associated with the form (each trigger has `id`, `name`, and `workflow_id`) |

List Integrations For Organization action

This action retrieves a comprehensive list of integrations installed for a specific organization in Rewst, providing a detailed overview of each integration's attributes. **Parameters:** * **Organization ID:** The unique identifier for an organization in Rewst. This parameter is required to fetch the specific integration details pertinent to the organization. **Output:** The action generates a detailed list of integrations, including: * **Integration ID, Name, and Reference:** Basic identifiers providing clarity on each integration. * **Pack Configurations:** In-depth details of configurations applied to each integration, offering insights into their setup and customization. * **Applied Triggers:** Information on workflow triggers linked to each integration, useful for understanding operational dynamics. * **Foreign Object References:** Crucial data points that link integrations to external references, enhancing cross-platform data synchronization and management.

List Microsoft CSP Customer action

Get a list of Microsoft CSP customers in Rewst. **Parameters:** * **CSP Integration Configuration ID**: The ID of a Microsoft integration configuration in Rewst. * **Microsoft CSP Customer ID**: The ID of the Microsoft CSP Customer in Rewst that you want to link your organization or organizations to. * **Organization IDs**: The list of Rewst organization IDs to link.

List Organizations action

Fetch a list of all organizations in Rewst. **Parameters:** * Managing **Organization ID:** Identifier of the managing organization to fetch organizations for. This ID is unique for each organization within Rewst. * Name (Optional): Name of the organization to search for. The name must be unique within Rewst. **Output:** Outputs a list of organizations, each with its corresponding Organization ID, Domain, Name, Managing Organization ID, and Enabled Status.

List Organization Variables action

Lists all organization variables visible to the selected organization. **Parameters:** * **Organization ID:** (Optional) A dropdown list of the labels that correlate with the ID (visible in the code editor window) of an organization you'd like to retrieve. **Output:** Returns a list of objects. Each object represents an organization variable and includes the ID, name, value, organization ID, category, timestamps, associated organization, and more.

List Templates action

Lets you retrieve a list of all existing templates. Template actions are used to manage templates that exist at the organization level of the workflow in which you are building. This action won't work for child orgs of the workflow's organization. **Parameters:** *No parameters are required for this action.* **Output:** The action returns a list of all templates, with each entry including information about a template, such as its `id`, `name`, `description`, `body`, `content_type`, and `language`.

List Triggers action

Retrieves a list of all triggers in the system. **Parameters:** No parameters are required for this action. **Output:** The action returns a list of all triggers, each item including information about a trigger.

List User Invites to Rewst action

Get user invite list by your organization in Rewst. **Parameters:** *No parameters needed for this action.* **Output:** The returned list includes a list of user invite objects. Each object contains the invite's ID, email, organization ID, assigned role IDs, a boolean indicating acceptance status, and the ID of the inviter.

List Users by Organization action

Get user list and optionally invited users by your organization in Rewst. **Parameters**: * **Include User Invites?:** Whether or not to include user invites in the results. * **Which Invites:** Which invitees to include. Can be `all`, `accepted`, or `pending`. **Output**: A list of users with details like ID, role, organization ID, assigned role IDs, username, and a boolean indicating superuser status.

List Workflows actions

This action retrieves a comprehensive list of all workflows in your Rewst organization, giving you visibility into your automation library. This action is particularly useful for workflow management tasks, reporting, and as a starting point for more complex workflow operations that require workflow IDs. **Parameters:** * `run_as_user` (optional): Specifies which user the action should run as. If not provided, it uses your organization's default user. **Output:** The action returns detailed information for each workflow: * `id`: Unique workflow identifier * `name`: The workflow's display name * `tags`: Array of tags assigned to the workflow * `org_id`: Organization ID where the workflow belongs * `triggers`: Array of associated triggers for the workflow * `created_at`: Timestamp when the workflow was created * `updated_at`: Timestamp of the last modification * `organization`: Detailed organization information * `unpacked_from`: Template source information (if the workflow was created from a template) * `cloned_from_id`: Source workflow ID (if the workflow was cloned from another) **Common use cases:** * Workflow Inventory: Get a complete overview of all workflows in your organization * Trigger Analysis: Identify which workflows have active triggers * Workflow Management: Use the returned workflow IDs for subsequent operations on specific workflows * Organizational Reporting: Generate reports on workflow usage and organization {% hint style="info" %} Note that this action won't return workflow notes. To retrieve that information, use the [Rewst - Generic GraphQL Request](#generic-graphql-request-action) action to query `workflowNotes` . {% endhint %}

List Workflow Executions With Time Savings action

The `rewst_list_workflow_executions_with_time_savings` task is an action from the Rewst integration that lists workflow executions with calculated time savings data. This action retrieves execution data and calculates how much time has been saved through automation. It provides comprehensive analytics about workflow performance and efficiency. * Retrieves execution data including total executions, seconds saved, workflow names, and organization information * Calculates time savings for automated workflows * Filters executions by date, status, and organization * Groups results either by individual workflow or by sub-organization **Parameters:** * **`updated_at`** (required): Include any executions updated after this date (datetime format) * **`workflow_status`** (optional): Filter by execution status (`succeeded`, `failed`, or `running`) * **`group_by_sub_org`** (optional): Choose whether to group results by sub-organization (default: false, groups by workflow) * **`run_as_user`** (optional): The user that the action will run as **Output:** The action returns data including: * `ran_for_org`: Organization identifier * `workflow_id`: Unique workflow identifier * `seconds_saved`: Calculated time savings in seconds * `workflow_name`: Name of the workflow * `total_executions`: Total number of executions

Unlink Microsoft CSP Customer action

Unlink one or more Rewst organizations from a Microsoft CSP customer in Rewst. **Parameters:** * **CSP Integration Configuration ID**: The ID of a Microsoft integration configuration in Rewst. * **Microsoft CSP Customer ID**: The ID of the Microsoft CSP Customer in Rewst that you want to link your organization or organizations to. * **Organization IDs**: The list of Rewst organization IDs to link. **Output:** The returned object lists a status for the unlink action ***

Update Organization action

Update details of an existing organization within Rewst. **Parameters:** * **Organization ID:** Identifier of the organization to be updated. This ID is unique for each organization within Rewst. * Name (Optional): New name for the organization. This name must be unique within Rewst. * Domain (Optional): New domain for the organization, excluding protocol. * Is Enabled (Optional): Updated enabled status for the organization. It is a boolean value. **Output:** Outputs the updated details of the organization, which includes the Organization ID, Domain, Name, Managing Organization ID, and Enabled Status.

Update Template action

This action lets you update the details of an existing template. Template actions are used to manage templates that exist at the organization level of the workflow in which you are building. This action won't work for child orgs of the workflow's organization. **Parameters:** * **Template ID:** The ID of the template you wish to update, it is a required field. * **Body:** The new content of the template. * **Content Type:** The new type of content used in the template. The options are `message` and `script`. * **Description:** A brief description of the template. * **Language:** The new language used in the template. The options include: `html`, `markdown`, `powershell`, `python`, `yaml`. **Output:** The action returns the updated template's information, including its `id`.

Update Trigger action

The rewst\_update\_trigger task is used to modify existing workflow triggers within the Rewst platform. This action allows you to update properties of a trigger such as its name, enabled status, description, and the user it runs as. This task is particularly useful for dynamically managing trigger states within workflows, such as enabling ordisabling triggers based on certain conditions or updating trigger configurations programmatically. **Parameters:** * Trigger\_id - required: The ID of the trigger to be updated * Name: New name for the trigger * Enabled: Whether the trigger should be enabled or disabled * Description: New description for the trigger * Run\_as\_user: The user ID that the trigger will run as (defaults to organization default user if not specified) **Outputs:** The action returns an object containing the updated trigger information: * ID: The trigger ID * Name: The trigger name * Enabled: Whether the trigger is enabled or not * Description: The trigger description * Criteria: The trigger criteria * Parameters: The trigger parameters * Workflow\_ID: The associated workflow ID * Form: Form configuration objects * TriggerType: Trigger type information * Organization: Organization information * ActivatedForOrgs: Organizations where the trigger is activated

## App Builder-specific Rewst actions {% hint style="info" %} These Rewst actions are for use with [App Builder](/documentation/app-builder) only. Don't use them for general workflow building on the Workflow Builder canvas. {% endhint %}

List Pages action

Lists all pages for a specified app in Rewst. **Parameters:** * **App ID:** The ID of the app for which to fetch pages. * **Run as user - optional:** The ID of the user to run the query as. **Output:** Returns a list of pages within the specified app, including each page's ID, name, and metadata.

List Page Elements action

Lists all elements within a specific page in an app, including their Element IDs and key properties. **Parameters:** * **Page ID:** The ID of the page whose elements you want to retrieve. * **Run as user - optional:** The ID of the user to run the query as. **Output:** Returns a dictionary mapping element IDs to their properties, including type, Craft ID, and other element-specific details.

Update Text Element Content action

Updates the text-based content of a page element— such as a text block, button, link, HTML container, markdown block, or accordion— within a specified page. **Parameters:** * **Content:** The new text content to set for the element. * **Page ID:** The ID of the page containing the element to update. * **Element ID:** The ID of the page element whose text content you want to update. * **Run as user - optional:** The ID of the user to run the query as. **Output:** Returns the updated element's details, including confirmation of the new text content.

# Generic GraphQL request action ## What is GraphQL? {% hint style="info" %} Learn more about GraphQL in its official documentation [here](https://graphql.org/learn/introduction/). {% endhint %} GraphQL is an open-source query language for APIs and a server-side runtime for fulfilling those queries. It enables clients to interact with a single endpoint to get the exact data they need, without chaining requests together. Unlike traditional REST APIs that return fixed datasets, GraphQL allows clients to request specific data, eliminating over-fetching or under-fetching of data and offering improved efficiency. The [GraphQL Schema](https://graphql.org/learn/schema/) defines the structure of the data and available operations, serving as a clear contract between the frontend and backend. Like REST APIs, GraphQL is composed of a basic request and response for each call. While REST APIs rely on multiple endpoints for this process, GraphQL shifts the responsibility of defining what should be called back to the user. GraphQL in Rewst works off of two *operation types*: 1. Query: Used for reading or fetching data 2. Mutation: Used for writing, updating, or deleting data {% hint style="info" %} GraphQL has a third operation type called subscription. Rewst's generic GraphQL action currently only supports queries and mutations. If there is a subscription you are looking to use in Rewst, please submit a request to our product team for a dedicated action. {% endhint %} ## What is the Rewst GraphQL generic request action? {% hint style="warning" %} Before using the Generic GraphQL request action, we recommend that you have: * An understanding of GraphQL query structure and syntax * Familiarity with Rewst's data model and the below available schema documentation {% endhint %} \ The Rewst GraphQL generic request action is used for making authenticated requests against Rewst's GraphQL API. This action is available in the Rewst actions section of the Workflow Builder's actions library, but is open-ended in its capabilities. It enables: * Direct API access: Execute custom GraphQL queries and mutations against Rewst's backend * Advanced data retrieval: Access data structures not available through standard actions * Custom automation: Build sophisticated workflows with precise data control * Administrative operations: Perform bulk operations and administrative tasks programmatically

Make your choices in the **Parameters** tab of the action's settings to set it up in your workflow: * **Operation type**: Choose the type of GraphQL operation, **query** or **mutation** * **Graph operation**: The name of the specific GraphQL operation to execute * Uses the Graph Operations reference * Options in the drop-down list will dynamically populate based on your selected operation type * **Variable values**: Variables to pass to the GraphQL operation * JSON object type, but can be passed via Jinja * Contains the input parameters for the selected operation * **Response fields**: Enter text into this field to specify the fields to include in the GraphQL response * Only provide the inner content, as it will be wrapped in curly braces * Example, `id orgName email { name }` * **Raw query**: The complete raw GraphQL query string to execute * An advanced alternative to using the other fields and selectors in the Parameters tab * Allows for full control over query structure ## Filtering arguments: Where versus search Every plural list query in the Generic GraphQL Request action accepts up to two filtering arguments: *where* and *search*. They are not interchangeable. #### Where: Equality only - `field: value` → `WHERE field = value` `where` accepts a flat object of `field: value` pairs. Each pair is rendered as `WHERE field = value`. There's no way to express greater than, in this list, contains substring, etc. through `where`. The set of fields exposed in each `


Add or subtract from DateTime transform action	/pages/94VvqKtWjKOFrVGOAIVL
All transform action	/pages/zgUEdWLcY7r1E1RDEk6g
Any transform action	/pages/xLpDBjc9TesMbGkflijN
Append with items results transform action	/pages/iVCOFwsZReLztyCwBSNy
Average transform action	/pages/MuAV5iBTkLaxXbtZ3TPX
Base64 decode transform action	/pages/Hs63WnEFMdU7ayFJiyLV
Base64 encode transform action	/pages/3TOQHy0tSSEEoYWDToyM
Compare dates transform action	/pages/n8PQcMnhQKvGu1HobNgo
Convert DateTime to timezone transform action	/pages/nIqKmTumNJDTKgThdR1l
Convert from epoch transform action	/pages/cnjQaAPLWEO3Pv0nDh5n
Convert list to object transform action	/pages/dygkNPjMRNnmUGK28UI1
Defang transform action	/pages/x7W29AnqRzDtva7MEsXW
Diff lists transform action	/pages/5gc7RkOWkv0e12VAgSzZ
Extract part of a date transform action	/pages/PBuFVt8lWjaixgYVu9Sv
Flatten list transform action	/pages/B4Sts5BoPnNdsWpaZvMI
Format date time transform action	/pages/aC2wgAKASJ1moNIsW5Zi
Generate friendly password transform action	/pages/fAH7pStO1WFT2peGSkG8
Get business days between dates transform action	/pages/yo6Ew8ZTCwslgHOjYVtN
Get DateTime transform action	/pages/ElESrTJdT6s7ZL9asYsF
Get days between dates transform action	/pages/GisOlHYbpSP1TnmqkCM2
Get list length transform action	/pages/3YJNL9fq5APhRQM1uuEf
Get string length transform action	/pages/ealuUBdQqMQrcctJ8q9y
Is JSON transform action	/pages/LK3M6zmdHZGNH6E9PczO
Map to an attribute within a list transform action	/pages/GgJQcbcTwjLGa0rYQsAl
Merge lists transform action	/pages/b6KuxcunghNggGewvQip
Parse CSV transform action	/pages/pd2rEtXgSBUiGz7JdR4s
Parse text to JSON transform action	/pages/PAh7D8CUZwZ6UIouO7ET
Range transform action	/pages/1kNHOEHnPmtQUv5y4tDC
Refang transform action	/pages/VifM1lScmYmsrdtq7q4v
Remove duplicates from list transform action	/pages/xKJes1d1OT8GAwh52Zfi
Return element transform action	/pages/wmoO0QOnCPrxX7wrYtN5
Select attribute transform action	/pages/jSzeeXumO1RA09H5O7ME
Set list field value transform action	/pages/aUyqY6JFAZIPqTRtECfW
Set variable transform action	/pages/6LQ0hxDmBIlhQFB71IU8
Sort transform action	/pages/8jc8MeKCN2bO5ksTPdHZ
Split text transform action	/pages/LIyimMVNoharuPrXhOaR
Transform list objects transform action	/pages/dJhQgEeQYAgdlJYJY9rk
Trim variable transform action	/pages/I4u3825s6Iv7Z1E8N1uR
URL decode transform action	/pages/Jb3Mxsf4SopkJSGXoGyi
URL encode transform action	/pages/ELNDDW3L4pkil3rezsEH
Yaml parse transform action	/pages/JJD4HnCgAT4Q8ZnxQX9U

Parameter	Description	Required
DateTime to add or subtract from	Use https://strftime.org/ for various options	true
Days to add or subtract	Integer value for how many days to add or subtract.	false
Hours to add or subtract	Integer value for how many hours to add or subtract.	false
Microseconds to add or subtract	Integer value for how many microseconds to add or subtract.	false
Minutes to add or subtract	Integer value for how many minutes to add or subtract.	false
Months to add or subtract	Integer value for how many months to add or subtract.	false
Seconds to add or subtract	Integer value for how many seconds to add or subtract.	false
Years to add or subtract	Integer value for how many years to add or subtract.	false

Parameter	Description	Required
First Date	This should be a valid datetime string representation.	true
Second Date	This should be a valid datetime string representation.	true
Comparison Operator	The operator to use in the comparison.	true
Day First	Whether to interpret the first value in an ambiguous 3-integer date (e.g. 01/05/09) as the day (True) or month (False). If yearfirst is set to True, this distinguishes between YDM and YMD. If set to None, this value is retrieved from the current parserinfo object (which itself defaults to False).	false
Fuzzy Parsing	Whether to allow fuzzy parsing, allowing for string like "Today is January 1, 2047 at 8:21:00AM"	false
Ignore Timezone	If set True, time zones in parsed strings are ignored and a timezone naive datetime object is returned.	false
Year First	Whether to interpret the first value in an ambiguous 3-integer date (e.g. 01/05/09) as the year. If True, the first number is taken to be the year, otherwise the last number is taken to be the year. If set to None, this value is retrieved from the current parserinfo object (which itself defaults to False).	false

Parameter	Description	Required
Difference Method	Choose the method to compute the differences between the lists. Options are `anti_join` and `symmetric_difference` (described below).	true
First List	Enter the first list to be compared.	true
First List's Key	Identify the key attribute for matching items in the first list.	true
Second List	Enter the second list to be compared.	true
Second List's Key	Identify the key attribute for matching items in the second list.	true

Parameter	Description	Required
Date Time String	The original date time string that needs formatted differently.	true
Day First	Whether to interpret the first value in an ambiguous 3-integer date (e.g. 01/05/09) as the day (True) or month (False). If yearfirst is set to True, this distinguishes between YDM and YMD. If set to None, this value is retrieved from the current parserinfo object (which itself defaults to False).	false
Year First	Whether to interpret the first value in an ambiguous 3-integer date (e.g. 01/05/09) as the year. If True, the first number is taken to be the year, otherwise the last number is taken to be the year. If set to None, this value is retrieved from the current parserinfo object (which itself defaults to False).	false
Fuzzy Parsing	Whether to allow fuzzy parsing, allowing for string like "Today is January 1, 2047 at 8:21:00AM"	false
Ignore Timezone	If set True, time zones in parsed strings are ignored and a timezone naive datetime object is returned.	false
Desired String Format	Defaults to YYYY-MM-DDTHH:MM:SSZ if left empty.	false

Parameter	Description	Required	Required
Base List	This is the main list to which you want your collected results to be appended.	true	true
Collected List	This is the list of results from your completed `With Items` task, from which the nested `result.result` attribute will be extracted.	true	true
Attribute Name	This is the name you'd like to set for the new attribute to be appended to the `Base List`.	true	true

Parameter	Description	Required
String	String to encode	true
URL Safe	Whether to return a URL-safe base64 format. '-' is used instead of '+', and '_' instead of '/'.	false

Parameter	Description	Required
String	String to decode.	true
URL Safe	Whether the base64-encoded has been encoded in URL-safe format.	false
As Bytes	Whether to return the raw bytes, instead of decoding the bytes as a UTF-8 string.	false

Parameter	Description	Required
DateTime to convert	Use https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior for various options	true
Timezone to convert	Use https://en.wikipedia.org/wiki/List_of_tz_database_time_zones for various options not listed	true

Parameter	Description	Required	Required
List to Transform	The list of objects you want to transform into a single object. Each item in the list should be a object with key-value pairs.	true	true
Field to use as Key	The field name from the items in your list that you want to use as keys in your new object.	true	true
Field to use as Value	The field name from the items in your list that you want to use as values in your new object.	true	true

Parameter	Description	Required
URL	URL to defang	true
Colon	If true defang colons.	false
Dots	If true defang all dots.	true


	The `Symmetric Difference` method is used when you want to identify entries that are unique to each list, i.e., items that exist in the one list and not in the other.
		The `Anti Join` difference method is used when you want to determine the items in the first list that don't have a corresponding match in the second list.

Parameter	Description	Required
Date Time String	The original date time string to extract a part from.	true
Part to Extract	The part of the date to extract. Defaults to year.	true

Parameter	Description	Required
Start Date	The start date; This day is inclusive in the returned count.	true
End Date	The end date; This day is exclusive in the returned count.	true
Holidays	A list of holidays	false
Country	Country Specific Holidays to remove from the set.	false

Parameter	Description	Required
DateTime format to return	Use https://strftime.org/ for various options	true
Timezone to return	The timezone you would like to have the date returned in.	true

Parameter	Description	Required
Attribute	The attribute to map to, dot notation can be used. For example, result.result	true
List	The list you would like to perform the map on.	true

Parameter	Description	Required
Merge Method	Choose the strategy to merge the lists. Options are `inner`, `left`, or `outer` join.	true
First List	Enter the first list for the merging process.	true
First List's Key	Identify the key attribute for matching items in the first list.	true
Second List	Enter the second list to be merged with the first one.	true
Second List's Key	Identify the key attribute for matching items in the second list.	true

Parameter	Description	Required
Delimiter	Character or sequence of characters to used as a delimiter in the CSV (default is ), such as '\|';':', etc.	true
String Contents	Input the CSV formatted string you would like to convert to JSON.	true

Parameter	Description	Required
Start	The starting value of the range, inclusive. Default is 0 if not provided.	true
End	The ending value of the range, exclusive. Default is 0 if not provided.	true
Step	The step size for the range. Defaults to 1 if not provided.	false

Parameter	Description	Required
Attribute	Filter objects with unique values for this attribute; Only required for lists of objects.	false
Case Sensitive	Treat upper and lowercase strings as distinct.	false
List	List to remove duplicates from.	true

Parameter	Description	Required
Element	Element number to Return, starting at 0 for the first element. -1 will return the last element	true
Input String or List	String or list that you would like to return the element of.	true

Parameter	Description	Required
Attribute	The attribute of an object in the list that you would like to select if the condition is true. If nested, please use dot notation.	true
Comparison Operator	Test used for selecting matches. For information on the tests see Jinja's documentation here.	true
List	This is the list to run select attribute against.	true
Value to Compare Against	The value to compare the attribute against, this is required for most tests but tests such as true, false, defined, undefined do not require it. If a value is supplied and not needed it will be ignored.	false

Parameter	Description	Required	Required
List to Transform	The list of objects you want to modify the contents of.	true	Yes
Field to Update	Specify the field to be added or modified in each object.	true	Yes
New Value	Specify the value for the new or modified field.	true	Yes
New Value Mode	How you want to provide the field's new value. `copy_from_field` or `set_value` (described below)	true	Yes
Parent Fields	If the field should be nested within another list, specify the parent list's name here.	false	No
Condition Field	If you want to update the field conditionally, specify the field to base the condition on.	false	No
Condition Value	If a `Condition Field` is specified, provide the value that should be matched to trigger the update.	false	No

Parameter	Description	Required
Attribute	When sorting a list of dictionaries, an attribute or key to sort by. Can use dot notation like "address.city".	false
Case Sensitive	When sorting strings, sort upper and lower case separately.	false
Input List or String	List or string to sort	true
Reverse Sort	If true, will sort in descending order instead of the ascending order.	false

Parameter	Description	Required
Max Splits	The maximum number of splits. If not specified or -1, then there is no limit on the number of splits (all possible splits are made)	true
Seperator	Character or sequence of characters to split on (default is ), such as ' , ',':', etc.	false
Text to split	The string to be split.	true

Parameter	Description	Required
List to Transform	The list that you would like to restructure.	true
Input Field	The item in the list you would like to transform.	true
Transformation Method	The transformation method to be applied on the input field. (options described below)	true
Output Field	The new field where the transformed value will be stored.	false
Append Action Type	The type of appending action if the method is set to `append`.	false
Append Value	The value to be added if the `Append Action Type` is `Append Value`.	false
Append Field	The field to be joined if the `Append Action Type` is `Append Field`.	false
Delimiter for Append	The delimiter to be used in the `Append` method	false
Field for Concatenation	The field to be used in the concatenation operation if the method is `Concatenate`.	false