Features

The new dashboard for tracking workflow failures is awesome, but it would be great if there was a way to put a workflow in a "dev/testing" mode while it is actively being worked on so the success percentage isn't skewed by failures during development.

We would love the ability to update details of workflows, specifically the time saving value, from within a workflow.

Ninja is an RMM, but it also has a ticketing system. Setup User Onboarding, User offboarding, and other crates to work with Ninja as a PSA.

Would be great to have another file upload form field that accepts a variety of files, such as images. This would allow a user to attach a screenshot to a ticket via a support request form.

In building out workflows that have With Items, sometimes I want to do something with each item in the list and I have to create that, then back out and create a sub workflow, relink that to the main workflow and set the parameters. It would be much nicer if I could just create a With Items action and then right click - Convert to Subworkflow Alternatively some way to create a subworkflow from the workflow screen as opposed to opening a new tab or backing out of the current workflow. Something like being able to right click on a blank space and create a subworkflow.

It would be extremely valuable to offer Rewst instances for personal, non-commercial use by developers and engineers at organizations actively using the platform. A few key reasons this makes business sense: Stronger Internal Champions: When team members get to explore Rewst organically outside of structured work hours, it deepens their connection to the platform. This personal engagement often translates into stronger internal advocacy when an organization is evaluating whether to continue with Rewst or explore alternatives. In contrast, if those same users are also familiar with other platforms (e.g., n8n, Power Automate) because they can experiment with them freely at home, it puts Rewst at a disadvantage. Accelerated Onboarding for New Clients: New orgs are more likely to see faster time-to-value when their team includes devs who’ve had the opportunity to tinker with Rewst outside of a business context. Many of the people who naturally excel at building in Rewst are tinkerers at heart — when given the freedom to explore, they almost always will. Encouraging this kind of unstructured experimentation fosters faster learning, deeper comfort with the platform, and a stronger overall automation culture within the organization. Intrinsic Motivation Fuels Adoption: Speaking from personal experience — I likely would have ramped up far faster in Rewst had I been able to experiment with it for personal projects. Now that I’ve spent meaningful time in the platform, I want to use the skills I’ve developed beyond work-specific automations. Encouraging that level of personal investment strengthens the bond between your users and your platform. To manage cost and ensure fair usage, instances could be limited in execution volume, frequency, or concurrency — just enough to prevent abuse or strain on infrastructure while still being incredibly useful to the average automation enthusiast. This isn’t just a perk for devs — it’s a long-term growth strategy. Rewst becomes more than a tool we use at work — it becomes the one we prefer to use everywhere. —Sincerely, A guy who just spun up n8n at home only because I couldn’t do the same with Rewst 😅

as a dumb user, I want to put junk in a folder to organize it.

Example Use Case : We have a bulk update licences form and to give them the option to select users manually, assign based on an existing licence the users have or replace a licence with another, I have 1 Option Gen that can pull back all the licences a company has to cover all of these options, but so all the drop downs are labelled correctly for the users to follow it I need to to make 5- 6 dropdowns calling the same option gen based on the option they pick (Posted on behalf of client)

Allow us to create groups that we can assign roles to in Rewst. For example "Forms" group would have the Forms role only. "Engineer" could have read-only, "Manager" could have member etc. This would also help keep the list of users cleaner by nesting users within those groups.

As I dive deeper into the mystical realms of REWST organization structures, I’ve had a revelation—nay, a vision! What if we added a third tier to our hierarchy? Picture this: Parent Organization – The mighty MSP overlord, the all-seeing eye, the supreme ruler of the REWSTiverse. Child Organization – The client, loyal subject of the Parent, but with a rebellious streak and a penchant for independence. Grandchild Organization – The customer sites. These are the wildcards. The rogues. The Han Solos of the REWST galaxy. They follow the rules... unless they don’t. Why a Third Tier? Because reality is messy. Tools like RMM, Auvik, and other site-specific applications don’t always play nice when everything is lumped into one big happy family. Sometimes, you need to say, “Hey, this config is just for Site A, not the whole dang client!” With a Grandchild tier, we can: Assign tools and integrations at the site level. Keep configurations clean and scoped. Avoid the dreaded “Why is this alert firing for every site?” scenario. The Power Dynamic Let’s talk governance, because every good empire needs rules: Parent Org: The Emperor. Sets the laws of the land. All defaults, flows, and variables cascade from here. Child Org: The Governor. Can override the Emperor’s laws with local edicts (a.k.a. variables and flows). Grandchild Org: The Rebel Base. They do what they want. If they define their own variables or flows, they take precedence. If not, they fall back to the Child, and then the Parent. It’s like inheritance, but with more drama. TL;DR: Let’s build a third-tier org structure in REWST: Parent → Child → Grandchild. It’ll make tool integration cleaner, governance more flexible, and give us the power to manage chaos like pros.