locked
Looking for the right relationship between a RA and a SR for certain notifications RRS feed

  • Question

  • Hi there,

    can anyone please enlighten me what relationship I have to use when I want to notify the affected user of a SR when his request has been approved?

    Imagine a Service Offering you've published on the SSP for manager level employees to request new permanent Active Directory user. There he has to fill all the details to submit the SR. In the SR template there's a Review Activity included called HR Approval. Before the new permanent user gets created, HR has to validate that all the fields are valid (no typos in the users name etc.) and if so approve the SR.

    Now I'd like to notify the affected user of the SR that his request has been approved and will get implemented soon.

    Obviously I have to create a subscription with trigger class 'Review Activity' and trigger condition 'when object changes'. Additional criteria would be 'Activity Status equals Completed'. Is this so far correct?

    I'm struggeling now with the related recipients... I've tried several different relationship class to get to the 'affected user' of the SR such as 'Contains Activity -> Affected User', 'Has Parent Work Item -> Affected User', 'Has Child Work Item -> Affected User' etc. But none of them were the right ones. In the Workflow log I can see that the WF fires, but I don't receive any email at all...

    According to this blogpost http://blogs.technet.com/b/servicemanager/archive/2012/04/03/using-data-properties-from-the-parent-work-items-in-activity-email-templates.aspx I'd assume that 'Contains Activity' should be the right one but it's not apparently... Subscribing data in the notification template using this technique works fine, but I can't get it work with relationships unfortunately.

    Any help is very appreciated.

    Thanks

    Alex

    Tuesday, December 11, 2012 9:40 AM

Answers

  • You'll need to do some management pack diving :) Open up the MP where your subscription is defined. Once you find the rule, look for the "PrimaryUserRelationships" workflow array parameter. You'll see some <Item>s with some paths to related recipients.

    If you're still using "Contains Activity -> Affected User", you'll see something like this:

    <Item>$Context/Path[Relationship='CoreActivity!System.WorkItemContainsActivity' TypeConstraint='CoreActivity!System.WorkItem.Activity']/Path[Relationship='WorkItem!System.WorkItemAssignedToUser' TypeConstraint='System!System.User']$</Item>

    Change it to this (be aware of the references! Mine might be different than yours :) ):

    <Item>$Context/Path[Relationship='CoreActivity!System.WorkItemContainsActivity' SeedRole='Target']/Path[Relationship='WorkItem!System.WorkItemAssignedToUser' TypeConstraint='System!System.User']$</Item>

    If there's a way to do this with the GUI, I don't know what it is :(

    Remember that relationships are 2-way streets. The GUI, unfortunately, only seems to allow you to pick one direction (Source -> Target). So, editing the MP and setting the SeedRole='Target'  (and removing the type constraint) allows you to pick the other direction (Target -> Source). Essentially, the workflow was looking for an _activity_ related, as a target, to your review activity. But, you don't have an activity related to your review activity. This new path tells the workflow to pick a _workitem_ related, as a source, to your review activity.

    Tuesday, December 11, 2012 1:13 PM

All replies

  • You'll need to do some management pack diving :) Open up the MP where your subscription is defined. Once you find the rule, look for the "PrimaryUserRelationships" workflow array parameter. You'll see some <Item>s with some paths to related recipients.

    If you're still using "Contains Activity -> Affected User", you'll see something like this:

    <Item>$Context/Path[Relationship='CoreActivity!System.WorkItemContainsActivity' TypeConstraint='CoreActivity!System.WorkItem.Activity']/Path[Relationship='WorkItem!System.WorkItemAssignedToUser' TypeConstraint='System!System.User']$</Item>

    Change it to this (be aware of the references! Mine might be different than yours :) ):

    <Item>$Context/Path[Relationship='CoreActivity!System.WorkItemContainsActivity' SeedRole='Target']/Path[Relationship='WorkItem!System.WorkItemAssignedToUser' TypeConstraint='System!System.User']$</Item>

    If there's a way to do this with the GUI, I don't know what it is :(

    Remember that relationships are 2-way streets. The GUI, unfortunately, only seems to allow you to pick one direction (Source -> Target). So, editing the MP and setting the SeedRole='Target'  (and removing the type constraint) allows you to pick the other direction (Target -> Source). Essentially, the workflow was looking for an _activity_ related, as a target, to your review activity. But, you don't have an activity related to your review activity. This new path tells the workflow to pick a _workitem_ related, as a source, to your review activity.

    Tuesday, December 11, 2012 1:13 PM
  • Thank you Aaron. That was it!

    No idea why I haven't thought about manipulating the MP XML manually to add the SeedRole like in the blogpost.... I just noticed it's not possible specifying it via GUI and my brain probably stopped thinking further :)

    Cheers

    Alex

    Tuesday, December 11, 2012 3:25 PM