> For the complete documentation index, see [llms.txt](https://docs.rewst.help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rewst.help/rewst-documentation/rewst-classic-to-new-rewst-help/rewst-platform-translation-guide.md). # Rewst platform translation guide {% hint style="info" %} This documentation contains terms and concepts that were essential to using our Rewst Classic, with explanations for how they are now handled in new Rewst. For further assistance, ask the Rewst Agent. If you're someone who never used Rewst Classic and has only ever been a customer of new Rewst, skip this page and read our regular documentation. {% endhint %} ## AI * In Rewst Classic, you worked with RoboRewsty to learn and build. * The [Rewst Agent](/rewst-documentation/documentation/rewst-agent.md) is your new best friend. RoboRewsty doesn't exist in new Rewst, but the Rewst Agent can do everything RoboRewsty did and more. * Everything in this guide is a rule the Rewst Agent already follows. * The Agent does not take Canvases away. It produces the same draft you would, on the same Canvas. If you're a die-hard builder, let the Agent lay down the skeleton, the integration calls, and the data shaping, then hand-tune the parts you care about. You keep the control, but you skip the hour of finding out which port, alias, or filter is required. ## Workflow Builder * In Rewst Classic, the elements you placed on the Workflow Builder Canvas had different names: actions, triggers, subworkflows, etc. * All elements you place on the Canvas are now called *nodes*. This includes actions, triggers, and anything you drag from the library on the Workflow Builder. * Triggers are nodes on the Canvas. The common ones: | Classic trigger | Rewst trigger node | | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | | Webhook | **Receive Webhook** | | Cron Job, Time Interval | **Run on Schedule** (Interval, guided Schedule, Exact, or 5-field Cron, with a timezone) | | Form Submission | **Receive Form** | | Workflow Completed | **Workflow Completed** | | Integration sensors (New Ticket Record, Company Record Saved, ...) | The integration's own trigger nodes in its palette folder | | Options generator for forms | **Trigger: Request Options** | * Differences to plan for: * Trigger Criteria has no direct equivalent. Put an [If / Else node](https://docs.rewst.help/rewst-documentation/rewst-classic-to-new-rewst-help/pages/27ztelCxRCWn8lmMEtvh#if-else-none.if_else) right after the trigger and leave the non-matching port unconnected. * Trigger Variables become workflow inputs with defaults (Configure → Inputs and Default run variables). * Activate Trigger To Run For is Run For on the trigger node, set through Configure scope. * Webhook triggers have a Response Mode. The default acknowledges immediately. Synchronous modes return the workflow's `CTX.output` to the caller, which covers what Classic did with `wait_for_results`. * A trigger only fires for the published version. Editing the draft does not change what runs. * In Rewst Classic, every workflow in the org appeared as an action under the Default pack. You dropped it in like any other action, and we called these subworkflows. * Add a [Call Workflow](https://docs.rewst.help/rewst-documentation/rewst-classic-to-new-rewst-help/pages/27ztelCxRCWn8lmMEtvh#call-workflow-tasks.call_workflow) node to handle all inclusion of other workflows in a workflow. Pick the workflow from a list or resolve its ID with an expression at run time. You can pin a specific published version or follow the latest. Inputs come from the child's declared inputs, and the outputs you map come back under `TASKS..result`. Set the node's timeout with the child's longest path in mind. Publish as node (in Configure) is new. It exposes a workflow as a reusable node in child organizations' palettes, with only the inputs you choose to show. * In Rewst Classic, all workflows must be built with a Start action. * There is no Start node when building workflows. The [trigger node](/rewst-documentation/documentation/automations/nodes/nodes-triggers.md) is the entry point, and the publish check will not pass a workflow whose trigger is disconnected. * In Rewst Classic, you could copy and paste or duplicate actions. * Copy and paste and duplicate action have no equivalent yet. Add the desired node again to replicate it. * Real-time multiplayer editing of the Canvas is not available. The last save takes priority and overrules others, so coordinate with teammates who edit the same draft. * In Rewst Classic, you drew a transition, opened it, and picked On Success, On Failure, Always, or Custom Condition with a Jinja expression. A task's Advanced tab chose Follow All or Follow First, and Follow First had an Edit Transition Order button. Transitions also carried Data Aliases. * In new Rewst, [a transition is just a line](/documentation/automations/workflows/task-transitions.md). Connections no longer have conditions or an order. Its meaning comes from the *port* you drag it from:
| Node kind | Ports you can drag from | | -------------------------------------------------------------------------------- | ------------------------------- | | Triggers, transforms, JOIN, Delay | out (blue) | | HTTP, integration actions, Call Workflow, org variable and datastore actions, AI | success (green), failure (red) | | If / Else | true, false | | Switch | one port per case, plus default | | Logic: Loop | each, done | | Wait for Webhook | pending, out, timeout, failure | * Translating what you used to do: * On Success → drag from the green success port. * On Failure → drag from the red failure port. * Always → connect both success and failure to the same next node, with a JOIN: Any in front of it (see section 3). * Custom Condition → there is no condition on the line. Add an If / Else node (a field, an operator, and a value, or a template that renders true or false) or a Switch node, and drag from true / false or the case ports. * Follow First → use a Switch. It follows exactly one case, in order, and always needs a default connection. * Follow All → this is the normal behavior. Every connection from a port fires. * **"**This node is deterministic and cannot fail." You'll see this message when you try to add a failure transition to an If / Else, Switch, Object Builder, Transform Array, Code Expression, Delay, or JOIN node. Those nodes compute a result from their inputs and do not call anything external, so they have only an out (or true / false) port. Only nodes that talk to the outside world, such as HTTP, integrations, sub-workflows, and AI nodes, have a failure port. * In Rewst Classic, an action with several incoming transitions waited according to Task Transition Criteria Sensitivity — "How many parent tasks need to be satisfied? 0 = All tasks". The default waited for all of them. * A node runs once for every incoming connection that fires. If two branches both connect to the same "send summary" node, the summary sends twice, and the first time it runs, the second branch's data does not exist yet. The fix is a JOIN node: | You want | Use | | ------------------------------------------------------------------ | ---------------- | | Wait for every branch, then continue once | **JOIN: All** | | Continue from whichever branch arrives, or reconverge an If / Else | **JOIN: Any** | | Wait for N of M branches | **JOIN: Quorum** | | Continue once per arriving branch, in arrival order | **JOIN: Stream** | * The editor offers to insert a JOIN when you draw a second connection into a node, and the publish check reports `E105_MISSING_JOIN_NODE` if you skip it. Use JOIN: Any after an If / Else or Switch, because only one of those branches will ever arrive. A JOIN: All there would wait forever, and the publish check flags it as `E108_JOIN_ALL_EXCLUSIVE_BRANCHES`. * In Rewst Classic, you read a task's result as `{{ TASKS.task_name.result }}` or `{{ TASKS.task_name.result.result }}`, published it under a friendlier name with Publish Result As, and defined Data Aliases on transitions (`my_alias -> {{ RESULT }}`) to get `{{ CTX.my_alias }}`. Workflow inputs and form fields arrived in `CTX`. A Data Aliases panel listed every alias in the workflow. * Every node has an *alias*, shown at the top of its configuration panel. \ ![](https://3039672601-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh0G0em3PH6aDfPoI5XpN%2Fuploads%2Fpg0V4cN8P80RYf0gtRNy%2FScreenshot%202026-09-22%20at%2011.44.47%E2%80%AFAM.png?alt=media\&token=c562f87a-4f16-48ee-a4ee-d8e3372d5f98)\ The alias is derived from the node name until you edit it, and it must be unique across the workflow. There is no Publish Result As and no Data Alias on a connection. The alias is the published name. Where the result lands depends on the kind of node:
Node kindRead its result asExample
HTTP, integration actions, Call Workflow, datastore, org variable actionsTASKS.<alias>{{ TASKS.get_ticket.data.summary }}
Object Builder, Transform Array, Code Expression, Aggregate Values, JOINCTX.<alias>{{ CTX.ticket_summary.total }}
AI nodesAI.<alias>{{ AI.classify_ticket.result }}
Workflow inputs and form fieldsINPUT.<name>{{ INPUT.customer_email }}
Trigger payloadTRIGGER.<kind>{{ TRIGGER.webhook.body.id }}, {{ TRIGGER.form.submission.email }}
Org variablesORG.VARIABLES.<name>{{ ORG.VARIABLES.default_timezone }}
Loop item and counters (inside a loop only)ITEM, LOOP{{ ITEM.id }}, {{ LOOP.index }}
Link to the current runWORKFLOW.runUrlsee Add the current run to a message
\ Notes for Classic builders: * `RESULT`, `RESULT_DATA`, `TASK_DATA`, `USER`, and `REQUEST` do not exist. Read the node by alias instead. * Send HTTP Request stores parsed JSON at `TASKS..data` and raw text at `TASKS..body`. Use `.data` for JSON. * `CTX` and `TASKS` are shared by the whole run, the same as Classic. A value written inside a loop is overwritten on the next iteration. * The Browse Fields button on any field opens a picker of upstream values. It replaces the Current, Tasks, Published, and Organization variable tabs. * `ORG.VARIABLES.` works the way it did. `ORG.` now refers to organization details such as `ORG.name`, not to variables, so always write `ORG.VARIABLES.`. ## Templates * In Rewst Classic, every field was full Python Jinja2. You could write `{% if %}` blocks, call `.split()` and `.startswith()`, use operators, and switch a field to PowerShell with `#ps`. * [Templates](/rewst-documentation/documentation/automations/automation-assets-templates-and-scripts.md) run on a Jinja-compatible engine, not Python, and fields come in two sizes. Ordinary fields accept variable paths and filters only: ```jinja {{ TASKS.get_user.data.mail | lower }} {{ INPUT.first_name }} {{ INPUT.last_name }} {{ ITEM.tags | join(", ") }} ``` They do not accept operators (`+`, `>`, `and`), `{% if %}` or `{% for %}` blocks, method calls, or named filter arguments. If you type one, the field shows an error that names the fix. [Code Expression nodes](https://docs.rewst.help/rewst-documentation/rewst-classic-to-new-rewst-help/pages/27ztelCxRCWn8lmMEtvh#code-expression-ctx.code_expression) accept full Jinja: blocks, operators, math, `selectattr`, `groupby`, and multi-line templates. The result is stored at `CTX.`, and you reference it from ordinary fields afterward. * Three habits to unlearn: * String methods are filters. `s.startswith("#")` becomes `s | startswith("#")`. `sep.join(list)` becomes `list | join(sep)`. Porting classic template expressions has the full table, including `replace` and `split`, which silently return different results if you call them as methods. * The context is read-only. `list.append(x)`, `dict.update(...)`, and in-place `sort()` fail with "Template context is read-only." Build a new value instead: `list + [x]`, `dict | combine({...})`, `list | sort`. * No PowerShell in templates. `#ps` is not supported. Shape data in a Code Expression, and keep PowerShell in script assets. * Before you reach for Code Expression, check whether a no-code node does the job. The Object Builder builds an object from picked fields and filters. Transform Array filters, sorts, maps, deduplicates, groups, flattens, and batches lists. Aggregate Values sums, counts, and averages. Those nodes are faster, checked before publish, and preview their output while you edit. ## Saving, versions, and publishing * In Rewst Classic, Save wrote the live workflow immediately. History was a list of patches you could revert. Publish meant publishing to a Crate or as a cloneable item. * The Workflow Builder keeps one draft per workflow and saves it automatically one second after you stop editing. The status line shows Unsaved changes, Saving…, and Saved. A draft never runs in production. * Publish checks the draft and promotes it to a numbered version. Published workflows are what triggers, forms, and other workflows call. * The publish check reports problems by code. Errors block publish. Warnings do not. * Versions opens the version history with a side-by-side diff and a Revert to this version button. * Configure holds what Classic kept in the settings tabs: Inputs, Outputs, Default run variables, Time savings, Limits, Retries, Concurrency, Tags, Security, Observability, Metadata, and Publish as node. * There is no Edit JSON tab. The publish check catches most of what you used the JSON view for, and the Versions diff shows you exactly what changed. ## Loops * In Rewst Classic, you set With Items and Items Concurrency on a task's Advanced tab. The task repeated per item, and `collected_results` gathered every iteration's result for you. * Loops are a node. [Add Logic: Loop](https://docs.rewst.help/rewst-documentation/rewst-classic-to-new-rewst-help/pages/27ztelCxRCWn8lmMEtvh#loop-ctx.logic_loop), set Array to loop over (a template such as `{{ TASKS.list_tickets.data.value }}`), and optionally Batch Size, Concurrency, Delay between iterations, and Max Iterations. The loop has two ports: * Each runs the body once per item. Nodes on this path see `ITEM` and `LOOP.index`, `LOOP.isFirst`, `LOOP.isLast`. * Done runs once after the last item. Nodes here see `LOOP.total`, `LOOP.successCount`, and `LOOP.failureCount`. Don't draw a connection from the end of the body back to the loop. The loop iterates on its own. Results are not collected for you. There is no `collected_results`. If you need every iteration's output, either accumulate it in a Code Expression with `{{ (CTX.results | default([])) + [ITEM] }}` at Concurrency 1, or skip the loop and use Transform Array, which maps and filters a whole list in one step. ## Test and read a run * In Rewst Classic, the Run dialog picked a trigger, an organization, and inputs. The Execution Panel showed each step's Raw Input, Rendered Input, and result, and animated the path on the canvas. Mocking was per task (Mock this task, Mock Result). The Live Editor page tested a template against a pasted context. * The Test button in the Workflow Builder Canvas toolbar combines what to run and how to run it. Its label tells you both, for example Preview Draft.
| Mode | What happens | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Mock** | Mock data, no API calls. | | **Preview** | Real reads, mocked writes. Integration writes return a simulated receipt, and datastore and org variable writes are discarded when the run ends. | | **Run** | Full production execution. The first live run of each workflow asks you to confirm. | * You choose Draft or Published in the same control. Mock and Preview replace per-task mocking. There is no per-node mock toggle. * When a test starts, the Canvas switches to run view. Nodes light up as they execute, taken connections show which port fired, and a run bar at the bottom lets you scrub back through the run. Click any executed node for step details: status, duration, error, Resolved input (Classic's Rendered Input), output, and the context values the step changed. Nodes inside a loop get a Previous / Next iteration stepper. The Watch panel pins up to 20 `CTX` or `TASKS` paths and shows their value at the scrubbed step. * Recent runs in the toolbar replays any of the last 10 runs on the Canvas. Failed steps that Rewst can attribute show a Likely cause line telling you whether the failure was a credential, a platform timeout, or the external service, so you know whether to change the workflow at all. Template testing moved into the editor. Object Builder and Transform Array preview their output as you edit, and the template preview in a node's panel renders an expression against run data. * [Runs](/rewst-documentation/documentation/automations/runs.md) are now available in a separate menu as well as directly from the Workflow Builder. ## Timeouts, retries, and failure * In Rewst Classic, Task Timeout and Workflow Timeout were the only limits. Retries existed in the engine but not in the builder. Failure handling was an On Failure transition. A failed run could be Re-Run from the start. * Node timeout lives in each external node's advanced settings. Defaults: 60 seconds for integration, HTTP, and datastore nodes; 120 seconds for AI nodes; 600 seconds for Call Workflow. * Workflow timeout is in Configure > Limits. The default is 24 hours. A node cannot extend past the workflow's remaining time. If a node's timeout cannot fit in what is left, the run is blocked before the node starts and the run details say so. * Retries are configured for the whole workflow in Configure > Retries: max attempts, backoff, and what to do when attempts run out. There is no per-node retry. * Failure routing works the way you expect. Connect the red failure port and the run continues down that path. Leave it unconnected and the run fails at that node. A node that times out follows its failure port too, if you connected one. * Cancel is available on the run page. Start over by testing again or re-triggering. ## Run for another organization * In Rewst Classic, Run as Org on an action's Advanced tab took an organization ID and ran that one action in that context. * Add a [Set Org node](https://docs.rewst.help/rewst-documentation/rewst-classic-to-new-rewst-help/pages/27ztelCxRCWn8lmMEtvh#set-org-ctx.set_org). Everything downstream of it on that branch runs for the chosen child organization, picked by name or by the vendor's external ID through the integration's organization mappings. The override covers the rest of that branch and each loop iteration separately; in a straight line, add another Set Org to switch back. Credentials stay owned by the organization that created them, so the parent's connection is used with the sub-org's identifiers. * Integration fields tagged as organization identifiers can be left blank. Rewst fills them from the active org's mapping, and a value you type wins. Bulk run in the editor toolbar runs a workflow across many child organizations at once. ## Organization variables * In Rewst Classic, it was `{{ ORG.VARIABLES.name }}`, with a Use as Default checkbox to cascade a value to managed organizations that had not set their own. * `{{ ORG.VARIABLES.name }}` reads the same way. A child organization's own value wins, then the MSP's value. Each variable has a **Category—** secret values are masked in lists— , a scope, and a per-organization overrides panel that replaces Use as Default. Workflows can also read, set, list, and delete variables through the [Org Variables nodes](/rewst-documentation/documentation/automations/nodes/nodes-data.md) in the Data tab of the library, including a cascade option when setting. ## Forms * In Rewst Classic, a Form Submission trigger picked the form. Fields arrived in `CTX`. * You [bind from the form side](/rewst-documentation/documentation/automations/forms.md#binding-in-forms). In the Form Builder, the workflow binding section selects a published workflow and its [Receive Form trigger](/rewst-documentation/documentation/automations/nodes/nodes-triggers.md#receive-form). The form's Submit button stays disabled until a binding exists. Fields arrive as `INPUT.` or `TRIGGER.form.submission.`, and `TRIGGER.form.submitter` tells you who submitted: name, email, roles, organization. Form drop-downs can still be filled by a workflow through the [Trigger: Request Options](/rewst-documentation/documentation/automations/nodes/nodes-triggers.md#request-options) trigger. ## Workflow output * In Rewst Classic, the Output Configuration tab listed field names and Jinja values. * Configure > Outputs declares each output with a name, a type, and a binding you pick with Browse Fields. Subworkflows and forms consume those declared outputs. For a synchronous webhook response, the body comes from a transform node whose alias is exactly `output`, which writes `CTX.output`. ## Move workflows between organizations * In Rewst Classic, you could clone (optionally Synchronized), per-row export, and Import Bundles. * [Crates](/rewst-documentation/documentation/crates.md) are the way to move a workflow. Promote a workflow to a crate from the editor, publish it to the Marketplace, and install it in the target organization. The install wizard handles the workflow, its forms, and its dependencies together. * Clone, synchronized clones, JSON export, and JSON import are not in the editor today. If you relied on those for a one-off copy, a crate does the same job with a version history attached. ## Crates * In Rewst Classic, you unpacked a Crate to set it up in Rewst and access all the assets contained within the Crate. * Unpacking is now known as *installation* instead. You install Crates, which installs the assets within those Crates into your Rewst instance. * In Rewst Classic, workflows unpacked from Crates couldn't be modified easily. * The Rewst Agent can now modify all installed Crate workflows. Modified workflows will be marked as such in the total workflow list. ## App Builder * In Rewst Classic, App Builder was recommended for individuals with existing HTML and CSS coding skills. * Now named [Apps](/rewst-documentation/documentation/apps.md), this portion of the Rewst platform is much more user-friendly, and requries no existing coding knowledge to use. It still operates on the concept of [pages](/rewst-documentation/documentation/apps/app-pages.md) for its contents. * The Rewst Agent builds your app for you, and has a much wider array of components, now called [*blocks*](/rewst-documentation/documentation/apps/blocks.md), to choose from to meet your requirements. ## Renamed and replaced: quick reference table for terms | Classic Rewst | Rewst | | --------------------------------------------------------- | ------------------------------------------------------------------------------ | | Action / Task | Node | | Transition with On Success / On Failure / Always / Custom | Connection from a **success**, **failure**, **true** / **false**, or case port | | Follow First + Edit Transition Order | **Switch** node | | Task Transition Criteria Sensitivity | **JOIN: All / Any / Quorum / Stream** nodes | | Publish Result As, Data Aliases | Node **alias** | | `{{ TASKS.x.result }}`, `{{ RESULT }}` | `TASKS.`, `CTX.`, `AI.` | | Form fields in `CTX` | `INPUT.` | | With Items, Items Concurrency, `collected_results` | **Logic: Loop** with **each** / **done**; accumulate explicitly | | `noop` task for Jinja-only steps | **Object Builder** or **Code Expression** | | Delay Workflow For Period / Until Date | **Delay** | | Await Webhook Request | **Wait for Webhook** | | Sub-workflow from the Default pack | **Call Workflow** | | Run as Org | **Set Org** node | | `TEMPLATE.` templates | Automation assets, rendered by **Render Template Asset** | | `#ps` PowerShell templates | Not supported; use Code Expression or script assets | | Mock this task | **Mock** and **Preview** run modes | | Rendered Input | **Resolved input** in step details | | Live Editor page | Inline node and template preview | | Save (live) + patch history | Autosaved draft + **Publish** + **Versions** | | Workflow Timeout / Task Timeout | **Configure → Limits** / node **Timeout (seconds)** | | Time Saved | **Configure → Time savings** | | Trigger Criteria | **If / Else** after the trigger | | Activate Trigger To Run For | **Run For** on the trigger | | Clone, Import Bundle, Export | Marketplace crates | | Edit JSON tab | Not available | \ \
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.rewst.help/rewst-documentation/rewst-classic-to-new-rewst-help/rewst-platform-translation-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.