CA Service Management

Has anyone come up with a way to populate the Group list created when you click the Group label in an Incident, Problem, Request, Change, to only show groups that the current Assignee is a member of?

Thanks,

Kevin

Hello Kevin,

Does this "View" Data Partition Constraint meet your need?

group.[group]member_list.member IN @root.id

If not, please expand on what is missing to meet your requirement. If so, flag as "Correct Answer."

Thanks, Kyle_R.

Hi Kevin,

Curious if you tried this and if it worked?

Tammy

But then the user would not be able to see groups they are not a member of.  The requirement was to only list groups that the current assignee on a ticket is a member of when the Group link is clicked.  Similar to the way the Assignee link works, it initially populates the assignee list with the members of the currently assigned group.  The user may have a need to be able to assign tickets to a group they are not a member of.

Hello Kevin,

Okay - got you.

Would this then be a variation on the above like:

group.[group]member_list.member IN <<put the ticket's Assignee field here>>

I'm not sure if you can do that with a Data Partition Constraint. In particular the testing should take account that a lot of the Assignee/Group functionality flows from having the Group filled in, and then the Options constrain the Assignee field. Whereas what you are talking about is the reverse.

It would seem to be more SPL code on the ticket itself? ? ?

Thanks, Kyle_R.

Check this link, this might be of help:

http://www.servicedeskusers.com/forum/lofiversion/index.php?t4444.html

Ah. Good tip. Thanks Abhishek_Asurion.

The key words here which may help in other searches are "dependent dropdown."

And yes, the Service Desk Users Forum is another great location for SDM information. It's been around for a while.

Thanks, Kyle_R.

Hi, I'm a bit confused as to why this would be something requiring custom code to do, when you're doing the exact same thing in reverse out-of-the-box -- when the group field is populated first, the assignee list only includes the analysts who are in that group.  So this is simply the opposite -- when the assignee is populated first, the group field should show only those groups that analyst is a member of.  This has always seemed to me like something that should have been coded as out-of-the-box functionality from the beginning.

Thanks,

Tammy

May be for the reason..at times we know of the Analyst whom we need to assign the ticket but do not know of the group(s) he belongs too, or the exact group name of Analyst in SD.

Yes, that would be the use case.  My question is that since the application is already doing this in reverse, why does it not also do this? (rather than having to create custom code for a dependent drop-down scenario).

Tammy

Hi Tammy.

This "reverse" implementation is there, yes, but it is a specific functionality, programmed hardcoded exactly for this aproach. I have quite a few different code places in mind, which involves htmpl, javascript and spell code, where parts of this functionality are implemented, and which are working all together to provide this functionality.

I would not say, this could not be done, but I assume, if you want a comparable behaviour like you have in the "reverse" functionality, there is some effort to invest, and I think, it would get tricky, that both functionalities would not harm each other.

I remember a customer which asked me exactly this question, I tried to convince him, not to go into this direction. The common way is to assign a ticket to group, not to an analyst. The group is specialized on certain topics, and therefor will be addressed to solve a problem. Who in the group personaly will do the work, is a responsibility of the group itself. So everyone in the group should monitor their group ticket list for unassigned tickets, and pick these up. Someone who is already busy with working on another problem should not be assigned to a ticket, where he can't work on. Another one, who just finnished something, could easaly assign the next ticket to himself.

Regards

...............Michael

Hi Michael,

While I would agree with your 'best practice' approach, there are situations where it isn't appropriate to just route to a group with no assignee.  And since the logic is already there out-of-the-box to show only assignees that are in the group selected, then it's natural to expect the same functionality out-of-the-box to only show the groups the analyst is a member of for the assignee selected. 

Thanks,

Tammy

Hello Tammy,

Good points.

I suspect that the reason why it has not come up before (Assignee restricts Groups) is because the typical case is that the Assignee is the logged in user.

When combined with the very common Data Partition mentioned above, restricting the Groups to the logged in user, then there is "in practice" a restriction of Groups to ones that the Assignee belongs to.

The case where this doesn't work is where the Assignee is not the logged in user, and you wish to assign a Group to them - which you can do, but is not filtered here as requested.

This may be a good case to log as an Idea.

Hello KevinG.,

Please check out the comments from other Community members above.

Thanks, Kyle_R.

Thanks, Kyle.  As Kevin already knows (because he did our original implementation back in January 2012), this has been on my 'list' ever since then, so I guess I failed by not submitting an enhancement request for it back then.

You said 'the typical case is that the Assignee is the logged in user'.  But here is my use case, which I would think is very typical of any Service Desk team -- The Service Desk receives a call about an urgent issue.  They know that John Smith is the analyst that needs to assist with this, so they follow their procedures to call John to start working on it right away.  The procedures are to assign the ticket directly to John, since he is now working on this urgent issue.  John is a member of 5 different 'groups', and they cannot remember the name of the group that is most appropriate for this issue.  So they want to be able to assign it to John, and then click the link on the group field to see what groups he is a member of, and then select the appropriate one.

Another use case is:  A ticket has been assigned to a 2nd level team.  Mary is working on it, and she calls Joe on the Telecom team to discuss the issue.  Joe says it looks like a telecom issue, so he tells Mary to route it directly to him and he'll work on it right now.  Mary doesn't know what the group name is for the Telecom team, but knows she needs to get this ticket to Joe.

I will submit this as an idea now, with the above use cases.

Thanks.
Tammy

Actually, there already is an idea posted for this, created on Nov 10, 2013 -- I've just voted for it.

FInd group based on member(s)

And here's another one, from back in 2012, which I had already previously voted for.

Group Dropdown for Assignee

Thank Tammy - very helpful!

I've gone and voted both of them up, as I understand where you're coming from with those use cases.

I advise others to do the same if interested. They are both currently at "Under Review" stage.

Thanks, Kyle_R.