Notfications should be sent from a system account, but not from personal email alias

  • 4
  • Idea
  • Updated 2 months ago
Hi Team,

One of my customer from company (Forge Rock) is looking for a feature where Gainisght would send the notifications alerts (Ex: assigning of CTA,etc) under its own alias (Eg: systemadmin@xyz.com). 

Current Design : If the user enables the notifications, then scheduler jobs will take that user into consideration and notifications are sent from that particular user's email alias. 

Expected Design : Notifications (like CTA assignments or anything defined within notifications) should be sent from a system account and not as the person that enabled the notifications.

Alternative : We thought to create new and valid login credentials (Ex: systemadmin@xyz.com) and enable notifications with that user to get notifications from the expected email alias (Ex: systemadmin@xyz.com). But it seems to be bit backward and a waste of a license. 

Could you please consider this as an feature request (or) let us know if there is any alternative to achieve my client's requirement?
Photo of Hardik Mota

Hardik Mota, Employee

  • 338 Points 250 badge 2x thumb

Posted 2 months ago

  • 4
Photo of Karl Rumelhart

Karl Rumelhart, Official Rep

  • 10,242 Points 10k badge 2x thumb
One thing you can consider is using Journey Orchestrator to alert a user of a new CTA instead of the default Notifications scheme.  With Journey Orchestrator you can select the From email. 
Photo of Marcelo

Marcelo, Champion

  • 3,424 Points 3k badge 2x thumb
Thanks Karl! We could do that as a workaround, but would be really interested in fixing the notification issue as I can't prevent people from leveraging the system functionality and still getting emails as coming from me :-) But, thanks for the suggestion!
Photo of Lane H

Lane H, Employee

  • 9,144 Points 5k badge 2x thumb
One way to get around this is to use an Integration User for your OAuth user. So instead of it coming from you, it would be gainsight@xyzcompany.com

The catch here is the integration user would require a license.