I've tested this on 4.5 (I'm assuming thats what you are using since yo have process portals) and it works without issues in both Management Console and custom code.

Here is the code snippet I used:

MNG.Criteria.WorklistCriteriaFilter oCrit = new MNG.Criteria.WorklistCriteriaFilter();

oCrit.AddRegularFilter(MNG.WorklistFields.Destination, SourceCode.Workflow.Management.Criteria.Comparison.Like, "mgr");
oCrit.AddRegularFilter(MNG.WorklistFields.Folio, SourceCode.Workflow.Management.Criteria.Comparison.Like, "Test 2");

MNG.WorklistItems oItems = oServer.GetWorklistItems(oCrit);

int iID;

if (oItems.Count == 1)
    iID = oItemse0].ID;
else
    throw (new Exception("Error retrieving Worklist item id"));

oServer.ReleaseWorklistItem(iID);

MessageBox.Show("Done");

Just remember, for roles, items are shared and as such, you cannot release the item (its not owned by a person), so in Workspace you will need to select the "Share item". There is a little + next to the item that allows you to manage individual shares.

dc, many thanks for your great contribution.

Yes I have 4.5
Can you please explain the settings for your action destination?

I think there is an issue when it's set to "create a slot for each role and group" which I am using.
The ReleaseWorkListItem method is throwing an exception: 26030 Worklist item 0 not found for K2:PRODUCTIONusername  at
When I choose to "resolve all roles and groups to users" the code just works fine,
but K2 creates a worklistitem for each user in the group (I am using AD groups, not K2 roles)
The issue with this is it overloads the process report with useless expired events which makes it hard for the end user to understand what's happening and track his processes.
For instance, one of my groups has 200+ users which means I'm getting 200+ expired events in the process report.
Imagine how hard for the end user is to find out who completed the task
Even in workspace, there is no an Expand/Collapse function when using AD groups.

Am I missing something?
What do you think?

hey, seems you are the new bee of K2 just like me.

I also faced same issue a few days ago. I told you how to find who open the item in another post. there are the methods for how to release the work item.

form clientAPI, only open the connection with the user who open the worklistitem, then you can get the worklist item and try to release it.

another way, you need use management API to release the worklist item, for this method, you need get the ID(not SN) of the item.

good luck.

Apologies, missed the part where you've mentioned groups. I was able to replicate the same behaviour when using native AD Groups. 

The good news however is I was able to work around this easily by wrapping the AD Group in a Role (set the AD Group as the member of the Role). Once thats been done, the AD Group is resolved as individual users and the behaviour is pretty much as expected (i.e. my previous posted code will work).

dc,
your are a life saver.
Many thanks for your brilliant trick, it worked like a charm.

K2 Support confirmed the AD group issue as a bug, I hope it gets solved soon.

Regards.