Replies: 1 comment 1 reply
-
I 100% most certainly know the exact type of use cases you're referring to and if there was one thing the stock connector taught me back in the day it was:
And as you might expect, I followed suit because I wanted to ensure there was parity so people could easily onboard. Plus it made the "how" of building automation a bit more straightforward by removing the choice entirely. I confidently knew that any Related User was potentially getting notifications, but my Affected Config Items were...well the actual impacted CIs! But I know advice like this is sometimes easier said than done given the host of automation scenarios one could configure within SCSM. I think if there was desire to move forward with this, it'd be the kind of setting that is enabled by default and you have to consciously disable. Maybe set the alternative relationship? Well I guess that could potentially mess things up too. Maybe pick the Relationships or none similar to a Request Offering? Hrmm...🤔 |
Beta Was this translation helpful? Give feedback.
-
The default behaviour when someone mails a comment regarding an existing ticket, is that the sender will be added as a related item to the ticket (besides adding the mail as a comment).
Sometimes this messes up requests with automations, that get data from a user object already added as a related item.
Maybe we could have a setting for turning off "add the sender as related item to the ticket" ?
Beta Was this translation helpful? Give feedback.
All reactions