Skip to main content
An Automation groups the Agents and Queues that run one process, and is what the Duvo app shows for that process. Once your team has moved to Automations, every new Agent and Queue belongs to one, and duvo automations is how you create and inspect them from the terminal.
On a team that hasn’t moved to Automations, these commands return a 403 error: “This team hasn’t moved to Automations, so it has no automations to work with.” Agents and Queues on those teams stand alone and are created without --automation-id.

​
Create an Automation

Creating an Automation also creates its first Agent. The --json response carries both IDs, automation.id and first_agent_id. Set up that first Agent rather than creating a second one.

​
Create Agents and Queues inside it

Pass --automation-id when you create a Queue or another Agent:
To keep a process together, pass the same --automation-id to every Agent and Queue in it. To add an Agent or Queue that already exists, use add-agent or add-queue.

​
List and inspect Automations

Add --json to any command for machine-readable output.

​
Change an Automation

duplicate creates “Copy of <name>” with the live Agents, Queues and routing. Your own triggers and schedules are copied switched off; Cases and Run history are not copied.
remove-agent and remove-queue delete the Agent or Queue, not only its membership. delete stops the Automation’s Agents and Queues from dispatching. All three prompt for confirmation; pass --yes to skip the prompt in scripts.
When you build a process from the CLI, each step depends on the one before it:
  1. Connections. Check duvo connections list --type <slug> for every service the Agents use, and connect what is missing. See Managing Connections.
  2. Automation. duvo automations create --name <name> --json.
  3. Queues. duvo queues create --automation-id <automation-id>, then a Case schema and labels. See Cases and Queues.
  4. Agents. Create the remaining Agents with --automation-id, attach their integrations, pin a Connection to every slot that needs one, and link them to their Queues with duvo queues link-agent. Pass --enable-trigger when you link a consumer; without it, its Case trigger starts switched off.
  5. Policy. Answer the questions the Agents read. See Policy.
  6. Case triggers on. Run duvo agents case-triggers list <agent-id> --json for each consumer and check that enabled is true. If it is false and pending_change is set, your team saves Automation changes to a draft, and the trigger only switches on when someone clicks Make active in the Automation’s header in the Duvo app. Until then, a test Case stays Pending.
  7. Test Run. duvo runs start --agent <agent-id>, or add one test Case to the Queue, and check the result.
  8. Schedule, created paused. Create it with --disabled and an explicit timezone, then turn it on once the test Run is right:
Approval requests from a scheduled Run go to the person who created the schedule. See When to Ask a Human.

Policy

The typed setup answers an Automation’s Agents read at run time.

Cases and Queues

Case schemas, Case search, and Queue labels.