none
Inconsistent substitution string expansion in email templates - SCSM 2012 R2

    Question

  • Coming to the conclusion that email templates should not be stored in a custom MP ?

    I'm seeing odd begaviour where only some fields are expanded when the email is created. See below example where ID in the subject line has not been expanded but it has been expanded in the body of the email. If I store the custom template in "Service Manager Incident Management Configuration Library" then it works as expected.

    In the following notification, Subject has not been expanded yet when ID is used in a subsequent field in the email body it is expanded (Fault No.)

    Also Affected User Firstname has not been expanded.

    Subject: Your call has been closed.  ID: $Context/Property[Type='WorkItem!System.WorkItem']/Id$

    Fault No: IR223

    Fault Description: Testing Open, resolve & close notifications

    Dear $Context/Path[Relationship='WorkItem!System.WorkItemAffectedUser' SeedRole='Source' TypeConstraint='System!System.Domain.User']/Property[Type='System!System.Domain.User']/FirstName$,

    Please be advised that this call has now been marked as closed.


    Ian Moran

    Monday, July 28, 2014 10:03 AM

Answers

  • Ok ignore previous. If you're experiencing similar issues just delete the substitution strings and "Insert" them again.

    Ian


    Ian Moran

    • Marked as answer by konnexion Monday, July 28, 2014 11:41 AM
    Monday, July 28, 2014 10:28 AM

All replies

  • Ok ignore previous. If you're experiencing similar issues just delete the substitution strings and "Insert" them again.

    Ian


    Ian Moran

    • Marked as answer by konnexion Monday, July 28, 2014 11:41 AM
    Monday, July 28, 2014 10:28 AM
  • Did you perhaps copy+pasta some of the "substitution strings"? I have bad experience with this. Fix is just inserting them again.

    http://codebeaver.blogspot.dk/

    Monday, July 28, 2014 11:40 AM
  • That's exactly what I did and yes deleting the inserted strings and re-inserting did the trick. Thanks

    Ian


    Ian Moran

    Monday, July 28, 2014 11:41 AM
  • I suspect encoding-issues, but haven't looked into it.

    http://codebeaver.blogspot.dk/

    Monday, July 28, 2014 11:44 AM
  • it should be noted that those substitution strings are contingent on the MP that stores the notification template. for example, 'System!System.Domain.User' is only valid if the MP Reference "System" points to an MP that contains the element System.WorkItemAffectedUser, and that element is a relationship class definition.

    to break it down:

    $Context/Path[Relationship='WorkItem!System.WorkItemAffectedUser' SeedRole='Source' TypeConstraint='System!System.Domain.User']/Property[Type='System!System.Domain.User']/FirstName$

    • $ starts and ends a variable.
    • Context is one of the keywords that control the behavior of the variable, but in this case, you can read it as the target of the notification template.
    • Path[] means we are going down the projections path \
    • Relationship modifies path by specifying which relationship to follow in the brackets with the Relationship element.
    • SeedRole modifies path by setting which side of the relationship the starting objects is on, in this case, the "context" is the source of the relationship.
    • TypeConstraint filters path based on what's on the other side of the relationship, in this case, it must be a user.
    • Property[] means we're reading data from a property of this user, as opposed to pathing again
    • Type modifies property by controling which class to get the property set from
    • the last entry is the property name to get data from, i.e. the FirstName property.

    Consider http://technet.microsoft.com/en-us/library/ff719642.aspx and http://msdn.microsoft.com/en-us/library/ee533748.aspx, thou Context is new for service manager and is largely undocumented, I suspect it was added to address related classes, as (also speculation) Target may refer only to the target entity without its relationships.



    • Edited by Thomas Bianco Monday, July 28, 2014 3:28 PM clarification and better contexts
    Monday, July 28, 2014 3:21 PM