Questions about using Queues to restrict workitems
Marc-Andre_Lafleur
Customer Adept IT Monkey ✭✭
We are currently extending our Service Catalog to HR and Finance and we have some concern about sensible data that the tickets may contains. I watched the recent webinar “How to Extend Your Service Catalog to Other Departments” and during the demo, this was addressed using Queues and User Role.
Ideally, I want to restrict IT tickets to the HR team and HR tickets to IT (or simply just restricting HR tickets to any other analyst).
In my test environment, I created a queue for “SR SupportGroup is HR” and another for “SR SupportGroup is not HR”, assigned those to User Roles. I also had to remove the “All work items can be accessed” to any other user role to make this work. Then everything worked as I wanted for Service Requests but now no one has any access to the other types of work items and the end users does not have any access to even their own tickets on the portal.
Does that mean I have to create a Queue for any other work item classes (All CR, All IR…)? That seems to add lot workflows for so little. Is there a more efficient way?
For the end users, if I give them access to the queues, all analysts will also be grated access to the queues. Other than having a “non-analysts” group, how do you manage that?
To anyone that uses Queues in their environment to scope Work Items permission, did you see any performance hit after implementing this? Did you see any other performance or usage impact?
Best Answers
-
Tony_Collett
Cireson Support Super IT Monkey ✭✭✭✭✭
Scoping is an 'opt-in' system. If you have "All work items can be accessed" that encompasses everything.
Once you turn it off, you need to selectively choose work items to assign to users by using queues. Yes, you would need to create queues to cover other work items if you need to select them.
For handling End Users, you could use a queue system for End User work items and non-end user work items.
5 -
Justin_Workman
Cireson Support Super IT Monkey ✭✭✭✭✭
@Marc-Andre_Lafleur
Those are fairly normal. Affected User should have implicit access to their own Work Item. If it's outside of the Analyst's scope, they shouldn't be able to open it despite being the CreatedBy user.5
Answers
Once you turn it off, you need to selectively choose work items to assign to users by using queues. Yes, you would need to create queues to cover other work items if you need to select them.
For handling End Users, you could use a queue system for End User work items and non-end user work items.
- When an analyst or a end-user submit a request offering, if they try to open their newly created ticket right away, they will get an error "The
item you requested either does not exist or you do not have access to view it" and 5-10 seconds later they'll be able to access it.
- When an analyst submit a request offering using the "Create on behalf of" and the created ticket is out of their scope, they'll never be able to open the ticket. It seems like only the affected user can open the ticket even if it is out of their scope on the portal.
Are those normal behavior and is there something we can do about it?Those are fairly normal. Affected User should have implicit access to their own Work Item. If it's outside of the Analyst's scope, they shouldn't be able to open it despite being the CreatedBy user.