I have seen lot of developers like to put all the fields of original list inside the task form to give the exact look and feel/functionalities as like of the original form. This type of development have pros and cons from both side.
Pros: The task and the original form is having the exact look so that user can't distinguish and also can view/update the original list fields from task form on the course of running the workflow. Also reduce the headache of developers to develop. It's cool.
Cons: If we design the task form as like of original form, the size of the workflow get increased and consume more RAM during the run time. And if the instance of the workflow running inside the RAM get increased, its execution time, loading time etc. also get increased. Also mimicking all the task forms as like of original form, increase the development time and violates the re-usability principle.
Now the situation is very risk. If user find the task form is taking substantial amount of time to load,substantial time to submit they could get irritated and can dislike to use NINTEX. This is our very recent experience we faced with a client. So we have to handle this situation very sensitively.
So, if a list is reasonably small then you can afford to put those fields(or a subset) inside task form but if a list is big, never ever try to mimic all the task forms as like of original form. Unnecessary it will increase the size of the workflow instance and increase the execution time and will have bad impact to the workflow performance. You can definitely put few fields that user want to see inside the task form but never try to mimic the look and functionality(rules, validations etc.) of the task form as like the original form.
You can tell this is an infrastructural issues (RAM,CPU etc) from client end (On-premise) and they can install good machine in the place but still irrespective of those we can do something good in designing to enhance performance of the workflow.
To overcome this situation, it's a best practice to put a hyperlink inside the task forms that will redirect the user to open the original form in another browser. From there user can operate (read/update) on the original form. Here is the link where I have demonstrate to achieve in a pretty simple way.
In this way we can reduce the size (Bytes) of a running workflow instance (inside RAM) to a substantial amount by integrating the re-usability of Software development principle in NINTEX development and can make the application more faster and can also reduce the development time.
Hope you have enjoyed the blog.
MERRY X'MAS AND HAPPY NEW YEAR 2018!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.