A failed Fusion run can stop the scenario: alert on deactivation

A Workfront Fusion product update now exposes deactivated and deactivationReason alongside execution failures. A team that alerts only on the latest failed run can miss the bigger operational fact: the scenario may no longer run at all. That distinction matters when the scenario moves leads, work requests or customer events.

Diagnose the boundary

Start with an inventory of active scenarios, their owner, expected cadence and the business process each supports. Use the documented execution listing to identify failed runs and deactivations across the organization; retain execution ID and scenario ID. For a failure, inspect the paginated details before retrieving bundles. Adobe's execution history guide notes that history is limited and recently completed details can still be processing, so build a retry window rather than treating one empty response as success.

Decide the next safe change

Send a deactivation alert to the process owner with the reason and last successful run, then require a human decision about reactivation. A successful restart does not prove that missed source events were replayed. Check the trigger's cursor or source system, quantify the gap and test a bounded backfill. Limit bundle access because module inputs and outputs may contain customer data. Test API credentials, pagination and rate limits in the tenant before promising organization-wide coverage.

Evidence boundary

The October product notice describes the new v3 execution endpoints and deactivation fields. Availability, permissions and polling limits must be confirmed in the target organization.

Adovo’s view

An automation has two states that matter to the business: working and being watched. Detecting a failed execution is useful; detecting a stopped scenario is the actual service commitment. Give every critical flow an owner, a recovery path and evidence that missed work was handled.