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.

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.

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.

Currently the SmartForms content control can embed content from any domain/site instead of allowing an administrator to restrict it to certain sites/domain that are known to be safe.

The idea is to allow an environment administrator to add restrictions for the content control similar to what SharePoint does:
https://support.office.com/en-ie/article/allow-or-restrict-the-ability-to-embed-content-on-sharepoint-pages-e7baf83f-09d0-4bd1-9058-4aa483ee137b

Options that should be available:
Allow Any Domain
Restrict to whitelist of domains
explicit: help.denallix.com
wildcard: *.denallix.com
Automatically includes all domains associated with smartForms
Do not allow content injection (Not essential)
Prevents the control from being used on new forms/views

Configuration must be available through management site so that platform admins can control these restrictions, and the settings.

At runtime, when a content control tries to load content from a site, it first checks if it adheres to the restrictions applied and throws an appropriate error if it does not.

When exposing anonymous SmartForms to the internet or on a corporate website, there is currently no built-in way to prevent malicious bots from submitting the form and potentially creating millions of illegitimate entries.

Adding a custom CAPTCHA type implementation before the form loads is not sufficiently effective seeing that once a malicious user gets passed the CAPTCHA prompt it would allow them to see all the SmartForm requests that can be used by a bot to submit the form automatically.

A built in CAPTCHA type control and integration would be best - The idea is that it would allow a solution designer to select their preferred CAPTCHA provider (google reCAPTCHA etc) and then group rules/actions that requires a successful CAPTCHA challenge which is also validated server side when server side executions like SmartObjects and Process Start actions occur.

Currently all validation rules that are built in SmartForms are executed client side which is not great for data integrity.

Seeing that SmartObjects are seen as the data layer, it would be great to be able to configure validation rules on input properties as part of the SmartObject's design.

Examples of Validation types that should be available:
Regular expressions (ex email address, social security number, etc)
Value comparisons - Ex Value < 100
Property comparisons - Property1 >= Property2

Once a SmartObject is designed with these validation rules, the validation should be executed server side whenever the SmartObject is executed at runtime and validate the input value.

This would improve data integrity substantially as the validation would take effect through SmartForms, workflows, OData API and custom c# applications making use of the SmartObject client API and would ensure that business data is always in the expected format/range and that there is no way to bypass validation client side.

To further strengthen the feature, SmartForms can automatically consume validation rules configured on a SmartObject to show validation errors when a field is linked to a SmartObject property so that the Forms/View designers do not need to build validation into every Form/View that consumes the SmartObject.