Features

When my workflow tasks require a specific Transition Mode, 90% of the time it's Follow First. I suspect this is the case for others as well. Having to change it from Follow All (and especially when I forget to set it) slows my dev time.

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

Can we get a feature to be able to organize workflows into particular folder for better organising, right now we have to put tags or go through filter for it and its not convenient and not efficient. Its just overwelhmig to see 1000s of wokflows in the workflow tab and everthing is everywhere

The ability to make a Task, name it, add transitions, define variables, Task settings etc. Then be able to add that Task to your favourites list. For example a "Start" Task. It would be called "Start", and have 3 variables defined in an always transition. I can add this to my favourites list. Then when creating a new Workflow, I can add that predefined Task to my Workflow, with all the previously configured settings.

Overview: We’re requesting the introduction of a central event/message bus within the Rewst platform to enable loosely coupled, event-driven automation. This feature would allow workflows to publish events and other workflows to subscribe to those events with flexible filtering. ---- Current Limitations: Rewst currently provides: Completion Handlers: Workflows can trigger other workflows on success/failure, but this creates a tight coupling between workflows and doesn’t allow filtering or conditional logic based on event content. Webhook Triggers: While useful, these require explicitly targeting a workflow and do not support decoupled broadcasting or internal event reuse. These approaches require hardcoding relationships between workflows, which limits scalability, reusability, and maintainability. ---- Proposed Enhancement: Introduce a central internal event bus, where: Any workflow can publish an event to the bus (e.g., user.onboarded, ticket.closed, backup.failed), optionally including a payload (e.g., JSON with metadata). Other workflows can subscribe to events via a trigger that filters by: Event name/topic (e.g., wildcard or prefix support) Attributes in the event payload (e.g., event.customer == "Acme") ---- Example Use Cases: A provisioning workflow publishes user.provisioned. Several other workflows listen for this: One sends a welcome email. One provisions access to a specific app only if department == "Finance". A monitoring process emits job.failed. A responder workflow only triggers if severity == "critical". --- Benefits: Enables loosely coupled, reactive automation. Reduces rigid workflow chaining and hardcoded logic. Improves reusability by decoupling logic across domains. Supports scalable, modular architecture aligned with modern event-driven design. --- Optional Future Enhancements: Add event history/replay for observability and debugging. Support external systems publishing to the internal bus or consuming from it. UI for exploring active events and their consumers.

Currently, Rewst supports .split() as a function. It might be helpful to add split as an official Jinja filter — simply as an alias to the existing function. This would support users who are newer to Rewst or who prefer writing expressions with filters instead of function calls. Current usage: my_string.split(',') Proposed alternative: my_string | split(',')

It would be handy to filter out the noise and filter by certain workflow tags on the results page.

We currently handle failed workflows using a workflow completion handler that logs jobs, sends alerts etc. Currently we have to set this up for each workflow once its in a ready state. It would be great to be able to set a rule to run a workflow completion handler on all workflows with a certain tag or something similar.

Overview: We are requesting a native queueing system within the Rewst platform—similar in concept to AWS SQS—to support decoupled, event-based workflows with built-in failure handling, retry logic, and message buffering. Current Capabilities and Limitations: Rewst already supports: Completion Handlers: Useful for chaining workflows, but tightly coupled and inflexible. Webhooks: Effective for triggering workflows externally, but require explicit targeting. Sub-Workflows: Helpful for reusability and modular design, but they execute synchronously and do not provide buffering, retry, or asynchronous decoupling. These features are powerful but don't offer the resilience, queuing, and flow control needed for high-volume or failure-prone use cases. -- Proposed Enhancement: Introduce a first-class internal queue system that allows workflows to: Push messages to a named queue, with an optional payload. Trigger workflows based on messages in the queue, processing them individually or in batches. Include visibility timeouts, retry attempts, and dead-letter queues for persistent failures. Optionally support message delay, FIFO ordering, or filtering based on message content. --- Example Use Cases: A data sync workflow pushes jobs to a queue for downstream processing. If one job fails, it is retried automatically after a delay. A webhook receives 1,000 requests in a short burst—these are queued and processed at a controlled rate by a consumer workflow. A provisioning workflow emits tasks to a queue (provision.task) for systems like M365, Entra ID, or AWS, allowing consumers to act independently and retry failures without coordination. --- Benefits: Improved reliability: Work is not lost on failure—automated retries and DLQs provide resilience. Better decoupling: Workflows don’t need to know who will consume their output. Load smoothing: Handle event spikes without overloading the platform. Simplified error handling: Avoid the need for complex retry loops or delay logic within workflows. Reusability: Standardised queue triggers can be reused across workflows or accounts. --- Optional Enhancements for Future Iteration: Queue metrics and monitoring: e.g., message count, retry stats, error rates. Manual requeueing or DLQ inspection in the UI. Ability to publish messages from external systems into Rewst queues via webhook or API.

Allow for use of Jinja templating inside the Task Transition Criteria Sensitivity field. This will allow us to have varying sensitivities depending on previously defined workflow variables.