Features

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 😅

Would like to add the bulk tag update option for organizations. Just like the bulk tag update option present in workflows. Thanks!

Allow the Confirmation Email action to be customizable: branding, sender, etc.

Would be very helpful if I can select multiple tasks with their transitions and copy those to the clipboard.

When re-running a workflow, currently you only get the option of re-running the entire thing (and any sub-workflows individually). If you run a hefty workflow and find out you did not adequately prepare a prerequisite (such as org variables), it is sometimes detrimental to re-run the whole flow if it does not have checks for pre-existence of certain items. A solution (that's not just changing how your flows are written) would be to allow selective re-running of tasks in the workflow. The one thing I haven't quite figured out in my head is how to properly deal with context. In the situation I outlined above, you would technically want all context to persist besides the missing pre-requisite so that the workflow functions as intended with the new value. IIRC, the current functionality of re-running does not allow that. This may need to be paired with some sort of context editor before the confirmation of the re-run, but folks smarter than me can probably come up with a cleaner solution.

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

We have come across a few scenarios where we need to create a child flow just to set a delay between items that we are looping through to avoid failure responses because of request limit reached or service unavailable errors. Most APIs have time based request limits, so if we can set a delay between items in the With items, that would lessen the need for a child flow only for one action and the sole purpose of putting a delay in between items.

For scenarios where a workflow has kicked off many executions by mistake, it would be helpful to have the ability to mass-cancel them.

Custom Integrations v2 are coming along very nicely! Sadly, there are still quite a few authentication scenarios that stop it from working perfectly with some APIs. Salesforce, for example, expires Access Tokens/sessions based on activity (or lack thereof). Additionally, they (for some reason) choose to not include expires_in as a property of the Access Token response, leaving us in the dark as to when it will die. Temporarily, I've worked around this specific issue by blasting Salesforce with queries on a cron timer. For the end-game of CIv2, I think a dedicated mechanism to account for this will be required. I see two features that could fix this: Forced periodic refreshes : Allow us to set a period on which Rewst will forcefully refresh the tokens. For example, if we know Salesforce is set to 24h, then we can expect the expiration to happen at around the 12 hour mark of no activity. Forcefully refreshing every 8 or 12 hours could keep authentication live here. On-Failure refreshes : Allow us to enable attempted token refreshes on task failure. If a task from the integration fails with a 40# error, we should refresh the token ONCE and retry. Subsequent failures can be considered failures. This allows for the integration to mitigate authentication some failures as they appear, also dodging any potential unmonitored expiration issues. Let me know your thoughts, folks :)

We need the ability to embed/provide forms publicly. We have a lot of forms that are used by outside vendors and/or new clients that are not yet in AAD. For example, we have a Site Survey form that 1099 field techs complete. Another example, a new client that is in the process of onboarding may not have AAD as part of our onboarding is to migrate them from hosted Exchange/etc. We still need to provide them with forms for: Company Details, Billing Details, Sites/Locations, Employee Listings, Letters of Agency and many more.