Automations

Pomavo now lets you automate repetitive ticket work with a visual graph instead of custom code. You connect typed nodes, let runs execute asynchronously, and keep every workflow scoped to an organization and optionally to a project.

A visual engine for no-code workflows

Automations are built as graphs. A trigger starts a run, data flows across edges, conditions decide which branch is active, and actions make changes back in Pomavo. The run happens in the background, so creating a ticket, adding a comment, or changing a field does not have to wait for every downstream workflow to finish.

Asynchronous orchestration keeps product actions fast

Automations run asynchronously through the automation engine. When a matching event occurs, Pomavo records the work and lets the user-facing action complete without waiting for the graph. The orchestrator seeds the run from the trigger, resolves each node input from connected edges, executes the node, and skips branches that are not active. This design keeps automation powerful without making core ticket operations feel slow.

Triggers cover ticket, comment, link, attachment, sprint, and schedule events

A graph needs at least one trigger. Pomavo ships event triggers for core ticket lifecycle activity and sprint workflow changes. The trigger output gives the rest of the graph the context it needs, such as the ticket, user, comment, link relation, iteration, sprint tickets, or old and new values.

You can use a single trigger for a focused workflow, or use multiple triggers when one automation needs to share downstream logic. In run history, branches that did not start from the active trigger are marked skipped.

Conditions and routers make branching readable

Conditions let you express business rules without writing a service. The DSL Condition node evaluates a Query Language expression against a ticket. The DSL Query node returns a list of tickets, which is useful when the workflow needs to fan out across matching work. Logical nodes combine booleans, and If / Else routes a value to the true or false output while preserving that value's type.

1

template = "Bug" and priority in ("High", "Critical") and assignee is empty

The If / Else node is especially useful because it passes through the value you connect. For example, you can route the same ticket to an escalation branch or a normal triage branch without rebuilding the data on each side.

Actions change tickets, sprints, links, and locks

Action nodes are the part of the graph that writes back to Pomavo. They use typed inputs so you can wire dynamic values from triggers, data nodes, and conditions. For example, Transition Ticket accepts a ticket, a target state, and a Force Transition value. Change Field accepts a ticket, a field, and a value whose type matches that field. Move to Sprint accepts a ticket and an iteration.

Force Transition is useful when an automation is intentionally allowed to bypass normal transition constraints. Keep it explicit in the graph so reviewers can see where the workflow is using elevated transition behavior.

Data nodes provide pickers, constants, extraction, and templates

Data nodes make graphs reusable. You can select organization objects, provide literal values, extract properties from typed objects, and build field values for ticket creation. The editor hides inline config when an input is wired, so a node can start as a constant and later become dynamic without changing its role.

Shared fields and template fields both matter in this model. A Template node provides template context, Get Template Field picks a field from that template, and Change Field writes a correctly typed value to a ticket.

Typed ports make the editor safer

Every node input and output has a type from the Types reference. Primitive types include string, number, boolean, date, and void. Object types include ticket, user, state, transition, iteration, project, link, comment, follow, tag, field, workflow, template, and ticket field. Generic types such as list<T> and type variables such as T let nodes work with many shapes while still being checked.

ForEach, Collect, and Extract unlock list workflows

List workflows are where automations become operationally powerful. DSL Query can find a set of tickets, For Each runs the downstream subgraph once per item, and Collect gathers one value per iteration back into an ordered list. Extract Properties can pull fields from each item as it flows through the loop. List Length can count the resulting collection for reporting, branching, or comments.

1
2

"Sprint" = "Sprint 24" and status != "Done"
order by priority desc

Quotas and tiers keep automation fair

Automation runs are governed by Quotas. Each organization belongs to a tier, such as Basic or Premium, and each tier defines limits for metered resources. Automation runs count against a rolling daily window. Tickets and projects are capped as absolute totals. If an organization exhausts its automation run quota, additional runs are skipped until capacity returns.

Platform administrators can change an organization's tier and inspect usage from the Admin Dashboard. That makes it possible to tune capacity without code changes when a team grows into heavier automation use.

Admin visibility completes the operating model

The automation release includes the administrative pieces needed to run workflows responsibly. Admins can view quota usage, see when automation limits are reached, and inspect underlying background jobs for automation evaluations. Together with typed graphs and run records, this gives teams a clear path from authoring to operations.

Automations turn Pomavo from a ticket tracker into an active workflow system. You can start with simple reminders, then grow into typed branching, bulk list processing, and administrative controls as your process matures.