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:
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.
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.
/** 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;