locked
Using Email Channel Return Address in Notification Template RRS feed

  • Question

  • We're looking at using mailto links in Review Activity notifications for approve and reject like this post on the scsm team blog:

    http://blogs.technet.com/b/servicemanager/archive/2011/02/08/tricky-way-to-handle-review-activity-approvals-with-the-exchange-connector.aspx

    This is fine, but we manage more than one management group, so instead of using an explicit email address for the mailto link I want to use the Return Email address as configured in the email channel. This was I can use the same MP in each management group without having to manage multiple copies.

    I've tried using this:

    $Context/Property[Type='CustomSystem_Notifications_Library!System.Notification.Channel.SMTP']/ReturnAddress$

    with the correct MP reference, but it doesn't return any value. I guess I'm missing something, maybe a type projection?

    Anyone got any suggestions or know if this is even possible?

    Thanks

    Monday, October 7, 2013 7:31 AM

Answers

  • Hi Sendster,

    afaik there is no relationship between a workitem and the smtp channel. Since your $context is a review activity it doesn't make sense to link it to the returnAddress property as it's not found on that class or any derived classes (workitem)

    It sounds to me that you want to reuse email templates for different environments/customers. To lower the administrative burden you could make a powershell script to get the emailchannel and then replace that with your "dummy" emailadress in your xml management pack.

    Another option is to make a powershell or orchestrator workflow/runbook that sends the email.


    • Edited by Morten Meisler Tuesday, October 8, 2013 11:37 AM typo
    • Marked as answer by snedster Thursday, October 10, 2013 1:27 AM
    Tuesday, October 8, 2013 11:36 AM

All replies

  • Hi Sendster,

    afaik there is no relationship between a workitem and the smtp channel. Since your $context is a review activity it doesn't make sense to link it to the returnAddress property as it's not found on that class or any derived classes (workitem)

    It sounds to me that you want to reuse email templates for different environments/customers. To lower the administrative burden you could make a powershell script to get the emailchannel and then replace that with your "dummy" emailadress in your xml management pack.

    Another option is to make a powershell or orchestrator workflow/runbook that sends the email.


    • Edited by Morten Meisler Tuesday, October 8, 2013 11:37 AM typo
    • Marked as answer by snedster Thursday, October 10, 2013 1:27 AM
    Tuesday, October 8, 2013 11:36 AM
  • Thanks Morten,

    Yeah, I knew the simple context property I wrote was not going to cut it, but I was hoping it would be possible to create a relationship from activity (or workitem) to notification channel. I played with creating a relationship and type projection, but I realise now that a relationship between the classes is not enough.

    I was thinking that the E-Mail Notification Channel entry was like a system setting, as there is only one possible, but it's an object of the system.notification.channel.smtp class. Which is not applied anywhere to activities.

    You're right, it's about the admin overhead of managing multiple MPs for each environment that essentially do exactly the same thing. Just thinking about making life easier :-) Although I think I'll have to go with that for now, and maybe investigate the powershell options later down the track.

    Thanks

    Wednesday, October 9, 2013 7:50 AM