We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.
For more information around feature requests in the Cireson Community click here.
Muliti-Tennancy / HIPPA Compliance via More Granular 'Analyst' Access to Portal Work Items.
What I would like to see is the ability to add certain users into an AD group so that when these users access the system they will 'only' be granted analyst access to a ticket when the ticket is assigned to a support group they are a member of, otherwise it will only provide end-user access to the ticket.This would allow for better segregation between tickets, depending on your support group, and prevents end-users from seeing 'private notes', and other extended information unless the ticket is assigned to their support group.
Further to this, I would like to see the ability to mark a work item as 'sensitive'. And this would lock access to a work item, so that is can only be accessed by the assigned support group, no other end-users (except administrators) can access the ticket at all. This would assist with PII, PCI, HIPPA compliance etc.
If people have other ideas which may enhance this feature request, just sing out.
Cheers,
Adrian
Comments
Just an opinion: I think you have to put the protection on the work item or ticket. If you put the protection on the "Assigned To" or "Support Group" and the work item is assigned to an unprotected person or group the security is broken. In my organization tickets are routed to many groups throughout it's life cycle. Wondering if a check box on work items that says "Sensitive Information" and then only users in a security group that allow "Sensitive Information" views would solve this?
Thanks Jason,
That's a great Idea,
I agree that a Cireson Specified "Security Information Group" used for accessing sensitive work items makes perfect sense, rather than using the support group for filtering. Thanks for your input / amendment!
Regards,
Adrian
All of IT are members of the Cireson_Analyst group which currently are designated as the group to enter all work items. In the case of Change Requests, we have a handful of non-IT individuals that are technical support folks for their area and would like to have access to create CRs. At the same time, we do not want these folks to have access to all the IRs and SRs managed by the same AD group.
I see the need - in our case - to be able to add a secondary group to which ever work item class we need to customize the selectivity of access. I supposed I can create a separate AD group to include the Cireson_Analysts adding in the individual's names just for CRs. I'm sure it's just me, but adding a secondary AD group to the 'AD Group With Access" field is more intuitive! :-D
Thoughts?
Regards,
Mark