This article describes a new feature that allows admins to restore deleted workflow automators within 14 days, helping to recover accidental deletions and maintain business continuity.


TABLE OF CONTENTS

Admins can now restore deleted workflows within 14 days of deletion. Restoring a workflow does not resume automation on previously processed tickets, service requests, or other entities. The workflow will only apply to entities created after the restoration.



State transitions for deleted workflows

The behavior of a deleted workflow depends on its state at the time of deletion:

  • Active workflows: When an activated workflow is deleted, it first changes to inactive and then moves to the trash. Execution stops immediately.
  • Inactive workflows: When an inactive workflow is deleted, it moves directly to the trash and remains inactive.
  • Draft workflows: When a draft workflow is deleted, it moves to trash as a draft.


Restoring Workflows

  • When a workflow is restored, it will return to the Inactive state.
  • Active and draft versions of a workflow will be restored separately, and any previous associations will not be retained.
  • Workflows in the trash can be restored within 14 days. However, the exact date of permanent deletion may vary, and Freshservice cannot guarantee a fixed deletion timeline.


This feature is available for workflow automators in:

  • Tickets
  • Changes
  • Problems
  • Releases
  • Assets
  • Tasks
  • Software Users


Limitations:

  • This feature is not available for production accounts with an active legacy sandbox. It will be enabled automatically once customers upgrade to the latest version.

Use cases 

Scenario 1: Active/Inactive and draft workflow pairs

In Freshservice, workflows can exist in pairs based on their lifecycle state—Active/Inactive and their corresponding Draft versions.

Behavior

  • When an Active or Inactive workflow is edited, a Draft is automatically created with the same name.

  • If either the active/inactive workflow or its draft is deleted, the link between the two is broken, and the deleted workflow is moved to the Trash.

Post-restoration condition

After restoring the deleted workflow from the Trash:

  • If two workflows with the same name now exist (e.g., one was never deleted), the restored workflow must be renamed before activation.

  • Attempting to activate a workflow without resolving the name conflict will result in a system error.


Note: The platform enforces unique names for active workflows to maintain consistency and prevent conflicts.

Scenario 2: Draft deletion and edit restrictions

  • An Active workflow named Service Request process is edited.

  • A Draft named Service Request process is created.

  • The draft is then deleted, sending it to the Trash.

Issue upon re-editing

  • When trying to edit the original active workflow again, the system blocks draft creation.

  • This is because a deleted draft with the same name still resides in the Trash.

Note: The draft must first be restored and renamed, or permanently deleted, before the system allows a new draft to be created from the active workflow.

Scenario 3: Sandbox sync and workflow name conflicts

  • In the source instance, a workflow named Test workflow is in an Active state.

  • Editing it creates a Draft also named Test workflow.

  • During a sandbox sync to the target instance, name duplication causes an issue.


Note: If the target instance already has multiple workflows with the same name (including those in Trash), the sync will fail for this workflow.


Solution

  • Ensure only one workflow with the same name exists in the target environment.

  • Rename or delete additional workflows (including those in Trash) before attempting the sync again.