Documentation

Document / describe the subflows within a workflow so we can quickly see the whole tree of linked flows without having to manually check. For example something that would list out the tree of subworkflows that could be used within a flow, such as if we execute flow ABC, that references DEF, GHI and JKL, and then from JKL it also calls MNO, for example.

I’d like to put forward a small but impactful request regarding how deprecated crates and workflows are communicated, especially when development or maintenance has stopped. At present, when a crate or its associated workflows are deprecated, it can be difficult to identify which components are still actively maintained—particularly in cases where the same workflow name appears across multiple crates. This can lead to confusion, wasted troubleshooting time, and uncertainty about which version to rely on. Suggestion: When a workflow or crate is no longer supported or has been superseded, please consider prefixing the title with DNU – (Do Not Use) or something similarly clear. This small change would make it much easier for us to: Quickly identify deprecated workflows in our environment Avoid accidental usage of unsupported components Confidently migrate to actively maintained alternatives This would be especially helpful for synced workflows used across multiple crates, where duplicate names can make it tricky to tell what’s still safe to use.

Customer has a collection of python scripts and would like more detailed information about how to store and execute scripts using Rewst. We currently have the video explaining how to use Rewst with Powershell. They would like something similar but with Python instead of Powershell.

There is a lack of supporting documentation, especially diagrams, around how your partner tenant's Rewst and Rewst App interact with the Customer tenants when workflows are executed. Partner Center has a pretty explicit Relationship -> Granted Roles -> Roles assigned to specific group or users visual, and supporting logs. There is not the same level of representation of the actual grant to the Application itself to the customer tenant inside Entra ID. This creates risks for providers who need to document their permissions to customers or an auditor, and issues when attempting to troubleshoot problems with the application or GDAP permissions, and communicate effectively with ROC support.

There seems to be a mismatch between what is in the Documentation and what is in the component library. Two examples that I have run into are: the Workflow component isn't actually in the library, and the Template and NumberInput are undocumented. There is also no documentation on using custom components. This is not exhaustive.

It would be handy to have examples of how to use the various filters listed on this page: https://docs.rewst.help/documentation/jinja/list-of-jinja-filters There seems to be more information on how to use these Jinja filters through the inline autocomplete hints in the Jinja editor than there is in the documentation about these filters. It would be nice if there was more information on the syntax, or an example, for using each filter in the documentation.

I would like to keep my automation codes the same as what Rewst does in order to improve readability, and a list of what codes you guys use would go a long way!

https://usea1-008.sentinelone.net/docs/en/overview-of-service-users.html

https://docs.rewst.help/updates/development-updates/august-11th-2023 Hard to ingest this in a automated way.

In rewst you guys only retain 30 days logs which is quite not feasable for cases where there was something wrong done and it was done 2 months back i can not see it, results should be there for as long as i want for auditing