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.

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.

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").

I would like to submit a request for the revaluation of removing the SSRS Broker from “legacy” status back to active support/development. There are still many on prem customers that use SSRS including my current customer.

This could be accomplished in a few ways that would be of benefit.

Option 1: Update the current broker project. This is the quickest and low hanging fruits. The necessary web services that the current broker reply upon exist in SSRS 2016. This has been validated in a fresh build of a test environment.
Change the reference from depending on the ReportViewer 2005 to Report Viewer 2016.
Update the project .NET Framework Version to one that is more current.
Recompile and remove the legacy label.
Option 2: Removed the report viewer dependencies and update to use the new Report Viewer Controls Nuget package.
Package manager can be used to add new DLLs to the project for the most recent version of SSRS / Power BI which is still backward compatible back down to SSRS 2005.
Update name spaces to reference the same methods, properties and types used today in the SSRS broker to leverage the new viewer control dependencies.
Option 3: Consider releasing the broker code as an open source project so that the community could enhance the broker beyond feature parity that the first 2 options offered aim to accomplish if Nintex doesn’t have an interest in adding net new functionality.

I'm coming from MS Access world (building apps) and there you could build an event when the user clicks or double clicks the specific column in the list view (the specific cell so to speak). In K2 there are only two list view events possible - the click and the double click event for the whole item (row). This is quite limited. If you want to make an amendment to specific cell under certain conditions (and you don't want your users to edit the whole row), or open different subviews for different columns or do any other actions related to the data in specific column (for example - by double clicking the ID cell you could delete the whole row from SO (upon confirmation of course), while by double clicking the user cell you could only send a notification to that specific user), the additional column click or double click events would be very useful (alternatives are not that great tbh, they mean more work and are not that user friendly). Check my pic from MS Access -> by double clicking on different cells you can trigger different column events.