How To Emulate On-Cancel in Flow Designer

[NicholasC137604]

In Legacy Workflow Editor there was a workflow property that allows us to run on-cancel, which as is designed to allow us to run scripted logic if our workflow was ever cancelled prematurely. This was very useful for situations where we may want to run some sort of script include that could run to update or clean up actions against tasks or change records associated with RITMs. 

As Flow Designer does not have the On-Cancel feature in workflow properties, I am curious to learn how anyone in the community has overcome this limitation.

[Vikram Reddy]

Hi Nicholas,

I would look at this less as “how do I replace Workflow On-Cancel?” and more as “where should cancellation ownership live in a Flow Designer architecture?”

In Legacy Workflow, the workflow engine often owned the full lifecycle. In Flow Designer, I have had better results by moving cancellation handling to the business object lifecycle instead of the flow execution lifecycle.

The architectural pattern is:

A flow performs work.
The record owns state.
A separate cancellation handler owns cleanup.

So instead of waiting for a Flow Context to be cancelled and then trying to run logic inside that same cancelled execution, create a dedicated cancellation path that is triggered by the record state.

Use case 1: Catalog request cancellation

Scenario:
A RITM is cancelled while fulfillment tasks are still open.

Recommended design:
Create a separate record-triggered flow on sc_req_item.

Trigger:
RITM state changes to Closed Incomplete, Cancelled, or your organization’s cancellation state.

Actions:
- Cancel open Catalog Tasks.
- Cancel pending approvals.
- Add work notes explaining why fulfillment stopped.
- Notify assignment groups.
- Release reserved resources.
- Set a cleanup complete flag.

This replaces the old workflow on-cancel behavior, but it is cleaner because cancellation is driven by the RITM state, not by the flow engine.

Use case 2: Change request cancellation

Scenario:
A Change is cancelled after implementation tasks, approvals, or automation jobs have already been created.

Recommended design:
Create a cancellation handler flow on change_request.

Actions:
- Cancel pending approvals.
- Cancel or close open Change Tasks.
- Stop planned automation execution.
- Notify implementers and approvers.
- Add a cancellation summary to work notes.
- Update related deployment/release records if applicable.

If there is an active external automation job, do not assume Flow Designer can stop it automatically. Store the external job ID and call the external platform’s cancel API from the cancellation handler.

Use case 3: Hardware/software provisioning request

Scenario:
A user cancels a request after a license, VM, laptop, or access package was reserved.

Recommended design:
Use a cancellation subflow that reverses reservations.

Actions:
- Release inventory reservation.
- Return license count to available pool.
- Cancel procurement task.
- Cancel shipping task.
- Notify asset team.
- Update entitlement/allocation record.

This is a good example where cancellation cleanup should be reusable, because the same cleanup logic may be called from Flow Designer, a UI Action, a Business Rule, or an integration.

Use case 4: Integration-driven fulfillment

Scenario:
A flow creates records in another system, then the ServiceNow record is cancelled before fulfillment completes.

Recommended design:
Create an integration-safe cancellation handler.

Actions:
- Check external transaction status.
- If external transaction is not started, cancel it.
- If external transaction is in progress, mark ServiceNow record as cancellation requested.
- If external transaction is complete, create a reversal/remediation task.
- Store the external cancellation response.
- Notify the owning team if manual cleanup is required.

This prevents the common issue where ServiceNow says cancelled, but the external system continues processing.

Use case 5: Approval cancellation

Scenario:
A workflow/flow is cancelled while approvals are still requested.

Recommended design:
Do not depend on the cancelled flow to clean up approvals.

Create a record-triggered approval cleanup flow.

Actions:
- Find sysapproval_approver records for the source record.
- Cancel pending approvals or mark them No Longer Required.
- Add a work note.
- Prevent new approvals from being created after cancellation.

This avoids orphaned approvals.

Use case 6: Long-running fulfillment with wait conditions

Scenario:
A flow is waiting for a task, approval, date, or external callback. The parent record is cancelled.

Recommended design:
The cancellation handler updates all child work and sets a cancellation flag. Any long-running flow should check that flag before continuing.

For example:
- u_cancel_requested = true
- u_cancel_cleanup_complete = true

Then before major actions in the main flow, add a condition:
If cancel requested is true, stop or exit.

This gives you a controlled cancellation model instead of relying on the flow context itself.

The core pattern I would recommend:

1. Add explicit cancellation fields if needed

Examples:
- u_cancel_requested
- u_cancel_reason
- u_cancel_cleanup_complete
- u_external_job_id
- u_cleanup_status

2. Create one reusable cleanup subflow per domain

Examples:
- Catalog Cancellation Cleanup
- Change Cancellation Cleanup
- Provisioning Cancellation Cleanup
- Access Request Cancellation Cleanup

3. Trigger cleanup from the record lifecycle

Examples:
- RITM state changes to cancelled
- Change state changes to cancelled
- Task state changes to closed incomplete
- Request stage changes to request cancelled

4. Make cleanup idempotent

The cleanup subflow should be safe to run more than once.

That means:
- check whether cleanup already completed
- check whether child tasks are already closed
- check whether approvals are already cancelled
- check whether external jobs are already stopped
- log what was skipped vs what was changed

5. Do not build critical cleanup around sys_flow_context

From an architecture standpoint, sys_flow_context is the execution artifact. It should not be the business control point.

The business record should drive the cancellation outcome.

Where I would still use Business Rules:

Use a Business Rule when cancellation must be enforced immediately or transactionally.

Examples:
- prevent cancellation if implementation is already completed
- require cancellation reason
- block cancellation by unauthorized users
- set cancellation metadata before update
- prevent state changes after cancellation

Use Flow Designer when cleanup can happen asynchronously.

Examples:
- close tasks
- cancel approvals
- notify groups
- call external cancel APIs
- update related records

A clean architecture would look like this:

Main fulfillment flow:
- handles normal fulfillment
- checks cancellation flag before major steps
- writes progress to the record

Cancellation trigger flow:
- listens for cancelled state
- calls reusable cleanup subflow
- records cleanup result

Cleanup subflow:
- cancels child work
- cancels approvals
- stops/reverses external actions
- updates audit notes
- marks cleanup complete

Script Include:
- contains reusable cleanup functions if logic is complex
- can be called from Flow, Business Rule, UI Action, or integration

In short, I would not try to reproduce Legacy Workflow On-Cancel literally. I would design cancellation as a first-class business process.

That gives you better auditability, better retry behavior, cleaner integration handling, and less dependency on the internal state of the Flow Context.

Thank you,
Vikram Karety,

Octigo Solutions INC