Features

We would like to be able to allow workflow retention greater than 30 days. 120 days is the target.

There are some APIs the require a JWT or token to be generated from the client ID and secret and passed as the authentication via a header. It would be nice if the custom integration could be setup to generate the JWT and then regenerate it at expiration. This would help us avoid having to create workflows and additional header entry for each call. An example is the "x-av-sig" header for Avanan: https://www.avanan.com/hubfs/MSP/documents/Smart-API-Documentation/master/Avanan_SmartAPI_Reference_Guide.pdf

Allow employees to work within the managing org's workspace to create workflows for clients, but not have access to managing org's tenant.

While I do love the new versioning and change logs; having to do an individual change log for every single press of the save button when that's required totest anything feels a bit extreme. Especially as a new user that requires a bit more trial and error. I would love the ability to indicate that I am going to be working on a workflow to add functionality that would encompass changes over a set time frame instead of each individual save. For example I put a workflow into maintenance mode for 2 hours and all changes during those 2 hours are logged but I am only prompted to explain the log changes once the workflow is taken out of maintenance mode. All changes during that time can be attributed to the maintenance mode itself.

Add integration to Hatz AI, to allow usage of multiple AI models.

Please include an option to set the retention policy manually. We would like to create our Orgs with the max 30 days retention policy

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

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.

Currently available approval methods (Email, Teams, etc.) do not have an authentication layer. It is assumed that the recipient is allowed to approve whatever is being sent their way. The approval is just a simple webhook that does not output any information, which makes auditing difficult. As an example, if email forwarding is setup when a user is on vacation, an approval could end up in the wrong hands. Having the ability to send an approval, but also authenticate would be extremely helpful, as currently there is no way to determine who approved something. Ideally, specifying a specific list of Rewst users who can approve something on a per workflow basis, along with outputting who approved it, would make changes much easier to track.

I was tasked with looking into Secrets Management for our APIs and realized that it would be secure and beneficial if Rewst allowed for connecting with a secrets server (1Pass Connect for example) and using the vault items to access the credentials and only have them at runtime. How this could look: User configures vault as its own integration (since a good amount use REST). (Maybe have a box that denotes it as a vault integration?) The vault integration then is leveraged when setting up other integrations (example: Datto, Ninja, Huntress, etc) by allowing the user to select to use the vault -> use dynamic options generator to list IDs and Names of items (no values of credentials) -> when this configured integration is then called, it reaches out to the secrets server to prevent auth from being reviewed in logs and prevent leakage. This would also help with rotating credentials in line with current best industry standards and prevent stale API keys, stolen credentials, etc as well as minimize impact on labor time when needing to rotate keys for whatever reason.