Strategy for keeping some Work Items confidential
Sandy_Wood
Customer IT Monkey ✭
From time to time, we get requests to do some searches in email from HR that need to remain confidential and out of prying eyes. We want to create Work Items but want to limit who can see them. We currently have 4 support groups in our Service Manager world, Networking, Help Desk, Programming, Facilities. We don't want anyone in those Teams to see the Items. Should we just create a new support group, say, Confidential and then only let specific people be part of it? Wondering what others have done in similar situations.
0
Best Answers
-
Justin_Workman
Cireson Support Super IT Monkey ✭✭✭✭✭
@Sandy_Wood
I think the most definitive way to keep work items separate would be a queue in SCSM. This would require adjusting your existing roles and permissions in the SCSM console to give explicit access to everything that's not 'Confidential' but it is the only airtight method. The easiest criteria to define the queue probably would be, as you suggest, a Support Group. Keep in mind as you build out queues and extended security scoping that it can have an impact on the performance of any process that checks SCSM security(ie. Cachebuilder building Scoped Access). An alternative to additional security scoping in SCSM would be forcing all SCSM analysts to only use the portal(which may already be the case) and creating some navigational "funnels" that keep analysts away from seeing these incidents. But without the added security from SCSM it would be possible for these incidents to come back in search results or be navigated to manually(typing a Work Item Id in the address bar). Just some things to consider...
I hope it helps!6 -
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
Having actually performed this and seen it to it's end - new queues, new support group (Human Resources), etc. This really begins to treat SCSM as less of an IT tool and more of an organizational/department tool.
I think this is the way to go for sure as it introduces a means for departments to begin to showcase the services they offer through the Cireson SCSM Portal through new request channels. In this way everyone in the organization becomes part of the help desk.6
Answers
I think the most definitive way to keep work items separate would be a queue in SCSM. This would require adjusting your existing roles and permissions in the SCSM console to give explicit access to everything that's not 'Confidential' but it is the only airtight method. The easiest criteria to define the queue probably would be, as you suggest, a Support Group. Keep in mind as you build out queues and extended security scoping that it can have an impact on the performance of any process that checks SCSM security(ie. Cachebuilder building Scoped Access). An alternative to additional security scoping in SCSM would be forcing all SCSM analysts to only use the portal(which may already be the case) and creating some navigational "funnels" that keep analysts away from seeing these incidents. But without the added security from SCSM it would be possible for these incidents to come back in search results or be navigated to manually(typing a Work Item Id in the address bar). Just some things to consider...
I hope it helps!
I think this is the way to go for sure as it introduces a means for departments to begin to showcase the services they offer through the Cireson SCSM Portal through new request channels. In this way everyone in the organization becomes part of the help desk.
The one thing I would add in support of this is do not underestimate the performance impact. It is real, and can be quite severe if you do not scale up with it and optimize your inclusion/exclusion rules to be as succinct as possible while still selecting the correct object(s).
In the background, scoping of any kind (only admins operate completely un-scoped) adds complexity to the queries that run in the background, and makes them less efficient. The less scoping applied to a user, the better. The more a user can access, the less work is required of those queries. I often wish that it worked the other way around.