Pomavo automation now covers delayed work, recurring work, and the debugging experience you need after a graph runs. This release adds scheduler nodes, forked parent and child runs, a read-only graph debugger, precise timing, shared field tooling, pickers, cloning, creation, linking, and transition actions.
Scheduler nodes defer branches without blocking the run
Most Automations run immediately after an event. Scheduler nodes let one branch run later while the current run finishes now. When execution reaches a scheduler node, the engine snapshots the upstream outputs the deferred branch needs, creates a scheduled instance, and resumes the downstream branch when the configured time arrives.
| Scheduler node | Configuration | Behavior |
|---|---|---|
| Recurring Cron | Cron expression, key, optional repeat and signals | Resumes the downstream branch on a recurring cadence |
| Run After | Key, seconds, optional signals | Resumes the downstream branch once after a delay |
The deferred branch sees the snapshot from fork time. If the underlying ticket changes before resume, the branch still receives the values captured when it was scheduled.
Cron schedules handle recurring operational work
Recurring Cron is for repeated work such as daily triage, sprint hygiene, monthly reporting, or release readiness checks. You configure a cron expression, such as the weekday morning default pattern, and Pomavo creates a fresh resume each time the schedule fires. Because the node is part of the graph, you can feed it dynamic context before the fork and continue with normal typed nodes after the resume.
status not in ("Done", "Closed") and updated_at < d'-14d'
order by updated_at asc
limit 100| Use case | Example branch after resume |
|---|---|
| Daily stale sweep | DSL Query, For Each, Add Comment, Transition Ticket |
| Sprint readiness | Get Iteration, DSL Query, List Length, Add Comment |
| Monthly report | DSL Query, group by assignee, Create Ticket |
| Release follow up | Link matching bugs to a release ticket |
Recurring schedulers continue firing until the automation is disabled or deleted. Use the automation enabled toggle as the operational control when you need the schedule to stop.
Run After supports SLA and follow up workflows
Run After is for one-time deferral. Give it a number of seconds and it resumes the downstream branch after that delay. It is useful for workflows where the right action depends on time passing, such as auto-closing resolved tickets, escalating work that stays in a state too long, or posting a follow up after a customer-facing response.
| Run After input | Purpose |
|---|---|
seconds | Required delay before resume |
key | Identifies the scheduled branch instance |
start_signal | Starts or arms the deferred branch |
stop_signal | Stops or cancels the scheduled branch when your graph says to stop |
A common pattern is to schedule a Run After branch when a ticket enters Waiting for Customer, then stop it if the customer replies or the ticket transitions away before the delay expires. That gives you SLA behavior without making a worker sleep inside the original run.
Stop, resume, and forked parent child runs make time visible
Schedulers are implemented as forks. The parent run reaches the scheduler, records the snapshot, and finishes. A child resume run starts later from the scheduler node and continues the downstream branch. This parent child shape is visible in run history, so you can tell whether a workflow scheduled work, whether that work resumed, and which node path ran after the delay.
Parent reaches scheduler
The graph executes normally until Recurring Cron or Run After is reached.
Engine snapshots inputs
Pomavo records the upstream values needed by the deferred branch.
Parent finishes
The original run completes without waiting for the scheduled time.
Child resumes
A background job restores the snapshot and continues from the scheduler node onward.
| Run relationship | What it tells you |
|---|---|
| Parent run | Which trigger or upstream branch scheduled the work |
| Scheduled instance | When the deferred branch was expected to resume |
| Child run | What happened when the scheduled branch actually executed |
| Stop signal | Why a deferred branch did not continue |
Run history records every node the engine touched
Runs gives every automation execution an audit trail. A run contains a node run for each node the engine touched. Each node run records status, inputs, outputs, duration, and any error. Skipped nodes are expected when a trigger branch did not fire, a condition evaluated false, or required inputs came only from skipped sources.
| Node run field | Meaning |
|---|---|
| Status | Succeeded, failed, or skipped |
| Inputs | Resolved values delivered to input ports |
| Outputs | Values emitted on output ports |
| Duration | How long the node took, now precise enough for sub-millisecond work |
| Error | Failure message when the node failed |
Start debugging at the trigger, then follow the active path. The first unexpected output usually explains the downstream behavior.
The read-only graph debugger mirrors your automation
The run viewer presents the graph as a read-only debugger. You can inspect the exact topology that ran without accidentally changing the automation while you investigate. Node status appears on the graph, and selecting a node opens a side panel with the values and timing for that node. This is especially helpful for typed graphs because you can compare the value that arrived at a port with the type the next node expected.
| Debugger feature | Why it matters |
|---|---|
| Read-only canvas | You can investigate safely without editing production logic |
| Node status styling | You can see the active, skipped, and failed paths quickly |
| Side panel | You can inspect inputs, outputs, duration, status, and errors |
| Structured values | You can expand nested ticket, user, link, and comment objects |
| Contract failures | You can see expected versus actual output shape when validation fails |
Use Inspect nodes when you need to capture the value crossing an edge. After the next run, the run viewer shows the captured value in the same node-by-node history.
Sub-millisecond timing helps find real bottlenecks
Automation graphs often contain many small nodes. Second-level timing is too coarse for a graph where constants, property extraction, comparisons, and routing may complete almost instantly. Run history now records node duration with sub-millisecond precision, so you can separate a fast data node from a slower service action.
Very small durations usually point to local transforms, constants, extraction, or routing. Precise timing also helps you understand ordering when For Each runs iterations in parallel and Collect waits for branch outputs.
Shared fields and migration tooling keep templates consistent
Shared fields are now part of the automation authoring story. Pomavo supports rich field types such as Text, Textarea, Number, Dropdown, Multi-Select, Date, Time, Date & Time, User, and Checkbox. Fields can be required, have default values, include descriptions, define options, enable multi-user assignment, and share tag topics. Shared field migration tooling helps teams move toward reusable fields instead of maintaining disconnected copies across templates.
| Field capability | Automation impact |
|---|---|
| Required and default values | Create Ticket can satisfy template requirements predictably |
| Dropdown and multi-select options | Change Field can write controlled values |
| User fields | Assignments and multi-user values can flow through typed ports |
| Tag topics | Tag-style dropdowns can reuse a shared vocabulary |
| Shared Field node | Automations can select reusable fields directly |
| Migration tooling | Existing template fields can be aligned with shared definitions |
Project, iteration, and sprint pickers make graph configuration concrete
New picker-oriented data nodes make it easier to configure automations without hard-coded IDs. Get Project selects a project. Get Iteration selects an iteration from a project. Template, Get Template Field, Shared Field, Workflow, Get State, Get Transition, Link Type, and User provide the surrounding context needed by actions. These pickers make graphs easier to read and safer to maintain.
| Picker or data node | Output it provides |
|---|---|
| Get Project | Project |
| Get Iteration | Iteration for a project |
| Template | Template, fields, and workflow |
| Get Template Field | Field from a template |
| Shared Field | Reusable field definition |
| Workflow | Workflow |
| Get State | State |
| Get Transition | Transition |
| Link Type | Link relation metadata |
| User | Organization user |
Use these nodes with Nodes and Types as your reference when building graphs that create or move work.
Ticket create, clone, link, and transition actions expand workflow coverage
The action palette now covers more of the ticket lifecycle. Create Ticket creates a new ticket from a template with optional field values and an initial state. Clone Ticket copies an existing ticket with configurable options. Add Link connects two tickets with a selected link type. Remove Link removes an existing link. Transition Ticket moves a ticket to a workflow state and includes Force Transition when the automation is allowed to bypass normal transition constraints.
| Action | Key inputs or options | Output |
|---|---|---|
| Create Ticket | Template, field values, initial state | Signal and ticket |
| Clone Ticket | Ticket, clone fields, clone links, copy status, add clone link, copy attachments | Signal and ticket |
| Add Link | From ticket, to ticket, link type | Signal |
| Remove Link | Link | Signal |
| Transition Ticket | Ticket, target state, Force Transition | Signal |
| Move to Sprint | Ticket and iteration | Signal and iteration |
template = "Bug" and status = "Done" and resolution is empty
set resolution = "Fixed"
comment "Resolution filled during release cleanup."These actions pair naturally with scheduler nodes. A recurring branch can create report tickets, a delayed branch can transition stale work, and a sprint trigger can clone standard follow up tasks for the next iteration.
Scheduling and run history make automations operational, not just expressive. You can defer work, stop it when conditions change, inspect every node after execution, and use shared fields plus richer actions to build workflows that match how your team actually works.
Keep Scheduler, Runs, Nodes, and Shared fields close while you build. They are now the core references for reliable automation operations.