{{#if (not signed_in)}} {{#is help_center.name "Ideagen Help"}} {{#link "sign_in" class="unified-navigation--btn-primary"}}Sign in{{/link}} {{else}} {{#link "sign_in" class="unified-navigation--btn-primary"}}Sign in{{/link}}
{{/is}} {{/if}} {{#if signed_in}}
{{#is help_center.name "Ideagen Help"}}
Manage tickets
{{else}} {{#link "requests" role="menuitem"}}
Manage tickets {{/link}} {{/is}}
Update profile
Change password
Privacy Policy
Terms of Use
{{#link "sign_out" role="menuitem" class="signOut"}}
Sign out {{/link}}
{{/if}}
{{user.name}}
Looking for help?
Common queries
Send us feedback
Before you start
This form is for Ideagen Luminate feedback only.
Your submission will not receive a response. To request solution support, open a ticket with us.
We'd love to hear your thoughts on features, usability, or what you love about Ideagen Luminate.
Date System Limitations in Ideagen Quality Management – suggested improvement.
Recently we requested for Ideagen to develop the way the due date system works to improve functionality and save on time wastage within the business.
The current workload functionality is set at the template stage and is purely based on the raised date. This is great in theory, but in the real world, it leads to a lack of efficiency & requires considerable manual intervention with the need for micro-managing all the due dates of stages & actions within the system.
As an FYI some of our Q-Pulse processes have 15 or more stages with multiple tasks within each stage.
Scenario - We have a process that involves three sequential stages, the current methodology has defined dates as follows:
The first stage due date is preset 7 days from the raised date, the second stage due date is preset 12 days from the raised date, and the third stage due date is 16 days from the raised date.
In theory, the task will be completed in 16 days and no dates will ever be changed.
However, what if the first stage was completed within 2 days?
The due dates for the remaining stages would not change so instead of maximising the efficiency and taking advantage of the potential 5-day bonus the dates would remain unchanged unless there was manual intervention to update all the due dates for the following actions and stages.
Conversely, if the first stage was delayed and took 14 days to complete then the original due dates on the second & third stages (along with all the associated actions) become void as although overdue, none of the tasks can be actioned.
Considerable manual intervention and micro-managing will be required to update due dates to maintain accurate workload functionality for staff members.
Suggested Solution
We have asked Ideagen if they could introduce an option for a “Relative Due Date” function to remove the need for this manual intervention.
The theory is simple:
Instead of having a fixed Due Date based on the raised date, the “Relative Due Date” is instead relative to the date that the stage becomes active.
The advantages of this methodology are plenty and the efficiencies this will provide are numerous:
Instead of micromanaging due dates, using relative due dates for actions will enable an accurate actionable workload without any manual intervention.
Efficiencies will become automatic. If a stage can be started early then the system will automatically allocate valid due dates and workloads will reflect this.
Conversely, if a stage is delayed (which in the real world often happens) then the template due dates on future stages will not require manual intervention.
This functionality already exists “under the hood” as the previous stage completed date is already a variable within the system. This date could be used as the basis for the Relevant Due Date.
I recently spoke to another company that suffers from the same problem, they would use this “Relevant Due Date” functionality throughout their system. Please feel free to comment if you would support the implementation of what seems to be a much-needed improvement.
100% agree. it should be easy to say that e.g. stage 2 should be given a target date of +2 weeks after stage 1 closed date.
i would also add to this, that any stage should not appear on the stage owner’s workload until it is actually available to be closed. there is complete confusion amongst our users as to what they actually have to do in the CAPA module as their workload is full of stages and actions that they cannot close yet, because the previous parts of the workflow have not been completed. it should only appear on their workload once it is an “active” stage i,e, with a green arrow.
+2Hi
Hi Paul, it would be revolutionary to see this implemented as it would allow function to suit the user if a practical way. Please tell me this consideration would be implemented into desktop as well as we have currently expressed to Ideagen that the web client takes around 3 x longer to perform tasks which increases the resource requirements. It also makes you perform multiple requirements just to edit things where a user has permission to edit but in the desktop it recognizes the permission. This means we will be staying with the desktop version hopefully if it does not come to an end of life. The desktop version works much better for our needs than the web client.
Please keep developing the desktop version ☹️
+2Hi
Thanks
Paul
Hi
Was there any progress on this great suggestion?
thanks, kevin.
+2Hi Kevin, no progress as yet on the specific area of target date offset, however on a wider note we have begun our journey on improving the workload/action completion experience. We have redesigned the web UI/UX in the workload area that has reduced the number of clicks to complete actions by 70%. this is the start of many improvements you will see beginning with the forthcoming V7.9 on track for first week December. Sneak peek communications will be sent shortly!
Hi
That sounds great! thanks for the update. Keep up the development and hopefully your team can find a way to bring Stuarts idea to life.
Since you are looking at improving the workload UI have you ever considered improving the function of upcoming workload?
there are 2 ideas in that screenshot:
- introducing 3 time status options
- introducing time status options for all workflows
The stages would be optional and tailorable so admin could would have the choice to show it or not show it and also set the time periods, or to only show 1 2 or 3 stages.
The thinking is that users will not only be able to see what is overdue but also what is upcoming and what is most urgent. Having the option to set 3 status will allow administrators more options
e.g. for acknowledgements we would like to allow staff some time to read docs e.g. 2 weeks, so having the ability to set stages will give us options like this:
stage 1 due in next 4 weeks.
stage 2 overdue < 5 days
stage 3 overdue < 10 days +
we could also set different importance in acknowledging e.g. SOPs could be high and so must be acknowledged within 5 days, a newsletter could be LOW they could have a 4 week acknowledgement period. these could be set when the document is created / made live.
It could therefore be used to have a concept of a ‘reading’ time period for users e.g. the yellow stage is the time allowed to read the document . once it lapses the document will be overdue. the green is whats coming up - or some version of that idea set by the administrator.
anyway, just a quick idea - i hope it helps. thanks kevin.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.