Workflow Lifecycle (activate, deactivate, delete)

Short Description Approval workflows have an active/inactive/deleted lifecycle. This article covers the rules, the implications for existing tactics, and how to make changes safely.

What this article answers

What changes when you activate, deactivate, or delete a workflow.
Why deactivated workflows still appear on existing tactics.
How to avoid orphaned-workflow errors when retiring a workflow.

The three states

A workflow can be in one of three states:

Active — currently usable. New objects can be assigned to it. Approvers act on items routed through it.
Inactive — turned off but preserved. Existing objects can't be submitted under it. Cannot be assigned to new objects.
Deleted — removed from the active list. Same blocking behavior as Inactive, but additionally hidden from the default Settings → Approval Workflows view (the "Active" tab).

[SCREENSHOT NEEDED — Settings → Approval Workflows showing Active and All tabs]

Activating a workflow

When you create a new workflow, you mark it Active. From that moment:

Users can assign the workflow to tactics, PRs, or CAG groups.
Submitted objects route through the workflow's approver chain.
The workflow appears in the Active tab on the Settings list.

Deactivating a workflow

When you mark a workflow Inactive:

The workflow is hidden from default selection lists (so users can't pick it on new objects).
Existing objects that reference the workflow keep their reference. Their Approval Workflow attribute still shows the workflow name.
Any modification attempt on those objects triggers the inactive-workflow error. See Error: "Selected Approval Workflow is either marked as inactive or deleted".

The rules:

If the workflow is in use and approval is in progress — Hive9 prevents deactivation. Wait for in-flight approvals to complete first, or reassign objects to a different workflow.
If the workflow is in use but no approval is in progress — Hive9 allows deactivation, but flagged objects will hit the error on next edit.

Deleting a workflow

Deleting a workflow has the same blocking effects as deactivating, plus:

The workflow is removed from the All tab as well.
Recovery requires recreating the workflow (or reactivating from audit logs in some configurations).

The orphaned-reference problem

The biggest gotcha: deactivating or deleting a workflow doesn't strip references from existing objects. The Inspection Window of an old tactic still shows the inactive/deleted workflow name in the Approval Workflow attribute. Any save attempt triggers the inactive-workflow error.

This is why some customers see error messages reading "Selected Approval Workflow is either marked as inactive or deleted" while their Settings → Approval Workflows page looks empty — the workflow was deactivated but the references weren't migrated.

Best practice for retiring a workflow

When you need to retire a workflow:

Identify everything that references it. Use Saved Views and the Filter Panel to find tactics with the workflow assigned.
Reassign those objects to a successor workflow. Bulk update via Honeycomb if possible.
Wait for in-flight approvals to finish before deactivating.
Deactivate (don't delete) — Inactive is recoverable; Deleted is harder to recover.
Monitor for a release cycle in case any tactics still surface the error. Reassign as they appear.
Eventually delete only after you're confident nothing references it.

Common questions

Can I bulk-reassign workflows on existing tactics? Sometimes — depends on instance configuration. The Honeycomb / Workspace Control Panel may support an Approval Workflow attribute update.

What if I deactivated a workflow accidentally? Reactivate it from Settings → Approval Workflows (use the All tab to find it). Activation restores its usability.

How do I tell if a workflow has objects referencing it? Filter the Plan Grid by Approval Workflow attribute = the workflow name. Any rows that appear are referencing it.

Why does Hive9 keep references on deactivation rather than auto-strip? To preserve audit history and prevent silent loss of approval context. You should know which objects need reassignment before they lose the link.