How Do You Manage Sales Tasks and Follow-Ups in Mautic?

Keep each next action attached to its deal

Manage sales follow-up by recording a concrete task against the deal it advances. Give that task a useful title, a due date, an owner, and enough context to make the next action clear. Review the task whenever the pipeline is reviewed, then update the same record as the work changes.

Deal Flow provides this structure through its DealTask entity. The Revenue Operations plugin associates each task with a deal, while the deal record can also carry separate notes. That keeps the action and its supporting context close to the pipeline record instead of relying on an informal list outside the deal workflow.

DealTask fields and REST operation paths checked August 29, 2026 against the canonical product specification. Authentication options were checked against the Deal Flow API reference.

Use the documented task record as the boundary

The canonical product specification defines these fields on DealTask. Their names are a capability boundary, not a REST request-body schema.

Create a task with the documented deal endpoint

The create route in the canonical product specification nests the task under the deal. Resolve the target deal ID first, authenticate with Mautic OAuth2 or Basic Auth, then send the create request to the documented endpoint.

POST /api/dealflow/deals/{id}/tasks

1. Identify the deal. Use the deal ID in the route so the task is associated with the correct pipeline record.
2. Prepare supported task values. Start from the documented entity fields, but follow the request contract for your installed version instead of treating the entity list as a JSON example.
3. Authenticate and send the request. Use the Mautic API authentication method already configured for the integration.
4. Read the deal after creation. The documented deal response includes associated tasks and notes, giving the automation a way to confirm the deal’s current follow-up context.

The canonical product specification names the create operation but does not publish its JSON body or response schema. Keeping that distinction explicit prevents an automation from depending on guessed fields or validation behavior.

Update the existing task under the same deal

When an existing task needs to change, use the update route from the canonical product specification with both identifiers. The specification names the operation but does not enumerate which fields are mutable.

PATCH /api/dealflow/deals/{id}/tasks/{taskId}

1. Carry both identifiers. Store the deal ID and task ID in the automation state that schedules the update.
2. Send fields accepted by the installed version. The canonical product specification names the update operation but does not define its PATCH body or partial-update semantics.
3. Read the deal again. Confirm the associated task data rather than assuming the update succeeded from the request alone.

This API-first pattern gives automations a documented create operation and a documented update operation without depending on an undocumented task screen or button.

Build the pipeline review around next actions

A useful pipeline review is a decision cadence, not another feature to configure. Use the documented task fields as the shared checklist and make one clear decision for each active deal.

1. Before the review, gather the task records. Bring the title, due time, owner, status, and priority into the review view or report your team controls.
2. Check the next action against the deal. Confirm that the task still advances the deal’s current stage and that its due date remains realistic.
3. Update the record while the decision is fresh. Use the installed version’s task update contract when the review changes the follow-up.
4. Add durable context separately. If the decision needs an explanation, add a deal note instead of burying the reasoning in a task title.
5. End with one accountable next step. The review is complete when the follow-up record states what happens next, who owns it, and when it is due.

A weekly cadence is a common starting point, but the interval is an operating choice. High-velocity pipelines may review more often; longer sales cycles may use a different rhythm. The important part is that each review updates the same deal-linked source of follow-up work.

Keep task records and notification routing separate

The due_at and reminder_at fields are part of the task entity, but the published task endpoint documentation does not define automatic reminder delivery, recipients, timing, or channels. Do not infer notification behavior from those field names.

When the workflow needs deal-change alerts routed to Slack, email, or a phone service, follow the separate Mautic deal notifications guide. It documents the outbound-event and consumer pattern without turning task due dates into an undocumented trigger.

Keep tasks, notes, and timeline reads distinct

Tasks and notes are separate deal-associated resources. A task records the next action; a note can preserve the reasoning, customer context, or review decision that explains it. The documented deal response includes both collections.

The API also exposes GET /api/dealflow/deals/{id}/timeline to retrieve deal timeline events. The current published documentation does not state that task records populate that endpoint, so treat the timeline as a separate read surface rather than promising task activity there.

For the broader record structure, stages, ownership, and buying-committee context, continue with the guide to tracking deals in Mautic.

Continue the deal workflow

• Use Track Deals in Mautic for the complete pipeline record and buying-committee model.
• Use Mautic Deal Notifications for documented alert routing through a consumer.
• Use the Deal Flow API reference for Mautic API authentication options and its published operations.

Frequently asked questions

How do you create a sales task on a Mautic deal?

Authenticate with Mautic OAuth2 or Basic Auth, identify the deal ID, and use POST /api/dealflow/deals/{id}/tasks. The canonical product specification names the operation but does not publish a REST request-body schema, so use the contract documented for the installed Deal Flow version.

How do you update a task that is already attached to a deal?

Use PATCH /api/dealflow/deals/{id}/tasks/{taskId} with the deal ID and task ID. Confirm the accepted fields and response for the installed version because the canonical product specification does not define the PATCH body.

Which fields does the DealTask entity define?

The product specification defines id, title, description, status, priority, due_at, reminder_at, owner_id, and deal_id. It does not publish status or priority enum values, so automations should not invent them.

Does a task due date automatically send a reminder?

The published task documentation does not define automatic reminder or delivery behavior. DealTask has due_at and reminder_at fields, but a notification trigger should not be inferred from those fields. Use the Mautic deal notifications guide for the documented alert-routing pattern.