ATF rollback leaves Flow Designer subflow in Waiting state

BhagyashriS4766 — Tue, 21 Jul 2026 10:28:21 GMT

Issue Description
I have a Flow Designer implementation where a main flow calls a subflow to invoke orchestration.

The high-level flow design is as follows:

A form submission triggers the main flow.
The main flow calls a subflow, which is responsible for calling the orchestration.
Inside this subflow, we use the Call Orchestration action.
If the orchestration call fails, or if a failed response is received from orchestration, the Call Orchestration subflow calls a separate failure handling subflow.
The failure handling subflow creates an SCTASK for manual action.
The failure handling subflow waits until this SCTASK is closed.
On the SCTASK, the user selects an action to take on failure, for example Cancel.
Once the SCTASK is closed, the failure handling subflow reads the selected action and returns it to the Call orchestration subflow.
The Call orchestration subflow, then returns the action to the main flow.
Based on the selected action, the main flow updates the RITM. For example, if the selected action is Cancel, the RITM should be closed as Closed Incomplete.
In normal execution, this design works as expected.

ATF Test Scenario
I am trying to test this failure task logic using ATF.

The ATF test performs the following steps:

Submits the form/request to trigger the main flow.
Waits for the failure SCTASK to be created.
Opens the SCTASK.
Sets the failure action field to Cancel.
Closes the SCTASK.
Validates that the RITM is closed with state Closed Incomplete.

Before ATF rollback, everything appears to work correctly:

The SCTASK gets closed.
The failure subflow moves to Completed.
The Call orchestration subflow completes.
The main flow completes.
The RITM is updated correctly to Closed Incomplete.

Problem
The ATF test runs successfully. The issues happen only after ATF rollback/cleanup completes.

After rollback, I observe the following:

The main flow context is deleted/cleaned up.
The call orchestration subflow context is deleted/cleaned up.
The SCTASK appears again in an Open state.
The failure handling subflow remains in Waiting state indefinitely.
This leaves an orphaned waiting flow context after the ATF test run.

Important Observation
This issue happens only in the ATF scenario.

In a normal/manual execution, once the failure subflow is completed, it does not go back to Waiting state.

I manually tried the following outside ATF:

Changed the SCTASK state back to Open after the failure subflow completed. Result: The failure subflow did not go back to Waiting state.
Deleted the SCTASK after the failure subflow completed. Result: The failure subflow still remained in Completed state.
Deleted the parent subflow context, which is the Call orchestration subflow context.
Result: The failure subflow still remained in Completed state.
Based on this, I do not think the issue is caused simply by the SCTASK being reopened, deleted, or by the parent subflow context being removed. It seems to happen specifically during ATF rollback/cleanup.

Things I Already Tried
I have tried multiple cleanup approaches, but none of them resolved the issue.

Deleted SCTASK and RITM using ATF UI steps and programmatically
I tried cleaning up the records as the last part of the ATF test.
I deleted the SCTASK using ATF UI steps.
I also deleted the RITM using ATF UI steps.
Additionally, I tried deleting the SCTASK and related records programmatically using a cleanup script.
However, even after trying both UI-based cleanup and programmatic cleanup, the failure subflow still appeared in Waiting state after ATF rollback.
Created a custom event for cleanup
I created a custom event that is triggered from ATF as the last step.
The idea was: ATF last step triggers custom event
Custom event runs cleanup script
Cleanup script deletes SCTASK and related failure subflow context
Even with this approach, the failure subflow still remained in Waiting state after ATF rollback.
Modified the flow to remove the SCTASK wait condition
Initially, I thought the issue might be with the failure subflow waiting for: SCTASK state = Closed Complete
So, I changed the flow and removed the wait condition related to the SCTASK state.
However, even after deleting/removing that wait step, the failure subflow still went to Waiting state after ATF rollback.

Because of this, I do not think the Wait for SCTASK state = Closed Complete activity is the actual root cause.

Expected Behavior
After the ATF test completes and rollback runs, all test-created records and related flow contexts should be cleaned up properly.

Actual Behavior
After ATF rollback:

The SCTASK is open again.
The failure handling subflow is in Waiting state indefinitely.
The parent/main flow context is already cleaned up.
The Call orchestration subflow context is already cleaned up.
The failure handling subflow appears to be orphaned.

Question

Has anyone seen similar behavior where ATF rollback leaves a Flow Designer subflow in Waiting state even though the subflow had already completed successfully before rollback?

I would like to understand:

Is this a known limitation when using ATF rollback ?
Is there a better way to clean up orphaned subflow contexts created during ATF execution?
Any guidance, known issue reference, or recommended ATF design pattern would be helpful.

question ATF rollback leaves Flow Designer subflow in Waiting state in Community Central forum

ATF rollback leaves Flow Designer subflow in Waiting state