{{#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.
Looking for support? Select the solution you need help with and open a ticket with us.
We'd love to hear your thoughts on features, usability, or what you love about Ideagen Luminate.
segregation of roles for permissions in CAPA
+3Is it just me/my organisation that feels the permission model for CAPA has weaknesses?
ignoring static and focusing of dynamic security permissions…
we’ve always worked on the basis that:
- the CAPA owner/creator has full edit permission for a record (along with any associated auditors),
- the stage owners can only edit any stages they have been assigned as owners
- and stage action owners can only edit those they own/are assigned.
that works fine except when the stage action owners need to attach evidence so that completion of the action can be independently verified. this fails as by default they don't have permission to attach files, and if given ‘add/edit attachments’ they also need the hieratical CAPA edit for that the work.
if they are given that permission, then it also allow them to also edit the stages and wider CAPA elements - which breaks the cascading/workflow type control model.
incidentally they can also edit the ‘details’ part of an agreed action, as well as the ‘response’, which is very trusting. plus they can change the action ownership and target date, without any system approval from the stage or CAPA owner.
additionally can anyone explain the purpose of the stage description field, as it often confuses users into thinking this is where they record the agreed action.
any ideas or suggestions gratefully received, so that we can make the CAPA workflow process more robust; at present our workaround is that stage action owners have to email evidence to the stage or CAPA owners separately, so they can add it to the record for them…. not very efficient IMO?
+2Hi Sean,
we use “stage description field” for stage owner to add the conclusions or any comments when completing the stage.
Handling permissions is a nightmare, you can only try-test-error-change-try….after some changes you will have something good enough (not perfect). Most probably you need to segregate roles into separated security groups for more granular permissions.
Good luck!
+3Hi Jordi,
regarding the stage description, we have added default txt to incident and capa templates but it still causes confusion. its a pity capa/incident stages arent more customisable. Ideally i’d remove the stage description box totally, and better still no stage owner, leaving just a list of action for each capa. when you have potentially 5000 users that could be assigned QP tasks - short and simple is key to success.
as you say permission are a real challenge, no system is perfect but after administering QP systems for 15+yrs IMO there’s still a lot of room for improvement. I try to use the dynamic permission by default, but often end up creating multiple static/role based groups for ad hoc access requirements - but that then creates ongoing admin task to keep updated.
regards Sean
+2I agree with you.
We already asked Ideagen some improvements requests like having custom fields on stages.
A lot of room for improvements.
+3I agree with you.
We already asked Ideagen some improvements requests like having custom fields on stages.
A lot of room for improvements.
good luck ;-) in a previous version of this community site there was an option for users to suggest improvements and others to vote it up. Ideagen design team were meant to review each and give feedback on technical viability and likelihood of implementation; including reporting if applied during a version update - but the initiative didn't last or get adequate attention. personally i would have thought it was a great opportunity for suppliers to focus on what customers really needed/wanted?
+2absolutely, is how it works with other SaaS products. Where clients vote for the next features to be included. Ideagen is not transparent on this part.
Coming from Skills? Create an Ideagen Luminate account to link your learner profile. Learn more.
Coming from Skills? Create an Ideagen Luminate account to link your learner profile. Learn more.
Coming from Skills? Create an Ideagen Luminate account to link your learner profile. Learn more.
Coming from Skills? Create an Ideagen Luminate account to link your learner profile. Learn more.
Login with SSO
Ideagen Employee Login Login with Ideagen Hubor
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.