Best way to handle obsolete Assignment Groups in HP SM 9.33

Out-of-the-box (OOTB) Assignment Group deletion capabilities do not seem to consistently work / apply to all modules, in addition where it does apply, closed out interactions containing the Assignment Group that was deleted get overwritten with "DEFAULT" as the Assignment Group instead of retaining the original Assignment Group value (if "DEFAULT" was chosen as the replacement Assignment Group in the delete function).  This was not expected. 

This same behaviour does not apply to incidents containing the old Assignment Group -- only open incidents get updated with the replacement value; closed incidents retain the original Assignment Group value (this is what was expected).

Only the Service Desk and Incident Management modules' tickets seem to get updated by OOTB delete capabilities. 

In light of the above constraints, we require a solution to this to address the handling of obsolete Assignment Groups and it is my understanding that this can be done via incorporation of changes to the OOTB delete capabilites, or by adding a checkbox field to the Assignment Group form to control the status and visibility of Assignment Groups -- i.e., whether they are "active" and visible or not.

Is there a recommended approach on this amongst forum users?  Are there any risks to either approach (data-wise, performance-wise, etc. )?

Informed thoughts are welcome on this.  Thank you in advance!

  • Here's how we handle obsolete assignment groups: when I get notified a group is no longer needed, I remove all users from the asisgnment group, then on the link record (for whatever module you need this for, incidents, probsummary, cm3r, etc) I added the following in the expresions tab:

    $query="lng(denull(operators))>0=true

    This will make it so that the operator only sees assignment groups that have people in them.  This will also retain all historical info in older tickets.

    You can also specify specific groups in the same place by writing the query like:

    $query="not (name isin {\"group1\",\"group2\",\"group3\"})"

    or you can combine the 2 methods:

    $query="lng(denull(operators))>0=true and not (name isin {\"group1\",\"group2\",\"group3\"})"

     caveat: I am on 9.40 but I don't see why this wouldn't work. This was the method suggested to me by the 3rd party vendor we had help us implement 9.40

  • The "Best way" it's a matter of taste :)

    I usually use one active field.

    Wish you luck!

    Regards,

    Breno Abreu

  • Thank you for this suggestion fcbcd!  Something to raise with our technical resources and consider.

  • Hi Breno,

    Thank you for your input as well, and you're right, the definition of "best way" is subjective. :)

    I am assuming that only "active" Assignment Groups appear in selection lists (comfills, etc.) for the majority of Operators in your SM instance?  I'm not sure if you have a lot of obsolete / inactive groups, but if you do, is it safe to assume you haven't encountered any performance issues or anything of the sort / other challenges?  (I would think no to performance issues if you're using comfills, only displaying "active" group values to users, etc., but figured I would ask.)

    Thanks again!

  • Hello Giggs,

    No, I never had problems with performance with this strategy  Remeber that you always create new indexes and also think about purge/archive strategy.

    You have to define your requirements about the visibility and validation, some points:

    What if a group with records assigned needs to be inactivated. You can allow and let the updates occurs on records (IM,RM, CM, etc) with inactive groups and don't allow new attributions to the inactive group) or only change the active for groups without active records. 

    What if someone try to search a record using an inactive group? On search forms, it's good to let all groups or a checkbox like (list inactive)

  • Hello Giggs,

    No, I never had problems with performance with this strategy  Remeber that you always create new indexes and also think about purge/archive strategy.

    You have to define your requirements about the visibility and validation, some points:

    What if a group with records assigned needs to be inactivated. You can allow and let the updates occurs on records (IM,RM, CM, etc) with inactive groups and don't allow new attributions to the inactive group) or only change the active for groups without active records. 

    What if someone try to search a record using an inactive group? On search forms, it's good to let all groups or a checkbox like (list inactive)

  • Hi Breno,

    Thank you very much for your input on performance.  :)  You raise valid points and we have considered some of these like the fact that we need the ability to be able to search for historical records tied to inactive / obsolete groups -- this is a must.  As for the other point you raise, this is something we definitely need to iron out -- i.e., do we allow groups to be made inactive if they have open tickets associated with them (which I know will work on the system to allow these tickets to be processed still); or do we only deactivate a group if it has no open records associated with it?  We shall have these discussions!

    Thanks again.

    Giggs1