Edit in List Enhancements

Idea created by zad on Feb 20, 2015
    Not planned
    • J_W
    • buian01

    Assignment behavior is not consistent across Service Desk

    Recently I raised a support call with CA because we identified that assignment behavior differed depending on how an analyst carried out an assignment update. The outcome was that the following is expected behavior.

    • If an assignment update is carried out using transfer.  The assignee must be a member of the assignment group
    • If an assignee is updated using edit in list.  The assignee does not need to be a member of the ticket assignment group.

    I can see benefits in both options but think the product should behave consistently.

    We operate in a multi tenant environment.   

    Some tenants require

    • Strict rules regarding assignee's being members of the ticket assignment group.  The assignment group to assignee relationship match is required for management reporting.  Team workload and team statistics can be reported on more accurately.
    • Other tenants are more flexible and like the adhoc approach of being able to pass a ticket to an assignee external to the assignment group.    A benefit of this option is overall visibility can stay with an assignment group.  EG when a team is overloaded work can be passed to someone outside of the team without losing sight of the workload.


    I carried out a further test and installed from options manager "require_request_group" This will enforce the group required on the edit in list as per the expected definition of "prohibits requests with no value in the Group field from being saved". The option does not extend to requiring the group to match the assignee when edit in list is used.


    I have a couple of suggestions.

    1. Edit in list should not be available to all analysts. It has limited functionality and should probably only be executed by a service desk manager and administrator roles.
      • Limitations are:
      • Inability to document a comment with the edit in list update  (Ie ability to document why the edit in list was carried out.)   I have also read people asking how to carry out bulk comments on tickets that are not child associated.  Currently there is no way to do this.
      • No notifications are released regarding edit in list changes.   I agree that notifications probably shouldn't be released due to the potential to release bulk notifications but the person completing the update needs to know the system behavior.  
    2. Add a text description to the edit in list form advising that edit in list does not release notification messages.
    3. Via Administration options manager provide an option to force the assignee to match the group when edit in list is used.  Prefer this to be a setting by tenant but if only available as a  global setting it would maintain flexibility for different implementation choices.