Basically, I would like to not see notifications when I close my own tickets.  If another analyst resolves/closes my ticket i want a notification.

So the criteria should be something like:

Changed To: [Status] <Equals> Closed

And [Resolved By User] <Does Not Equal> Assigned To User

or maybe...

Changed To: [Status] <Equals> Closed

And [Resolved By User] <Does Not Equal> Me

But i cat seem to enter this through the console.  Any help?

Hi,

For me the solution is to add this condition :

And [Resolved By User] <Does Not Equal> [Assigned to]

but in subscrition or workflow only one Relationship is allow ...

Good luck

Im not actually able to add it though.  The subscription is based on the work item being updated e.g. closed.  Under criteria > Changed to I can only add resolved by users attributes like their user name.  So it actually looks like:

And [Resolved By User] User Name <Does Not Equal> [Assigned to]

Which didnt work. 

The subscription engine can't compare values from two different relationships, but, I do have a workflow assembly that can be copied to the workflow server to handle this. You just need to export your Management Pack that defines your workflow and add a new workflow array parameter of "UserAliasOrRelationshipsToSkip", plus change the assembly name and type like this:

<WriteActions>
  <WriteAction ID="WA" TypeID="SystemCenter!Microsoft.EnterpriseManagement.SystemCenter.Subscription.WindowsWorkflowTaskWriteAction">
    <Subscription>
      <VisibleWorkflowStatusUi>true</VisibleWorkflowStatusUi>
      <EnableBatchProcessing>true</EnableBatchProcessing>
      <WindowsWorkflowConfiguration>
        <AssemblyName>SCSMNZ.NET.Workflows</AssemblyName>
        <WorkflowTypeName>SCSMNZ.NET.Workflows.WorkItemNotification</WorkflowTypeName>
        <WorkflowParameters>
          <WorkflowArrayParameter Name="InstanceIds" Type="guid">
            <Item>$Data/BaseManagedEntityId$</Item>
          </WorkflowArrayParameter>
          <WorkflowParameter Name="InstanceTemplate" Type="guid">f9a5041d-1785-729d-3535-238022ad744d</WorkflowParameter>
          <WorkflowParameter Name="NotificationRulesEnabled" Type="boolean">True</WorkflowParameter>
          <WorkflowArrayParameter Name="NotificationTemplates" Type="guid">
            <Item>2a52fd91-c6e2-a23d-f4a1-f78876c4584f</Item>
          </WorkflowArrayParameter>
          <WorkflowArrayParameter Name="UserAliasOrRelationships" Type="string">
            <Item>15e577a3-6bf9-6713-4eac-ba5a5b7c4722</Item>
          </WorkflowArrayParameter>
          <WorkflowArrayParameter Name="UserAliasOrRelationshipsToSkip" Type="string">
            <Item>f7d9b385-a84d-3884-7cde-e2c926d931a5</Item>
          </WorkflowArrayParameter>
        </WorkflowParameters>
        <RetryExceptions />
        <RetryDelaySeconds>60</RetryDelaySeconds>
        <MaximumRunningTimeSeconds>7200</MaximumRunningTimeSeconds>
      </WindowsWorkflowConfiguration>
    </Subscription>
  </WriteAction>
</WriteActions>

If the target user for relationship UserAliasOrRelationships is the same as that for UserAliasOrRelationshipsToSkip, no notification will be sent.

Let me know if this is of interest to you. You cannot edit the workflow in the GUI after this. Well, you can, but you'll need to add the extra parameter in and change the assembly details

Thanks Rob! This looks like what I need.  Mine currently looks like:

<WriteActions>
          <WriteAction ID="WA" TypeID="SystemCenter1!Microsoft.EnterpriseManagement.SystemCenter.Subscription.WindowsWorkflowTaskWriteAction">
            <Subscription>
              <VisibleWorkflowStatusUi>true</VisibleWorkflowStatusUi>
              <EnableBatchProcessing>true</EnableBatchProcessing>
              <WindowsWorkflowConfiguration>
                <AssemblyName>Microsoft.EnterpriseManagement.Notifications.Workflows</AssemblyName>
                <WorkflowTypeName>Microsoft.EnterpriseManagement.Notifications.Workflows.SendNotificationsActivity</WorkflowTypeName>
                <WorkflowParameters>
                  <WorkflowParameter Name="SubscriptionId" Type="guid">$MPElement$</WorkflowParameter>
                  <WorkflowArrayParameter Name="DataItems" Type="string">
                    <Item>$Data/.$</Item>
                  </WorkflowArrayParameter>
                  <WorkflowArrayParameter Name="InstanceIds" Type="string">
                    <Item>$Data/BaseManagedEntityId$</Item>
                  </WorkflowArrayParameter>
                  <WorkflowArrayParameter Name="TemplateIds" Type="string">
                    <Item>b0bb7b54-e7b6-3089-dc1c-b3b30fd68978</Item>
                  </WorkflowArrayParameter>
                  <WorkflowArrayParameter Name="PrimaryUserRelationships" Type="string">
                    <Item>$Context/Path[Relationship='CustomSystem_WorkItem_Library!System.WorkItemAffectedUser' TypeConstraint='CustomSystem_Library!System.User']$</Item>
                  </WorkflowArrayParameter>
                </WorkflowParameters>
                <RetryExceptions />
                <RetryDelaySeconds>60</RetryDelaySeconds>
                <MaximumRunningTimeSeconds>7200</MaximumRunningTimeSeconds>
              </WindowsWorkflowConfiguration>
            </Subscription>
          </WriteAction>
        </WriteActions>

Since mine has PrimaryUserRelationShips instead of UserAliasOrRelationShips, should I change that?  Otherwise it looks like i can just add the WorkflowArrayParameter - UserAliasOrRelationShipsToSkip.

Also, is the guid under the UserAliasOrRelationShipsToSkip the relationship or variable [me]?

That's a subscription workflow, my assembly is designed to be used for workflows created via Administration\Workflows\Configuration. [Me] won't work in workflow criteria, it only works in view criteria, or actually, criteria used in the console context of the current user.

Hey

Another option for more complex criterias is to use Orchestrator as your notification engine. I used it lately for a customer that wanted something like this:

"If an End User or Analyst comment is added to an Incident, the Assigned to User should get an eMail. However, when the Incident is NOT assigned to a specific user, the Support Group (members) should get an email."

This can also be done using custom workflows in SCSM, but from a customer perspective it's harder to maintain the process ... at least that's what I think :)

Cheers
Marcel

Marcel, I know but we wont have SCO until later in the year and the techs are currently getting so much spam from SCSM that they aren't even looking at it.  I cant say i blame them either.  

Rob, thanks for the clarification.  I believe I have it working now.  T