Home› General Discussion

Configure Team Request

Wolfgang_SchmidtWolfgang_Schmidt Customer Adept IT Monkey ✭✭
in General Discussion

Hello Community,

we would like to use the feature team request. It also works without problems in our analyst group.
I see the requests of my colleagues and my colleagues see the requests I have opened.
The same function should also work for end users, or do I have to adjust something else here?

Regards
Wolfgang

Best Answer

Answers

  • Nicholas_VelichNicholas_Velich Cireson Consultant Ninja IT Monkey ✭✭✭✭
    Hi Wolfgang,

    The "Team Requests" feature should work for any type of user provided the following:

    1) The users have access to the Team Request Navigation Node
    2) The users have permission to access Work Items in the Team Request view (SCSM User Roles)

    Thanks,
    Nick
  • Wolfgang_SchmidtWolfgang_Schmidt Customer Adept IT Monkey ✭✭

    Hi Nicholas,

    thank you for your quick reply.

    1) the user has access

    2) there is no Team Request view in SCSM User Roles ( or i can not finde them :-( )

    Regards

    Wolfgang

  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    Also to add to what Nick has mentioned, Team groups must also be configured in the admin settings of the portal. 

    There is also the teamgroupfilter in the settingitems of the portal, when this is set to true endusers will not be able to open workitems at the portal level outside there team groups - making SCSM permissions a little simpler as you can grant unscoped queue access.

    See https://support.cireson.com/KnowledgeBase/View/81 for more information.
  • Wolfgang_SchmidtWolfgang_Schmidt Customer Adept IT Monkey ✭✭
    Thanks for all the info and tips
    What we have done now:
    We built the whole thing over a queue. That worked just fine and we can limit the Team View to individual  groups of users.

    Thanks
    Wolfgang
  • Gerhard_GoossensGerhard_Goossens Customer Advanced IT Monkey ✭✭✭
    Nicholas_Velich said:
    To clarify, there isn't a view to grant access to within the User Role. Rather, we need to make sure the end-user-level users have access to the work items that would be within the view.

    By default, end users only have access to items in which they are the Affected User. This is taken care of behind-the-scenes in the Cireson Portal/SCSM. For the other items in the Team Requests view, they would need to have SCSM-user-role permissions to those items-- just being in a Team Requests group isn't enough. This work-item-level-access could be granted to all work items (probably too open), or by setting up a queue for those items (some performance drawbacks if using lots of queues, so limit usage here if possible).

    Thanks,
    Nick
    Good day Nicholas,

    You mentioned limiting the queues because of performance drawbacks. Can you clarify on what is too many queues and does it matter how those queues are defined? Currently, I use queues=support group to grant users access to work items. We will have about 50 support groups that will mean 40 queues, will this have a massive performance impact?

    I have a WF and secondary server with 8 cores and 16 GB RAM each. The amount of work items that will be generated per day will be a lot but I don't have a figure yey
  • Nicholas_VelichNicholas_Velich Cireson Consultant Ninja IT Monkey ✭✭✭✭
    Hello Gerhard,

    I believe 40 queues will have an impact on performance, and should be avoided if possible. Just how much of an impact would depend on the volume of Work Items, and specs of the Workflow/DB server (primarily CPU and Disk speed, respectively). The negative performance impact queues have is twofold:

    1. They take time to process, and there will ultimately be a 1-2 minute period (best case) where Work Item scope is being evaluated and a Work Item does not belong to any queue yet. This means that those Work Items won't be visible to any analysts during that processing time, and no one can work on them until processed. This would occur on creation, and whenever Work Items bounce between groups.
    2. All the extra processing is adding to the overall workload of the Workflow server, which can lead to general sluggishness, especially if not specced adequately. 

    My ideal approach for Work Item scoping is typically to do so via Views. I find that often times Work Items are scoped simply to make the content in the environment more appropriate for the user, rather than as a security precaution. By limiting what Views are available based on a user's group, you can more easily guide analysts towards content appropriate for their role. In this case, analysts can still technically view Work Items outside their role's scope, but it becomes a more difficult task (they would need the specific Work Item number, a link, search criteria, etc.). Remember that these analysts are still employees of your organization and can typically be trained and held accountable in what to/not to do; even if an employee goes out of their way to modify a Work Item that they shouldn't, there is a History Log for audit purposes on every Work Item.

    Adding to the above, the individual Work Items can also be restricted at the form-level in Cireson's Service Manager Portal via custom JavaScript. Content could be hidden altogether, or even just specific/key fields.

    The approach above works for many environments as long as "an analyst viewing a Work Item outside their scope" is not considered a security issue. If so, queues are really the only option, in which case you should try to limit the total number (perhaps queue by different tiers, rather than each group-- try to stay around 5-10 if possible).

    Thanks,
    Nick
  • Gerhard_GoossensGerhard_Goossens Customer Advanced IT Monkey ✭✭✭
    The reason for the number of queues is that we plan to integrate other departments into the environment. And with departments like HR and Finance, it is critical that no can pick a number and potentially view financial or private employee information.

    So this leaves me with the possibility to maybe create a queue for each department like HR, Finance, IT, Facilities to limit the access to the work items. And maybe a couple of queues within HR and Finance to truly lock down what must. Then I should get to the sub 10 queues.

    You mentioned the scoping via Views, is this only for the console views? I am planning on only using the Cireson Analyst Portal as the console is too unreliable and sluggish. Does this mean I will have to promote views to the portal and scope those vies to the support groups?

    If you have any more info relating to the use of Views for scoping can you please pass it along via a link or maybe a Private Message. I don't want to hijack this thread further....  :)
  • Nicholas_VelichNicholas_Velich Cireson Consultant Ninja IT Monkey ✭✭✭✭
    Limiting queues by overall department to adhere to the security requirements would be a great compromise.

    As far as View scoping is concerned, I probably made that more confusing by calling them "Views"-- old habit :smile: . By "View," I am actually referring to any "Navigation Node" in the Cireson Analyst Portal (any clickable icon along the left-hand side). These Navigation Nodes can be out-of-box (such as "Active Work" or "Team Work"), promoted console Views, saved searches, custom pages, etc.

    My mindset when writing the View-scoping reply was a Portal-only implementation. Each Portal Navigation Node can be restricted by AD group in Navigation Settings as an Administrator. I agree that the Console is less-than-ideal, especially because Views are granted through User Roles in that case.
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    Suggestion based on how I manage queues. I have ~197 support groups, but only a few who manage "sensitive" information that others should not see. I only setup one root queue for the finance group, where I still have different support groups for them. The end result is I only have about 6 queues. (3 for incidents and 3 for service request) The reset of WI are managed thru omission rather than restriction. Meaning I don't have it directly in there views but they would be able to search the ticket. This makes sure that group processing completes before the time out. 

    Here is an example of another person who it running into performance issues due to queues. (what to watch for)
    https://community.cireson.com/discussion/3801/relationship-change-in-a-ticket-to-a-new-support-group-takes-up-to-20-minutes
  • Gerhard_GoossensGerhard_Goossens Customer Advanced IT Monkey ✭✭✭
    edited April 2018
    @Brian_Wiest Thanks, I think I will create queues for each department and where the sub department needs to lock down access I will create a queue for them.

    How did you configure the queues? Support group=department?

    The reason for asking is that I have changed my Incident tier list to look something like this:




    How will I setup the queue? just support group = Information Technology. Will this include the sub-departments 

    I'm sorry for "hijacking" this thread but I have asked this question without many responses.

    https://community.cireson.com/discussion/3709/limit-on-queues#latest

     
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    edited April 2018
    In the queue setting you have to define all the support groups to include in that view.
    But you do not have to create queues for your non restrictive groups as they will still fall in the root.


  • Gerhard_GoossensGerhard_Goossens Customer Advanced IT Monkey ✭✭✭
    But won't this calculation of the queue take just as long as having a separate queue for the different subgroups?

    But thank you for the input, I will definitely be setting it up this way
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    So taking my example above. 
    If you create as above it performances one group calculation 
    Where if you split the four to each having their own queue the four group calculation take place. 
    Remember this is against each work item (including closed requests)
    Here we keep our live database as trim as possible to help in this effort. 
    Meaning you can increase your queue count by decreasing your retention settings.
    It is all about the balance of what your environment needs/requires.
Sign In or Register to comment.