Features

It would be great if Rewst could offer RoboRewsty as a built-in AI integration option, alongside (or instead of) the current third-party options like OpenAI and Anthropic. Since RoboRewsty is already an in-house AI developed by Rewst, it makes sense to allow users to leverage it directly within workflows without needing to set up and manage a separate OpenAI or Anthropic API key/tokens. Benefits: • Simplifies onboarding no need for users to provision third-party AI accounts • Keeps everything within the Rewst ecosystem • Reduces cost and complexity for MSPs who don't already have an OpenAI/Anthropic subscription • Potentially faster and better optimised for Rewst-specific use cases

In the current state, the generic HTTP request and most of the generic API actions have Headers as an object. This prevents the headers from being built dynamically. This is especially needed for the Graph API and the generic HTTP request as different endpoints often require different headers. This also appears to be an issue with any action that has object as the type for an input variable.

Customer would like an "uninstall crate" button. Desired functionality would allow them to quickly delete all elements unpacked as part of a crate. This is especially important when crates are replaced with new versions. They suggested a wizard that allows the user to view and select all elements of a crate, with a "used in x number of crates" indicator so they could deselect shared sub workflows, and then click "delete all selected."

Summary: We'd like the ability to set task quotas and track task usage at the child organization level to support Automation as a Service (AaaS) offerings. Use Case: As an MSP using Rewst, we want to offer co-managed automation to our customers. This means giving select customers access to build their own workflows within their child org while maintaining visibility and control over task consumption. Currently, there's no way to: Set task limits per child org to prevent a customer from exceeding an agreed-upon quota Distinguish between tasks consumed by our MSP-authored workflows (part of standard managed services) vs. tasks consumed by customer-authored workflows (billable to the customer) Export or report on task usage in a way that supports customer billing Requested Functionality: Task Quotas by Org – Ability to set a maximum task count per child organization, with alerts or enforcement when approaching/exceeding the limit Workflow Ownership Attribute – A way to assign or tag workflows with an "owner" (e.g., MSP vs. Customer) so task consumption can be attributed appropriately, even if the MSP initially authored a workflow on the customer's behalf Usage Reporting by Org/Tag – Ability to export workflow execution counts filtered by child org, workflow owner, or custom tags for billing reconciliation Business Value: This would enable MSPs to productize automation services, create tiered offerings, and bill customers fairly based on their actual usage—opening up a new revenue stream while maintaining control over platform consumption.

It would be great to have the ability to create workflows from GraphQL. Concept would be to automate workflow creation based on requests. (internal request for workflow is approved - kicks off creation of workflow with naming schema, description, and potentially some other core relationships - almost creating a workflow template). Conceptual, would allow stronger standardization and requirements for workflow creation for those in the automation team.

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

Would be nice to be able to save prompts or 'framing' of some kind for RoboRewsty giving it background / framing knowledge like: "We use AutoTask" "here are the statuses mapped to names in our ticketing system" "When I say 'email someone if it breaks' I mean use the contact in such and such an org var", etc etc

I have some unsync'd custom copies of forms from unpacked rewst crates. Id love the ability to either hide the original or limit access to forms in general within rewst to prevent my team from accidentally selecting the original form instead of the updated one.

As of right now, if a workflow has input parameters, and you create a trigger for this workflow, you cannot specify the parameter values that you want to use with a specific trigger. A couple of suggestion are either making separate variables for specific triggers or check the trigger ID in the workflow and do things depending on that. However, I think that this is not exactly a correct approach to this, and what would be objectively better, easier to use and more efficient to use (without creating potential ways to break a workflow) is to just let the triggers have all the workflow input parameters in them. Think of it, like this: a workflow is function, and a trigger is just something that calls a function. You would obviously just call a function with the inputs that the function wants, you wouldn't change the function to see what exactly called it and add a check every time you add another place that calls the function. That's how putting workflows inside workflows actually works, you just call a sub-workflow with the parameters needed and that's it! So, implementing the same behavior for triggers would be nice

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.