Source: https://docs.cumuluslabs.io/after-call-operations
Content version: 2171a891

# 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 {#flow}

![A cloud flow separating a completed-call path from scheduled review and branching on the outcome](https://docs.cumuluslabs.io/docs-assets/after-call-map.png)

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.

| Input path | Read | Intended result |
| --- | --- | --- |
| Resolved phone run | Source run context and current business record | An accurate CRM update |
| Call requiring review | Source context and the outstanding business operation | An exception/reconciliation ticket |
| Confirmed booking | The actual reservation record | The booking outcome stored in the CRM |
| Unknown business outcome | The transaction's state at the business service | Human review rather than repeating the write |
| Scheduled queue review | Your pending-review service | A review result under a separate task run |

## Define task inputs and outputs {#schemas}

![Cloud execution modes, limits and JSON input/output schemas](https://docs.cumuluslabs.io/docs-assets/after-call-cloud-contract.png)

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 {#event}

![Event and schedule triggers configured on the cloud agent](https://docs.cumuluslabs.io/docs-assets/after-call-trigger-list.png)

![An event trigger mapping scoped source-run fields into the follow-up input](https://docs.cumuluslabs.io/docs-assets/after-call-event-mapping.png)

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:

| Input field | Mapping in this example | Meaning |
| --- | --- | --- |
| `work_type` | `/channel` | The source channel, `phone` here |
| `source_run_id` | `/run_id` | The original run's identity |
| `outcome` | `/outcome/business/value` | The observed business outcome; can be absent/unknown |
| `account_reference` | `/metadata/account_reference` | Context supplied on the original phone 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](/docs/triggers-and-webhooks) for the maintained draft-edit contracts. Publishing makes the trigger part of that version.

## Use a schedule for the queue path {#schedule}

![A weekday review schedule with time zone and explicit input](https://docs.cumuluslabs.io/docs-assets/after-call-schedule.png)

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 {#routing}

![The cloud outcome branch routing resolved, review and booking work to different actions](https://docs.cumuluslabs.io/docs-assets/after-call-routing.png)

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:

<!-- operation:runs.create -->
```json
{
  "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](/docs/reference/runs.create), retain the idempotency key, follow its events and wait for completion before reading [the task result](/docs/reference/runs.result).

## Read an output and its state {#result}

![A cloud task result presented as typed fields and JSON with usage and details nearby](https://docs.cumuluslabs.io/docs-assets/cloud-task-result.png)

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 {#acceptance}

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.