Features

On the results page if a section fails, or just doing simple testing, it would be really nice that after the workflow has been saved again that you could just click a button to retry that specific action with the changes instead of having to run the entire workflow all over again. This is helpful when outputting information in a certain format/template but need to test to see if it's correct instead of running a 10 action workflow with subflows as well each and everytime.

I'd love to see a few more options for the markdown callouts. Currently we have :::warning | Red :::tip | Purple :::note | Yellow But I'd love to see three new options. Blue, Green, and Grey. Perhaps it could be :::info | Blue :::success | Green ::: (blank) | Grey If we aren't opposed to breaking changes the naming convention of these callouts could be altered to match Github's markdown alerts. https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#alerts

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

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

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.

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.

I would like the ability to define object types once and re-use them within custom integrations. Custom object types should be usable anywhere an "Object" currently is usable (JSON body, output schema, array member, etc). The attached screenshots illustrates why this can be necessary. Imagine defining many API endpoints with nested objects like this, any having many of the object types be repeated. This is quite labor intensive without the option to define custom objects.

We are trying to build out an Onboarding Workflow that will allow us to have a NEW client fill out a webform that will then kick off a process to get onboarding going, including setting up that client in all our various tools. If the client has to be able to login to see a form, then that would mean they have to already be set up in Rewst. An unauthenticated form option to allow for such a scenario would be nice.

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

Several APIs make use of other Content-Type values than "application/json". For example: application/<example>+json (still JSON, just a different Content-Type value) application/x-www-form-urlencoded application/xml application/graphql text/xml text/plain other binary formats I propose the following: Move Headers before Body in Action and detect usage of Content-Type header in the Action, or add a specific input for Content-Type (remember to allow for any custom Content-Type and usage of encodings, for example "Content-Type: application/x-www-form-urlencoded; encoding=utf-8") Add option to hide headers and parameters with a default value (making them defined in the Custom Integration and not modifyable) Change "JSON Body" to "URL-encoded Body" whenever "Content-Type" is set to "application/x-www-form-urlencoded", presenting the user with a key-value editor Change "JSON Body" to "Body" whenever any other content-type is used, allowing for a text input with Jinja2 support Notes on "application/x-www-form-urlencoded": Defined in RFC 1738 Both keys and values are always strings Values can be interpreted by servers as different types Keys can be interpreted by servers to create objects/arrays Due to different implementations on key formatting for arrays by various servers, I suggest either leaving keys as plain strings or supporting different key encoding schemes: 1. duplicate keys are treated as arrays "array=...&array=..." 2. brackets "array[]=...&array[]=..." 3. indexed brackets "array[0]=...&array[1]=..."