---
name: hermios-automations
description: Use when the user wants recurring CRM work using their Codex account, or wants to create, edit, inspect, run, activate, deactivate, or debug Hermios server workflows that create tasks, update fields, send emails, or call webhooks.
---

# When To Use

- "when a deal moves to Won, create an onboarding task and email the customer"
- "every Monday, create follow-up tasks for deals with no activity"
- "what automations do we have running"
- "why did the new-lead workflow fail yesterday"
- "turn off the renewal reminder workflow"
- "run the lead-qualification workflow on Acme now"

# Steps

First choose where the work runs. For recurring work that should use the user's Codex account, read `../../references/codex-workflows.md` and use the host's scheduling tools when available. Do not create a Hermios server workflow for that request. For record-triggered or server execution, follow the steps below.

1. Read `../../references/tool-discovery.md` and `../../references/safety.md`. Call `list_skills`, then `load_skills` for the workflow skill before any workflow tool, and `learn_tools` on the tools you will use.
2. Inspect first with `execute_read_tool`: `list_workflows`, then `get_workflow_current_version` for the workflow in question.
3. New workflow:
   - Use the requested trigger, conditions and ordered steps. Ask only for missing details that prevent a useful draft.
   - Build it with `create_complete_workflow`, then `validate_workflow`.
   - The workflow stays a draft. Activate with `activate_workflow_version` only after the user says yes.
4. Edit an existing workflow: `create_draft_from_workflow_version`, change it with the step, trigger, and edge tools, `validate_workflow`, then confirm before activating.
5. Run now: get the active version with `get_workflow_current_version`, show the user what the workflow will do, and after a yes call `run_workflow` with that version id (and `payload`, for example `{ "id": "<recordId>" }` for a record-based manual trigger). Then poll `get_workflow_run` until it finishes and report each step's result.
6. Debug: `list_workflow_runs` filtered to the workflow, then `get_workflow_run` for failed runs. Report the failing step, its input, and the error in plain language, then propose a fix.

# Rules

- Trigger variables: a MANUAL trigger on a single record receives the record itself, so steps read `{{trigger.id}}`, `{{trigger.name}}`, and so on (never `{{trigger.record.id}}`). A bulk-records trigger receives `{{trigger.<objectNamePlural>}}`. A later step reads an earlier step's output as `{{<stepId>.<field>}}`.
- A workflow step that creates a task or note must also link it to a record (for example the trigger record, via a `taskTarget` / `noteTarget` create step). Workflow-created tasks and notes have no owner, and without a link nobody can see them.

- Any workflow step that sends email or calls an external URL must be shown to the user word for word before activation.
- Use Hermios record triggers and server schedules when the user wants server execution. For work using their Codex account, use a Codex schedule when supported by the host. These are separate execution environments with separate permissions and availability requirements.
- When the user requests ChatGPT-plan execution, read `../../references/chatgpt-plan.md`. Drafting through Codex uses the user's Codex session; an AI step running later in Hermios does not inherit that plan. Keep unsupported AI execution unavailable and never silently choose API billing.
- Report the workflow with a link on the user's workspace subdomain: `https://<workspace>.hermios.app/object/workflow/<id>`.