Trigger condition on email domain, where using an Organization is not viable
I'm trying to set up a trigger for any tickets submitted with a given email domain. I understand that the common solution to this problem is to create an Organization with a given email domain, and configure a trigger specific to that organization.
Unfortunately, this won't work in our environment, because the email-domain-based organization will not be the primary organization for all users - some already belong to other organizations. Only the primary org for a given user is considered in trigger conditions/tagging when that user submits a ticket. (Assuming this setting can't be changed, it should be considered a bug.)
User tags may appear to be another possible solution, but won't work because we can't predict what specific users will reach out, and don't have a comprehensive list up front.
How can I set this up?
cc @... this is related to a post you helped me out with recently; wondering if you have any ideas
-
Hi Charlie,
On this part: "Only the primary org for a given user is considered in trigger conditions/tagging when that user submits a ticket."
That's true -- in emailed tickets. If your users happen to use the Submit A Ticket in the Help Center they should have a dropdown to select which Organization.
-
Hi Charlie, can you shed some light on what you're hoping to accomplish? Are you wanting to measure how often certain specific email domains are used, or have your agents handle tickets differently from a specific domain? I'm not sure that we have a solution for you, but it could be helpful to know what you're after. Thanks!
-
@... That's new to me, and helpful to know. Emailed tickets are a fact of life in this case and need to be captured, unfortunately.
@... We are onboarding an institutional customer in the near future, and want any ticket submitted by any member of that institution to be marked with a high priority and to generate an email alert. We do this kind of thing routinely for VIPs and for existing customers by adding tags to the users (aided in no small part by your response to my last post!), but needing to account for hypothetical requesters who could only be reliably identified by their email domain is a new problem.
Please sign in to leave a comment.
3 Comments