Workflows

Mental model

A workflow is Calypso’s project-scoped routing and automation graph. It is the system that decides, for each inbound request, whether to:

• respond automatically (messages, branching, knowledge)
• collect context (choices/inputs)
• handoff to the Shared Inbox for human handling

Workflows are designed so projects can evolve routing over time without changing how operators work day-to-day in the Shared Inbox.

Workflow library (project-scoped)

In Workflows, you manage multiple workflows per project. A few rules matter operationally:

• you must explicitly pick a Default workflow
• a default workflow cannot be deleted
• workflow routing can only be enabled when the default workflow is enabled

Default workflow (source of truth)

The Default workflow is the canonical entrypoint for inbound routing when workflow routing is enabled. Treat it as production infrastructure:

• Change control: avoid frequent, unreviewed edits—small changes can affect the entire inbound stream.
• Determinism: keep early branching conditions simple and explicit.
• Safe handoff: ensure there is a clear path to human escalation (Shared Inbox handoff / Inbox handoff) when automation can’t resolve.

Workflow routing (project-level)

The workflow routing toggle controls whether inbound requests use:

• Workflow routing (default workflow)
• Legacy routing

Calypso uses guardrails to prevent enabling workflow routing without an enabled default workflow.

Shared Inbox handoff

The Inbox handoff step routes a conversation into the Shared Inbox so a human can take over. In operational terms, handoff is the boundary between:

• automation (workflow execution)
• human ownership (assignment, departments, tags, resolution in Shared Inbox)

Some project settings only matter when:

• workflow routing is enabled
• the default workflow is enabled
• the default workflow contains an Inbox handoff node

Handoff design principles

• Escalate with context: aim to hand off with enough customer intent captured so an agent can resolve quickly.
• Minimize ambiguous states: if a conversation is handed off, avoid continuing to send automated messages that compete with human replies.
• Operationalize assignment: once visible in Shared Inbox, use assignment and departments to keep concurrency controlled and routing predictable.

Hours behavior

Workflows exposes hours controls that affect how routing behaves:

• Bot hours gate: outside configured hours, the bot can send an off-hours message and skip workflow execution
• Post-handoff hours messaging: sends an hours message after an Inbox handoff, once the conversation is visible in the Shared Inbox

Choosing the right hours control

• Bot hours gate is for controlling whether automation should run (and what happens when it shouldn’t).
• Post-handoff hours messaging is for setting expectations after the conversation is operationally in human queues.

Departments and routing intent

While departments are configured under Project, workflows are where you typically encode routing intent (e.g. which lane a request belongs to) and then hand that request off into Shared Inbox for execution.

In practice:

• workflows determine who should handle this (Sales vs Support vs Billing)
• Shared Inbox determines who is handling it right now (the current assignee)

Operational rollout (recommended)

When adopting or changing workflows, treat it like a production change:

• Start with a narrow scope: enable workflow routing only when the default workflow is enabled and reviewed.
• Validate the handoff path: confirm that edge cases (unknown intent, unsupported request) still land cleanly in Shared Inbox.
• Align the operating model: define project conventions for assignment, departments, tags, and closure so the human layer is consistent with the routing layer.