| Term | Definition |
|---|---|
| Actions | Actions are specific tasks that live inside a workflow in Rewst. Actions are grabbed from the menu, dragged onto the workflow builder canvas, and executed as a task when the workflow runs. |
| Anti-patterns | Anti-patterns are common but harmful practices that increase complexity and maintenance challenges. Unlike design patterns, which offer best-practice solutions, anti-patterns often make your code less clear and more error-prone. |
| API | Short for Application Programming Interface, an API is a set of protocols that allow actions on a platform in a programmatic manner. APIs power Rewst's integrations, enabling actions that workflows perform. |
| API key | An API key is a unique identifier used during integration setup, allowing secure communication between platforms without re-entering the key for each action. |
| Authentication method | The process of verifying the identity of a user or application. The required authentication method will depend on the API you're attempting to access. For more detail, or information on more complex authentication methods check out Mozilla's Developer Network (MDN) documentation on HTTP authentication methods. |
| Automation | Automation refers to the process of using technology, including Rewst's platform, to perform repetitive tasks without human intervention. It enables businesses to increase efficiency, accuracy, and consistency by automating various processes, from simple notifications to complex multi-step workflows. |
| Basic authentication | Basic authentication is a method that requires a username and password, often used for web server login. |
| Body | Regarding APIs, a body is the part of an HTTP request containing data sent to the API, typically structured in formats like JSON or XML. Example JSON body: {"username": "john_doe", "password": "secret"}. |
| Cookies | Cookies are small pieces of data stored on a user's computer by a web server, used by APIs to manage sessions or track user behavior. |
| Content type | A content type is a specific header used in HTTP requests to indicate the media type, such as application/json for JSON data. |
| The context | 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 without re-fetching the data. |
| Context variables | Context variables are variables accessed via the CTX prefix within a running workflow in Rewst, for dynamic processing. They are specific to the workflow run and hold data generated or used during that instance, such as the current ticket ID or timestamp. |
| Crate | A Crate is a pre-built automation. Crates within Rewst contain workflows, forms, triggers, templates, and scripts bundled together for easy deployment. |
| Crate Marketplace | The Rewst Crate Marketplace is the area of the Rewst platform where users can find and install Crates, offering a range of pre-built automation solutions. |
| Child organization (child org) | Rewst uses a two-tier system to manage organizations, with your MSP as the parent org, and customers set as individual child orgs under that parent. |
List comprehension is a way to create a new list by transforming or filtering items from an existing one, all in one Jinja expression.
| {% endtab %} {% tab title="MNO" %} | Term | Definition | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Markdown | *Markdown* is a lightweight markup language that you can use to add formatting elements to plaintext text documents. When you create a Markdown-formatted file, you add Markdown syntax to the text to indicate which words and phrases should look different. | | Multipart/Form-Data | A media type used to send files as part of an HTTP request, allowing for the uploading of files along with textual data. | | Nopp | In Jinja, a *noop* is an empty action used to create custom transitions. | | OAuth | Short for open authorization, *OAuth* is an open standard for access delegation, often used to grant token-based authentication and authorization. | | Option Generator | An *option generator* is a workflow that generates options, and can be connected to specific field types. For example, you would use this to curate what shows up in a workflow's dropdown, rather than showing every single group in that menu. | | Organization | A group or entity within the Rewst platform that may have its own variables, forms, workflows, and users, *organizations* enable multi-tenanted management and customization of the platform according to specific client needs. You may see us refer to an organization as an *org* for short. | | Organization Variables | Also known as *org variables,* these are specific variables used within an organization or sub-organization in Rewst. They can be referenced in workflows and may be inherited or overridden by sub-organizations. They apply across all workflows, storing consistent data like company settings or API keys. | | Output | Regarding APIs, *output* is the content returned by a server in response to a request, including messages, data objects, or other information. E.g., `{"status": "success", "token": "abc123"}.` | {% endtab %} {% tab title="PQR" %} | Term | Definition | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Parameters | *Parameters* in Rewst are like fill-in-the-blank options that make workflows adaptable. Example: Instead of hardcoding a date, you can use a parameter like `ReminderDate` to customize it each time the workflow runs. | | Parent organization (parent org) | Rewst uses a two-tier system to manage organizations, with your MSP as the *parent org,* and customers set as individual child orgs under that parent. | | Path parameter | A *path parameter* is a unique identifier in the URL that identifies specific data, such as an ID in API calls. E.g., the `123` in `/users/123`. | | PowerShell | *PowerShell* is a command-line shell and scripting language, primarily designed for system administrators by Microsoft, allowing them to automate tasks and manage systems from the command line. The language is now cross-platform. | | Query parameter | A *query parameter* is an optional parameter available to be added to the Endpoint to filter the API call for some endpoints. E.g., `?status=active`. | | Redirects | Regarding APIs, a *redirect* is the automatic forwarding of an HTTP request from one URL to another. E.g., redirecting from `http://example.com` to `https://example.com` to enforce use of HTTPS. | | RoboRewsty | *RoboRewsty* is Rewst's AI integration feature. It integrates with the workflow builder canvas. It takes your workflows' JSON objects, and sends them to a private OpenAI Azure instance. The result is a quickly presented, well structured documentation breakdown of all selected tasks in your workflow. | | {% endtab %} | | {% tab title="STU" %} | Term | Definition | | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Status codes | *Status codes* are numeric codes returned by a server to indicate the result of an HTTP request. E.g., `200` (success), `404` (not found), and `500` (server error). | | Template | In Rewst, *templates* are used as a central store for repeated text, allowing for consistency across different actions and workflows. | | Timeout | Regarding APIs, *timeout* is the maximum time allowed for a request to be processed | | Transitions | *Transitions* are elements found at the bottom of every action in Rewst that determine the path the workflow will take. Transitions can be based on success, failure, always, or custom-defined Jinja conditions. | | Triggers | *Triggers* are components in Rewst used to initiate workflows or perform actions based on specific events or conditions. They can respond to various events, such as form submissions or webhook responses. | {% endtab %} {% tab title="VWX" %} | Term | Definition | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Variables | A *variable* is a labeled container that holds data you can reuse. Instead of locking in specific details like a customer's name, you can use a placeholder— e.g., CustomerName— that updates dynamically. | | Webhook | A *webhook* is like a notification that triggers a workflow as soon as an event happens—no need to constantly check for updates. Example: When a customer submits a support ticket, a webhook instantly sends that information to Rewst, starting the workflow right away. | | With Items | In Rewst, `with_items` is used in Loop blocks, and sometimes inline within block configurations, to iterate over a list of items. It's the Rewst equivalent of a `for` loop in Python or Jinja. | | Workflow | In the context of Rewst, a *workflow* is a series of automated actions that are executed in a specific sequence based on triggers and conditions. Workflows enable users to design, execute, and manage multi-step processes, bringing together various integrations to accomplish a particular task. | | XML | Short for extensible markup language, *XML* is used to encode data in a format that is both human-readable and machine-readable. | {% endtab %} {% tab title="YZ" %} | Term | Definition | | ---- | ---------------------------------------------------------------------------------------------------------- | | YAML | *YAML* is a human-readable data serialization language that is often used for writing configuration files. | | | | | | | {% endtab %} {% tab title="#" %} {% endtab %} {% endtabs %}“Give me a list of all X from Y, but only if Z.”