Continue a phone workflow with a cloud task

Start a cloud task after a support call to reconcile a refund, update the CRM or create a review ticket. Give the task its own agent so you can test and release follow-up changes separately from the phone conversation.

The screenshots use synthetic flows and records. You supply the CRM, review-queue and ticket services. Select an image to view it at full size.

Give follow-up work its own definition

The cloud agent accepts either a phone-run follow-up or a scheduled review-queue request. It reads the relevant business record, classifies the work, takes the permitted action and returns a structured result.

Separating this agent from the phone conversation lets you change the follow-up logic independently. Each task still executes a publication and gets a run ID, events, external-action evidence and usage.

Define task inputs and outputs

Choose task or background modes for work that returns an output rather than maintaining a live caller conversation. Define the input fields and the result your integration expects. Set a deadline and maximum turns so work cannot continue indefinitely.

In this example, work_type distinguishes phone from review_queue. A phone task carries a source_run_id, account reference and observed outcome; a scheduled request carries a queue name. Some source fields can be null. Your flow must handle missing context explicitly before calling a business endpoint.

Return fields such as source_run_id, next_action and needs_review. A field proposing the next action is not proof that the action was performed. Use the external-action receipt and business response for that distinction.

Start work after a selected agent's run

Choose the source agent, source channel and event type. Map the fields the next agent needs. Cumulus event-trigger mappings read a projection of the source run:

The mapping scope includes run ID, agent ID, channel, outcome, disposition, phone-run dynamic variables and phone-run metadata. Phone numbers are not part of that projection. A field that is missing maps to null, so the target input schema and flow must account for it.

Choose run.ended when the work depends on the terminal run outcome. Choose analysis.updated when it needs completed analysis. Those events represent different readiness points: a run can end before all derived output is available.

See triggers and webhooks for the maintained draft-edit contracts. Publishing makes the trigger part of that version.

Use a schedule for the queue path

For scheduled work, provide a valid cron expression, time zone and input. This example passes { "work_type": "review_queue", "review_queue": "pending" }. It does not fabricate an originating call ID for work that was not started by a call.

Keep the schedule input compatible with the publication's input schema. Test a daylight-saving transition, an empty queue, a slow queue service and a task that reaches its deadline. Decide which outcomes require a human notification.

Route on facts and handle uncertainty

Read the actual business state before updating a downstream record. If the source call ended with an uncertain refund, query/reconcile that transaction first. The cloud task is not permission to send the same write again under a new identity.

Use one named action for a CRM update and another for a review ticket. Their endpoints own business validation and transaction idempotency. The platform records the task's decisions, send attempts and receipts with its run identity.

You can exercise the same input path directly through the API while developing:

{
  "channel": "cloud",
  "agent_id": "after-call-operations",
  "mode": "task",
  "input": {
    "work_type": "phone",
    "source_run_id": "22222222-2222-4222-8222-222222222222",
    "account_reference": "DEMO-42",
    "outcome": "manual_review"
  },
  "metadata": { "workflow_reference": "DEMO-42" }
}

Use Start a run, retain the idempotency key, follow its events and wait for completion before reading the task result.

Read an output and its state

The result view presents returned fields alongside the same run history you use for phone execution. Check whether the output is ready, unavailable or purged. A completed task with no retained output needs a different response from a failed task with an application error.

For the production integration, preserve both the source phone run ID and the cloud task run ID. The first explains the conversation; the second explains what the follow-up agent did. Join them using the context you passed, rather than assuming that two tasks with a similar transcript are the same business operation.

Acceptance before enabling automation

Test matching and non-matching source agents, missing metadata, unknown business outcomes, event redelivery, unavailable business services and incompatible target schemas. Use mocks for repeatable agent tests and a separate authorized integration run for the real endpoints.

Enable the trigger on a tested live publication. Review the first tasks’ source context, action receipts and results to confirm that the mapping and downstream updates work as intended.