< class="prominent-subhead ">

Using Live Instance Migration (LIM) when escalation was removed from process

This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.


After removing the Process Level Escalation and Activity (referred to by this escalation) from the process definition and migrating running process instances to new a definition using LIM; the API escalation still keeps firing causing the process to be stuck in a running state.


When running a process migrated to a new definition where the Process Level Escalation and activity referred by the escalation was removed, the escalation keeps firing causing the process to be stuck in a "Running" state.


Removing escalations from process definitions are not supported by LIM API as documented in K2 BLACKPEARL DEVELOPERS REFERENCE - Important Notes about Live Instance Migration (LIM).

Documentation lists process definition changes which are NOT supported when migrating between process versions. In particular, removal of the following from the process definition is not supported:

  • Activities
  • Lines
  • Events
  • Data fields
  • Xml fields
  • Escalations
  • Actions

In case you migrated instances with removed escalations, you can remove scheduled escalations from K2 database as a workaround. 

This workaround involves direct modifications of K2 database. Do not modify any database definition or database content unless specifically instructed to do so by K2. No changes to the K2 Database definition or content are supported unless specifically instructed by K2.  Please see: http://help.k2.com/onlinehelp/k2blackpearl/devref/current/default.htm#Database_Reference.html 

As a workaround to prevent scheduled escalations from firing off, please contact K2 Support to do the following:

Backup the K2 database and execute SQL script shown below. Note that in the script there is 2 variables that need to be set - @VersionWhereEscalationWasDeleted and @ProcessWhichWillExpire.

"DECLARE @VersionWhereEscalationWasDeleted INT;

DECLARE @ProcessWhichWillExpire NVARCHAR(MAX);

SET @VersionWhereEscalationWasDeleted = 7; -- (SAMPLE VALUE)

SET @ProcessWhichWillExpire = N'ProjectName\ProcessName'; -- (SAMPLE VALUE)

DELETE [AS] FROM [Server].[Async] AS [AS]

       WHERE [AS].[Type] = 5

         AND [AS].[ProcInstID] IN (

              SELECT [PI].[ID] FROM [Server].[ProcInst] AS [PI]

                     INNER JOIN [Server].[Proc] AS [EP] ON [PI].[ExecutingProcID] = [EP].[ID] -- Executing

                     INNER JOIN [Server].[Proc] AS [OP] ON [PI].[ProcID] = [OP].[ID] -- Original

                     INNER JOIN [Server].[ProcSet] AS [EPS] ON [EP].[ProcSetID] = [EPS].[ID]

                     INNER JOIN [Server].[ProcSet] AS [OPS] ON [OP].[ProcSetID] = [OPS].[ID]

                     WHERE [OPS].[FullName] = @ProcessWhichWillExpire

                       AND [OP].[Ver] < @VersionWhereEscalationWasDeleted

                       AND [EP].[Ver] >= @VersionWhereEscalationWasDeleted         );"