How to send a Notification if the Group changes, but NOT when the Assignee only changes, within Service Desk Manager

[Kyle_R]

Hello Everyone,

 

Reaching out for suggestions on the following query I received. I'm a bit stumped, so thought I'd try here for input!

 

IN BRIEF

* Send a Notification if the ticket's "Group" changes.

* Do NOT send a Notification if the ticket's "Assignee" changes "within Group." (That is, new Assignee, but the Group stays the same.)

 

FULL REQUEST

-------------------------

We have a requirement to limit transfer notifications for one client where they are assigning from within the same group to an individual within that group.

 

Current behaviour: When a ticket is transferred to a new group or to a new assignee (including within the same group) a notification is sent advising of the transfer.

 

Desired behaviour: Transfer notification will be sent when a ticket is transferred to a new group or a new group and assignee, but will not be sent if the transfer updates the Assignee only.

 

We have experimented with different options within the condition macros and have not yet been able to get the desired outcome.

 

Requesting assistance / guidance on whether the desired outcome is possible and can be achieved with a site defined condition - or requires a custom build Spel condition.

-------------------------

Any ideas on how this could be achieved "within system?"

Or with customisation, if necessary.

The catch is that the standard "Transfer" Notification will pick up on both Group and Assignee. But we only want to check for one in this case.

Thanks, Kyle_R.

[Michael Mueller]

Hi Kyle,

Maybe I miss something, but what's about the following approach:

Creating a site defined condition which checks, if the group has changed by comparing the Group and Group_Previous values.

Then using this as a condition in the Transfer notification rule.

Hmm. Should work I think..... This wasn't tested, so please give it try before telling the customer....

Regards

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

[Michael Mueller]

To fast . I did a short test and recognized, that the Group Previous attribute holds the last group different to the current one, even if the group has not changed. So my previous approach will not work.

 

To my knowledge, there is no other reliable possibility in a notification rule condition. The condition is executed after all the changes were made persistent. In this context, you don't have access to the information if the group attribute has changed. Unfortunately, you even do not have access to the current activity log, becasue the condition macro is executed in the context of the corresponding ticket, not the activity log.

Sure, one may think of someting like : find the last transfer activity for the given ticket, check, if this activity was written in the last, lets say, 5 seconds. Then check, if the description of this activity includes a text like "Transfer Group from 'group1' to 'group2'". Yes, this may work, but would have the disadvantage of certain assumptions (timescope of 5 seconds, hardcoded text comparison). Let me know, if the customer want to go this way......

 

But I have another appoach, which may fit to your customer needs (already tested ):

The idea is to write different activities depending on which attribute, assignee or group, has changed.

I created a new Activity Notification "Transfer Assignee" and changed the Activity Association for the Assignee Attribute to this new Activity Notification.

Now, whenever the assignee gets changed, an activity of type "Transfer" Assignee" will be generated.

When the group is changed, an activity of type "Transfer" will be generated.

By separating theses activities you are able to define your own notifcation rules for these different cases.

The disadvantage of this approach is that if both attributes gets changed, two activites will be generated, and you don't see, if "the other" attribute has changed too.

 

Hope that helps a bit.

Kind regards

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

[Giedrius Bekintis]

Hi, Michael

Don't you think that in this case use of Transfer activity (from activity menu) to change assignee will generate two activities "Transfer" and "Transfer Assignee". This is because activity type "TR" is hardcoded in link of transfer activity.

[Michael Mueller]

Yep, warrentable doubts, Gutis.

I did a fast check, and it works quite well. When going through the Actvity Menu and opening the Transfer Activity, changing only the Assignee, only the "Transfer Assignee" activity gets written (with the comment entered). When only changing the group, a "Transfer" activity gets written, and when changing both, both activites gets written, both with the entered comment.

[Giedrius Bekintis]

I think the best way to do that, is to use spell code. On group change you can attach an event that will send notification for you. It's something similar to this post: Notification (or any other action) on call back date for the requests

[Kyle_R]

Thank you both, Michael and Giedrius,

 

I was afraid that it would come down to something like that. It is good to have some experienced feedback.

 

 

Was trying to avoid SPL . . . but well, as most admins. know, sometimes it is just the right tool for the job.

 

 

Thanks, Kyle_R.