Flows & Automation

Flows let you automate actions across Hydra. Describe what you want to happen, and the AI helps you design the trigger, conditions, and action steps. You test it before it goes live.

What a flow does

Every flow has three parts:

1. Trigger — The platform event that starts the flow (e.g. "a new ticket is created")
2. Conditions — Optional filters that must be true for the flow to run (e.g. "priority is High or Urgent")
3. Steps — Actions that execute in order when conditions are met (e.g. "add an internal note", "send an email")

Available triggers

Flows can be triggered by events across the platform:

Ticket events: created, updated, resolved, closed, assigned

Lead events: created, promoted (Lead → Contact), source attached

Contact events: created, account changed, demoted to Lead

Account events: created, lifecycle stage changed (Prospect / Active / At Risk / Churned), health score changed

Onboarding events: plan created, milestone completed, plan completed

Conditions

Conditions filter which records the flow acts on. Examples:

• Ticket priority equals "urgent"
• Account lifecycle stage is "Prospect"
• Account health score is below 40

Multiple conditions use AND logic — all conditions must be true.

Available actions

Designing a flow

1. Go to Flows and click New Flow
2. Give the flow a name and description
3. The AI design chat opens. Describe what you want in plain language:
   • "When a high-priority ticket is created, add an internal note saying 'High priority — respond within 1 hour' and notify the team via webhook"
4. The AI asks clarifying questions, then generates a structured flow plan
5. Review the plan — trigger, conditions, and steps are clearly shown
6. Click Test in Sandbox to validate before going live

How the AI uses your company profile

The flow designer reads your Company Profile in the background — your industries, priority objects, and business objectives. These are latent priors: the AI uses them to recognize patterns in what you describe, but it will never lead with a menu of pre-baked flows or suggest a flow you didn't ask for. You describe the problem in your own words; the AI listens, then matches its response to patterns that fit your business. If your problem doesn't match any prior, you just get a flow designed for exactly what you asked.

Editing Business objectives on /settings/company-profile is the strongest way to widen the set of flows the AI will fluently design for you. Each objective is a short outcome phrase, one per line: "Route enterprise leads to sales within 15 minutes", "Surface expired permits before inspection day", "Close the loop on every negative CSAT".

Testing in sandbox

The sandbox runs a dry-run simulation using real data snapshots from your account. It checks whether conditions evaluate correctly and whether action inputs are valid.

Test results show each step with pass/fail status and any errors. If something is wrong, continue the design conversation to fix it, then re-test.

Auto-running tests

When the AI designer emits a complete plan, Hydra automatically runs a dry test in the same chat — you don't need to click "Run test" first. Results stream back into the conversation as a test results card the moment the run finishes. If the plan fails the dry test, the existing Fix and Re-test button appears so you can ask Sonnet to diagnose and revise.

Auto-test only fires for standard flows. Pre-built flows (like KB Re-ingest) skip this — they have their own Activate flow that doesn't go through the test surface.

Verifiability badges

Each success criterion the AI proposes is tagged with one of two verifiability tiers:

• ✓ Auto-verifiable (green check) — the dry test can prove this from the captured action output. Example: "send_email step routes to support@example.com" — Hydra checks the captured would_send.to field. If it matches, ✓; if it doesn't, ✗.
• 👤 Needs your verification (amber person icon) — this criterion involves real-world delivery, AI quality, or downstream outcomes that no dry run can confirm. Example: "the email reaches the recipient without spam-flagging" — only a real send to a real inbox can prove that. The criterion still appears in your test results, but Hydra marks it 👤 instead of ✓ to signal you need to verify it yourself after a live test.

When the designer emits a plan with one or more user-tier criteria, it'll proactively call them out: "I can auto-verify 2 of 3 criteria. Criterion 3 (the email reaches the inbox) needs your verification in production after a live test — keep, edit, or drop it?" You can edit the wording, drop the criterion, or leave it — Hydra won't fail the dry test on a 👤 criterion.

After a dry test passes, if any 👤 criteria are present, Hydra shows a banner above the decision panel: "Some criteria need your verification — consider running a live test before deploying." That's your cue to click Run live test and validate the real-world half of the flow before going to production.

Deploying to production

Once you're satisfied with the test results, click Deploy to Production. The flow becomes active and begins listening for its trigger events.

You can always go back to editing — click Let's keep editing to continue the design conversation.

Execution history

Every flow detail page has two tabs in the right-hand panel: Flow Plan (the design + latest test result) and Execution History (a running log of every time the flow has been exercised). The tabs sit side-by-side at the top of the panel — click to swap the view.

Execution History includes both test runs and live runs. Each entry shows:

• Triggered-at timestamp and whether it was a Test, Fix Retest, or live run
• Trigger event and the entity that fired it
• Status (passed, failed, running, skipped)
• Expand to see every step's result — captured outputs (email recipient + subject, webhook URL, field diff, etc.), errors, and any AI diagnosis if a Fix and Re-test was run

When you click Fix and Re-test on a failed flow, Hydra's fixer now reads the last 10 entries from this history — not just the most recent test — so it can spot patterns (e.g. the same step failing across multiple runs) and propose a better revision.

Use Execution History to debug unexpected behavior, confirm a flow is working as intended after deploy, or review what the fixer changed in a previous retest.

Flow ideas to start with

• "When a new ticket is created with urgent priority, send me an email"
• "When a Lead is promoted to a Contact, create a welcome ticket and add a lifecycle event on the Account"
• "When an onboarding milestone is completed, add a note to the account"
• "When an account health score drops below 40, create a ticket titled 'Account at risk'"