Personalized responses controlled through data partitioning


Article ID: 142757


Updated On:


CA Service Management - Service Desk Manager


Is it possible within the system to have global personalized responses not for the entire environment but data partitioned for example to particular groups?

One may wish to create group specific global personalized responses (in addition to global personalized responses) that can be filtered by data partitioning.  Creating personalized responses per individual may not be practical for larger teams who need to disperse closing statements between each other.

The existing Service Desk environment uses the system with individualized teams for handling incoming calls.  Other groups may handle the creation of specific user access accounts within the agency.  When Service Desk closes a ticket, they have very specific closing messages - depending upon the type of ticket - that they need to send out.  Other groups would have a completely different set of closing tickets - depending upon the type of ticket - that they need to send out.

Making all of those GLOBAL while does work because everyone can access them starts to create a massive list especially when one considers multiple groups that could be defined.  Being able to provide personalized responses per GROUP or team rather then per individual or global would be highly beneficial if it is possible.


Release : 17.2



Unfortunately, it is not possible to have personalised responses fall under control of data partitioning.  However, one thing to consider is to use Notification Rules and tie the condition based on an element that is specific to the assignee or the listed group.

Example:  A ticket is assigned to the "Service Desk" group (the request ticket lists "Service Desk" as the listed group on the ticket).  When you close the ticket, under the "Closed" Activity Notification, you can create a notification rule that checks the given ticket's group value, and depending on the given group, if group = "Service Desk", then send out the given notification message that is associated with that particular rule.  You could create multiple notification rules which are each meant to apply for that specific group.

The only drawback is that you would need as many Notification rules as there are groups, ie:  200 groups each need their own  Notification rule, which would affect maintenance overhead.  This also requires that all such tickets have the group field defined.  It would not be possible to look up the assignee's group  as the assignee could belong to multiple groups.  

That being considered, one idea to simplify things would be to consolidate the Notification Rules if a set of groups present a sufficient similarity to their message content, have the given groups share in the same notification rule message content.