Versioning, approvals, and automation

Flows are production automation, so Hark treats changing them with the care you would give code: you edit safely, you can require review, you can schedule a change, and you can see exactly what changed and roll back.

Draft and publish

The builder edits a draft tree while live conversations keep running the published tree. Nothing you edit affects customers until you publish. Just as importantly, a run that has already started keeps walking the exact tree it began on, snapshotted at start, so republishing mid-conversation never disturbs someone already in the flow.

Revision history

Every publish snapshots the tree as a revision with an optional change note. The builder's history panel lets you see past revisions and restore an older one into your draft without touching the live version until you re-publish. This gives you a clean undo across publishes, not just within one editing session.

Approvals

A flow can require approval. When it does, publishing a draft does not go live: it creates a pending approval holding a snapshot of the proposed tree. A reviewer approves it (which publishes the snapshot and writes a revision, exactly like a normal publish) or rejects it. This gives regulated or high-stakes teams a review gate on customer-facing automation.

Scheduled publishing

You can schedule a publish for a future time. The proposed tree is held, and a scheduled sweep publishes it once it becomes due, so you can prepare a change for a launch or a maintenance window without staying up to press the button.

Templates

Hark ships a library of official flow templates you can install into your workspace as a starting point (grouped by category), so you do not build every common flow from scratch. Installing a template drops its tree into a new flow you can then adapt.

Experiments

The split node makes experiments first-class. Because a split assigns a visitor to a branch deterministically, the same visitor always sees the same variant, and the chosen variant is recorded so analytics can compare how each branch performed. This is how you A/B test a flow's wording or path and measure which resolves better.

Event-triggered automation and SLA automation

Flows are not only started by a visitor. A flow can subscribe to an event (for example, sla_at_risk, sla_critical, sla_breached, ticket_created, mode_changed, or github_issue_opened). A background dispatch reads the workspace activity trail, maps each event to its kind, and starts every enabled flow subscribed to it. This is what lets you automate on your own operation: nudge a customer when a ticket is created, or escalate automatically when an SLA timer goes critical.

Testing and validation

Before you publish, Hark validates the flow: it checks the tree is well formed, within its size and depth limits, and free of the structural mistakes (like a branch that goes nowhere) that would strand a customer. Validation runs as you build so problems surface early, not in front of a customer.