In K2 version 4.7 (and previous versions), when the main workflow calls an IPC/sub-workflow, it uses the K2 service account to start the sub-workflow (IPC). Now, in K2 Five, when the main workflow calls the sub-workflow (or IPC), it uses the workflow Originator user's account instead of the K2 service account. With this changed, we are now encountering some issues...

1. When a workflow has a sub-workflow (or IPC) and the user (originator) started a task and assined it to another user. Then later the user (originator) who started the task left the company or was terminated (The originator is no longer active in the Active Directory). The main workflow will encounter an error when the user assigned completes the task since the sub-workflow wil not be able to execute or start as the originator of the task is no longer active from the Active Directory.

2. Some of our sub-workflows are being used by multiple workflows. We don't want to use the same permission set to sub-workflows as we don't want other users to access this sub-workflows. With the K2 Five new implementation for IPC, we are forced to grant start permission to almost any users who has start permission to the main workflows. Proper security permissions are compromised because of this changed. We can no longer limit the permission to execute the sub-workflow to just the K2 service account.

If the original implementation was retained where K2 service account is being used to execute an IPC or sub-workflow, the above issues should not be encountered. Or if there will be an option within the workflow where there is an IPC or a sub-workflow call that you can configure where you can grant permissions to a group or individual users or K2 service account and set a "Start" permission, these aforementioned issues will be resolved.

To allow a toggle (similar to that for the Action Bar in Management for K2 Workspace) to set the default for all actions to be visible/invisible on the worklist view.

We currently use the worklist view on the landing page of our forms and due to the business requirements all SmartActions should be set to invisible to make the user open the form and review it before approval.

Currently in K2 Workflows, the default setting is visible - if there was the toggle, this could be set in Management, reducing the effort required by developers and preventing any user errors by leaving the SmartActions visible.

We would like to limit the task reminder to go to certain users who are on the task. So in the task reminder section, I have set the reminder to 7 days, and edited the email section to only email reminders to task approvers who have a certain role. So in my case, there are two users who get the task assigned, one has a role of originator and the other the role of approver. I only want the reminder to go to the approver, so I have a smart obejct that gets the email address of the person who has the approver role. Sure enough the reminder only goes to this person but the email is sent twice to this person because the task is assigned to both roles Originator and Approver.

When we use the standard behavior from K2 Management site "Go to activity", if we go to an activity inside a split branch, the workflow stops suddenly at the next merge step without information.

We found this as a known issue here:
https://help.k2.com/support-services/kbs100272
but we need to be aware about this issue before doing the Go to activity.
I we are not aware, the workflow stops suddenly at the next merge step without information.

Reproduction steps:

Create a workflow with a split.
Example:

Task1MainPath
Split
Task2InsideSplitPath1 Task3InsideSplitPath2
Merge
Task4MainPath

A-Start the workflow instance.
B-From the Workspace, validate Task1MainPath to go to path2 and choose "Submit".
C-In Management, click on the instance and choose "Go To Activty" and choose the same task "Task3InsideSplitPath2" and click on button "OK".
D-From the Workspace, validate Task3InsideSplitPath2 and choose "Submit".

Result:
The workflow is completed and finished on merge part.

Expected result:
The workflow should continue to next step ("Task4MainPath").

When a user attempts to open a worklist item that has already been actioned - normally this will happen through an email that they have received, the message they get says: 'Error - Worklist item could not be opened. [User] is not allowed to open the worklist item'.

This is confusing as it implies that there is an error in the system, however there hasn't been an error it is just that the worklist item has already been actioned, so this user can't do anything on it. It would be better if the message said something more along the lines of the task having already being actioned, so that the user isn't confused by this.

In K2 Legacy Workflow (K2 4.7 and previous versions), by default, the Activity Display Name and the Activity System Name are the same. If you want to rename the Activity System Name different from the Display Name, you can easily do it as this property is editable.

In K2 Five, Activity Display Name is no longer the same as the Activity System Name. You don't even know what was the assigned Activity System Name unless you have to query it from K2 Database. The System Name is not even displayed somewhere easily accessible when you are building the Workflow from the K2 Designer.

Now, when you use the GoToActivity method from the API, you have to query from K2 DB using the two tables [K2].[Server].[Act] and [K2].[Server].[ProcSet] respectively just to get the System Name of a particular Display Name. Querying the K2 DB will consume additional time just to get the System Name.

I would like to request that the Activity System Name should be editable when building the Workflow from K2 Designer since this System Name plays an important role in many cases in our development.

At the moment. there is no way to configure a wait event in a workflow for reaching a specific date or a condition comes true.
It's necessary to have the possibility to configure your own rule. It must be possible to use/combine data fields and stored procedures (or other external resources) to define a condition and wait until condition is true.

For example:

IF

StoredProcedure1 = true

and

Field1 = true

and

Field2 = true

THEN go

ELSE wait

When a workflow needs to wait for a different workflow to finish before it can self move on, and this can sometimes take a very long time (6 months to a year) then you cannot use a Loop to check this since it will cause massive overhead and performance issues.