The customer cancels an implementation project. The project owner closes the main item, but the agent keeps creating weekly preparation tasks and sending reminders about missing data. The organization decided to stop, but the automation does not know which work that covers.

An Atlassian Community question describes a parent cancellation that reaches stories but not their subtasks. Agents produce the same gap across systems: closing the visible parent does not show every dependent action has stopped.

Define what the cancellation covers#

Start with the authoritative decision, the affected project or order, its effective time, and who made it. "Pause onboarding while we confirm budget" and "cancel the contract" have different consequences, and the agent must not infer a commercial cancellation from a paused technical task.

A customer cancels one regional rollout while continuing two others. The agent stops that region's preparation tasks and reminders, preserves completed deliverables, and leaves the shared account review intact, since a blanket cancellation would damage ongoing work.

Model dependencies in business terms. A task belongs exclusively to the canceled project, supports several projects, or stays necessary after cancellation, such as returning customer data under the agreed process. These relationships determine what happens next.

Prepare a cancellation change list#

Dependent work	Proposed treatment	Reason
Unstarted exclusive task	Cancel through its normal workflow	Its purpose has ended
Active external action	Inspect current state and stop where possible	It already has effects
Scheduled reminder	Disable the specific future delivery	No further request is needed
Shared task	Retain and remove only the canceled dependency	Other work still relies on it
Completed artifact	Preserve under retention rules	History and obligations remain

Have the responsible owner review material consequences. The user's request usually authorizes the cancellation, and the agent still has to resolve scope. Do not turn the review into approval of every harmless read.

Use the destination system's cancellation state when one exists. Deleting tasks erases the reason work stopped and complicates a later audit or restart. Reports should distinguish a canceled state from successful completion.

Check actions already in motion#

An email can already have left, an export can be running, or another team can be acting on a handoff. The agent inspects those states and reports what can still stop. It never says "everything canceled" when an externally visible action has already completed.

Cancelled work stops, and the agent reports what had already gone out.

For a running operation, use the normal stop mechanism where authorized, then verify the result. A cancellation request does not prove the operation ended. If the outcome is unknown, identify the operation for the owner and stop issuing cancellation commands.

Update future triggers as well as current tasks. A scheduled routine that recreates canceled work makes the next morning look like a new request, so the routine checks project state before producing another task or message.

Recover cleanly if work resumes#

A resumed project needs a fresh decision about which canceled tasks still matter. Do not replay old reminders or revive obsolete instructions; keep the cancellation history and build the new plan from current conditions.

If the wrong task was canceled, restore it through the supported workflow and tell its owner. Inspect whether downstream actions relied on the mistaken state, and repair the relationship rule that selected it as well as the visible status.

Test cancellation with nested tasks, a shared dependency, a pending approval, and a reminder about to fire, and check the next scheduled cycle. Success means the canceled purpose generates no new work while valid independent work continues.

The final update separates acknowledgment from verification: dependent items with confirmed cancellation, any action already completed, the unresolved operation, and the retained shared work, so another team does not cancel it again.

Deixic's pause control changes an agent's status and does not cancel an in-progress tool call, and action history shows what routed work ran. Business cancellation still needs the project's explicit scope, so keep your chosen agent working from it.