Emit the PROCESS/*/RESUMED event when a failed process instance returns to Active after "Skip" in Process Inspector

Summary

When a BPD process instance is in the Failed state, an administrator can recover it from Process Inspector. The Dynamic Event Framework (DEF) reports the two recovery paths differently:

• Retry failed steps: the instance returns to Active and DEF emits */*/BPD/*/PROCESS/*/RESUMED.
• Skip the failed task: the instance returns to Active and continues normally, but DEF does not emit */*/BPD/*/PROCESS/*/RESUMED.

PROCESS/*/FAILED and ACTIVITY/*/FAILED are emitted correctly when the failure occurs. After a Skip, an application that consumes DEF events never learns that the instance left the Failed state. Today, the only way to get a PROCESS/*/RESUMED event after a Skip is to manually Suspend and then Resume the instance.

Requested enhancement

Emit a process-level event whenever an instance moves from Failed back to Active through Skip. The preferred option is PROCESS/*/RESUMED, consistent with the other recovery action.

If reusing PROCESS/*/RESUMED is not acceptable, any of these would also meet the need:

• a new, documented DEF event for the Failed → Active transition after Skip
• an option to enable the event
• documentation that states the required follow-up step, for example Suspend and Resume

The behavior should be available in Business Automation Workflow on traditional WebSphere and in Workflow Process Service runtimes.

Current vs. expected behavior

Steps to reproduce (as reported)

1. Subscribe to */*/BPD/*/PROCESS/*/RESUMED and the FAILED events in DEF.
2. Start a process instance with a task that fails. PROCESS/*/FAILED and ACTIVITY/*/FAILED are emitted.
3. In Process Admin Console > Process Inspector, open the failed instance and Skip the failed task.
4. The instance becomes Active and continues, but no PROCESS/*/RESUMED event is emitted.
5. For comparison, Suspend then Resume of the same instance does emit the event.

Why it matters

Integrations that mirror process instance state into an external system, such as monitoring, audit or reporting, rely on DEF events. They subscribe to PROCESS/*/FAILED and PROCESS/*/RESUMED to track the Failed state. After a Skip, the external system keeps showing the instance as Failed while the real instance is Active. The manual Suspend/Resume workaround depends on administrators remembering an extra step, and Skip is often used as a last resort.