Tag Archives: Process Instances

K2 – How to identify process name by process instance ID

Somehow I kept forgetting this thing frequently enough to expend some effort to write this ūüôā

At times when you troubleshooting something in K2 you need to identify process having only process instance ID and frequently knowledge of the solutions and workflow is a missing part (developer is away on vacations or , in the worst case scenario, nobody even knows if there was a developer in the first place ūüôā ). As a sample scenario, you can think of troubleshooting failed process escalation or process instance which stuck in Running state.

Let’s look at this in more details. For failed escalation you will definitely have error in K2 host server log and entry in K2 Server.Async table – that will give you  ProcInstID value, and your next steps are: A) Find out which process this instance belongs to and B) Status of this instance. Finding (B), at least if your process is in error state is easy as it supposed to be listed in  Error Profiles View where you can retry error and also see Process Instance ID and process name.

But in case your instance not listed in Error Profiles View, or let’s say you going step by step before jumping into Error Profiles, then you still have 2 options to get Process Name process instance ID:

(1) Using Workflow Reporting SmartObjects. You can use Process Instance SmartObject (Workflow Reports > Workflow General > Process Instance) to get list of Process Instances – you just feed ProcInstID to it to get back ProcessSetID:

Process Instance SmO Get List

Process Set ID in turn can be feed to Process Overview SmartObject (Workflow Reports > Workflow General > Process Overview) which will give you Process Name:

Process Overview SmO Get List

(2) Querying K2 database (in case you already in SSMS and too lazy to switch over too K2 Server/Tester Tool ūüôā ). Here is a SQL query you need to run:

SQL Query – Get Process Name by Process Instance ID

K2 Process Instances report: “This report has been limited to 1000 rows”

The other day I was asked about default limit you may see in K2 workspace when accessing, for example, Process Instances report for particular process (K2 Workspace > Process Overview > Process Instances).


Here is the message about default limit which you may see when surpassed it (This report has been limited to 1000 rows):


Well the main difficulty for me was that in my test environments I don’t usually see that much process instances, so to reproduce and verify respective settings was kind of a problem for me. There is a section at help.k2.com which mentions briefly configuration setting we need to adjust but not exactly and without going into much of details –¬†Custom Reports – Create Report Wizard. From there we may infer that the setting we need to adjust is “RowLimitRecordCount“, and the next thing is to change it and test. But like I said testing this may be difficult if you don’t have 1000+ process instances running in your environment (it could be that your test environment even doesn’t have any process deployed yet). And you don’t want to run 1000+ process instances by doing 1000+ mouse clicks, right? Let’s consider how to go about this problem first.

Luckily enough at help.k2.com you may find information on “Starting a K2 Process using the Windows Powershell”¬†which is a good starting point for solving our little problem. So starting from that I created following PS script running number of process instances required for my test:

$i = 0

Do {


[System.Console]::WriteLine("Starting K2 process instance" + $i)

Add-Type -AssemblyName ('SourceCode.Workflow.Client, Version=, Culture=neutral, PublicKeyToken=16a2c5aaaa1b130d')

$conn = New-Object -TypeName SourceCode.Workflow.Client.Connection


# Adjust line below by specifying your workflow name

$pi = $conn.CreateProcessInstance("Project_Name\Workflow_Name")



# Adjust line below to create required number of instances

While ($i -lt 1000)

[System.Console]::WriteLine("Done: " + $i + " process instances started")

This code will run as much instances of a specified process as you specify in “While ($i -lt 1001)” line (lt is quite queer/unconventional operator which PS uses for “less than”). Another line you most likely have to edit is “$pi = $conn.CreateProcessInstance(“Project_NameWorkflow_Name”)” – I hope this is quite self-explanatory.

If you don’t have any workflows deployed then for this particular test all you need is just go to K2 studio and drop Default Client Event and next terminate it with Placeholder Event, then deploy this test workflow. Process with only Placeholder Event won’t suffice for this test as its instances will go into completion immediately and you won’t get multiple instances¬†running simultaneously with such process.

Once you have large number of instances running you may see the message about the row limit mentioned in the beginning of this post and test change of¬†“RowLimitRecordCount” value. Now it’s high time to adjust the¬†RowLimitRecordCount value in¬†web.config file located in <install drive>:\Program Files (x86)\K2 blackpearl\WorkSpace\Site. Based on its default (1000) value and description we saw at help.k2.com for it this should be the one we need. But quick test will show us that increasing it doesn’t work for described problem. OK, maybe we just forgot to perform IIS reset which is necessary for web application to pick up the settings? Nope, IIS reset is necessary but this doesn’t help us to increase this limit.

Next thing which we may look at is OOBReports.xml file in the same location as aforementioned web.config file. It also do contain RowLimitRecordCount value which is actually controls the returned rows limit for Process Instances report (and judging by its name of other OOB reports too). And yes IIS reset is required for this change to take an effect. You may easily make sure that the same setting in web.config file controls the limit for custom reports if you quickly create custom report (you may be unoriginal and simply create Process Instances reports using Report Designer) and test this. You will be able to see the same message on a slightly different custom report layout and verify that this limit is controlled by setting in web.config file:


Other interesting thing which may be adjusted by editing OOBReports.xml file is¬†whether deleted process instances should be included in reports. With regards to this setting you may adjust global default value for “IncludeDeletedStatus“, and also enable or disable¬†the users capability to adjust this setting via the User Interface by changing the”DisableUserSetting” to False or True.