Updating the K2 Worklist Items after the K2 Server Host Header changes

  • 24 February 2022
  • 0 replies

Userlevel 4
Badge +16


Updating the K2 Worklist Items after the K2 Server Host Header changes

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.


This issue occurs after updating the K2 server's host header or migrating an existing K2 Database over to a new K2 environment.  When opening a worklist item you are taken to the old K2 server. 




For example here's two K2 Server URLs:


Dev 1: https://k2.denallix-dev1.com/
Dev 2: https://k2.denallix-dev2.com/


After taking the Database tied to Dev1 and tied Dev 2 to a backup Database created from a copy of our Dev 1 server.


Any user who opens their worklist items will always hit the Dev 1 URL. This will occur on the server, on a client machine, outside and inside the network, etc.

Troubleshooting Steps

This behavior occurs due to the fact that the Server.WorklistHeader table still has the old URL for each of our worklist items within it's [Data] column. There are two ways to resolve this behavior. (K2 Support recommends option #1 as it is the least invasive change that does not require Database manipulation and covers the entire environment).


1) Update the Host files on the new server to point all requests for the https://k2.denallix-dev1.com/ FQN (Server 1) to then route to the IP Address for the Dev 2 Server. This would act as a pseudo redirect via DNS and ensure that all traffic requests to Dev1 will hit the Dev2 server. If there are inflight process instances that already have this data stored within a datafield, this will also prevent those instances from erroring.

Also, update the environment fields after moving the database, but if this redirect is in place you do not need to change the URLs in the Environment Library.


2) By running the following SQL Query to do a find and replace on this [Data] column.



NOTE: Please reach out to K2 Support to get assistance with running the below query. 

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: 







/** Below query will need to be updated with your old and new server host headers **/

UPDATE [K2].[Server].[WorklistHeader] SET Data = REPLACE(Data, 'dev1', 'dev2') WHERE Data IS NOT NULL;




0 replies

Be the first to reply!