Automated Workflows
Workflows (Flows) let your agent complete multi-step tasks reliably. Instead of a single answer, a Flow can collect information, call systems, and respond with a clear outcome.
What is a Flow?
A Flow is a structured set of steps (nodes) connected by logic. It can:
- Ask follow-up questions.
- Call a Connector to fetch or update data.
- Branch based on conditions.
- Escalate to a human when needed.
Flows are ideal when you need consistent, repeatable actions rather than a single free-form reply.
Flow types
Applied supports two types:
- Conversational: interactive steps that talk with the customer.
- Operational: background steps that run without sending messages.
Operational Flows are useful for silent updates like writing a ticket note or syncing data after a conversation ends.
Flow lifecycle
Flows can be Draft, Active, or Archived. Only Active flows run in live conversations.
Start a Flow from an Activity Event
Use the Activity Event trigger when an external customer or business event should start an Operational Flow. Send the event with the Create event API, then configure the Flow’s trigger conditions.
name and description are human-readable labels for the customer’s timeline.
metric.metric_name is the machine-readable event type matched to configured
Signal names and used for analytics and Flow conditions. Custom metric
properties are also available to conditions;
for example, metric.additional_properties.cart_id becomes
properties.cart_id in the Flow condition builder. Applied resolves or creates
the supplied contact and makes it available to the Flow trigger. A contact with
at least one of remote_id, email, or phone is required because every event
is stored as an Activity on a contact timeline.
For durable event idempotency, send both top-level remote_platform and
remote_id. Replaying the same event identity returns the original Activity
without emitting the metric or starting matching Flows again. Reusing that
identity with different event content is rejected. If either field is omitted,
each request is treated as a new Activity. The nested metric.deduping_key is
deprecated. It remains accepted for backward compatibility and deduplicates
only metric emission for 24 hours.
Use the bulk events endpoint to ingest multiple events in one request. Results
are returned in request order as success or error; an invalid item does not
prevent valid items from being processed. Created events and idempotent replays
return the same response representation.
The object reference fields are optional:
| Field | When to send it |
|---|---|
metric.metric_object_type + metric.metric_object_id | Use these only when the event should derive metric properties or values from an existing Applied object. The ID must be an Applied UUID for a Conversation, Message, Ticket, FlowRun, or Agent. |
metric.context_object_type + metric.context_object_id | Use these when the metric should be stored against an existing Applied object for analytics. The ID must be an Applied UUID for the matching object type. |
For a cart abandonment event from an ecommerce platform, you can usually omit
both object-reference pairs. Put the platform name and external event ID in the
top-level remote_platform and remote_id fields, and put domain identifiers
such as checkout, cart, or order IDs in additional_properties.
Build your first Flow
- Open Agents -> Flows.
- Click New Flow.
- Add nodes like Agent Response, Connector, or Escalate.
- Connect nodes with paths to define the logic.
Use branches to handle different outcomes (for example, “order found” vs “order not found”).
Test and monitor
Use the Flow builder to run sample inputs and confirm outputs. In Monitor, review flow runs and failures to see which paths were taken and where handoffs occurred.