RuleSets vs. Notifcation - when and what and where...

Hi - I am going a bit crazy with all the different approaches HP has used in SM 9.40 to trigger notifications.

I.e SD close is triggerd in rulesets and in the backend transisitons in a ruleset on workflow for close.

Further on - the IM Close notification is triggered from the notification record but there is also a ruleset that triggers when entering the Clousere phase on Incident WF


Is there a document or any knowledge on where and how these are triggered? And what to use when?


BR Ivis.



    In the 9.40 PD build, each HelpDesk module (SD, IM, PM) calls notifications using the Send HTML EMail ruleset type.  Looking at an OOB 9.40 system with Codeless Mode enabled, I don't see any Incident notification rulesets that use the Send Notification ruleset type that calls the Notification Engine. I cannot reproduce the issue in a 9.40 out of box codeless system. It's possible this was added when the system was configured for your installation.  You  should alsomake sure that the probsummary Object indications tab is blank. If you can't track down whatever is calling IM Close notifications, set the conditions to false in the notification record to suppress the emails.


    Because the original change management build for Process Designer was delivered before HTML EMail was a standard SM component, Change Management is configured with Send Notification rulesets that call legacy notification definitions. Sadly, this was not cleaned up for 9.40. Where we've deployed PD Help Desk we've removed the change notifications and replaced them with Send HTML Mail rulesets to be consistent across modules. 

  • Hi and thanks for the reply!


    I did not check the object record so I will do that (keep forgeting about that :) )


    It is a clean install of 9.40 - so not sure what has happend - but I am the only one that has touched the Email Rulesets records and I have not modified anything in the notification records. Issue is that the close notifications from IM was being tiggered from the notification record, and not the ruleset because all OOB RuleSet were either replaced or removed from the WF but still eventout was filled with other IM templates and these were located in IM Close notification. So IM Close was triggering but the RuleSet with new templates in Enter on phase Closure was not.


    Am I to understand that if the notification record is not added in the Object record - it will not trigger? Even if the notfication record is set to true? Will something override another i.e a IM Close notifcation will override the RuleSet in the Clousere phase? I find that hard to believe but as my issue shows the RuleSet did not trigger, but the notification record did.


    BR Ivis.



    It's totally sending everything (I must have tested it badly). It is invoking the notification engine in the background. I haven't figured out why yet, but it looks like a defect to me. So far I can track this down. 


    If you run a trace at close, part of it includes:

    RAD: Rule.callProcess
    |0|          call.process
    |0| RAD:
    |0|          start
    |0|          check.process
    |0|          init.process
    |0|          select.process
    |0|          run.pre.exp
    |0|          check.rad
    |0|          run.rad.pre.exp
    |0|          call.rad
    |0|          call.rad.1
    |0| RAD:
    |0|          start
    |0|          check.callback.list
    |0|          write.linker
    |0| RAD: us.write.linker
    |0|          start
    |0|          decision
    |0|          rinit
    |0|          set
    |0|          add.schedule
    |0|          exit.normal
    |0|          cleanup
    |0|          decide.exit
    |0| <return>
    |0| RAD:
    |0|          message.close
    |0|          check.return
    |0|          mb.close
    |0| RAD: us.notify
    |0|          start
    |0|          init.notification
    |0|          select.notification
    |0|          decide.note.cond
    |0|          next.notification
    |0|          exit.normal
    |0|          cleanup
    |0|          decide.exit
    |0| <return>

    So far as I can tell, the calls some hardcoded notifications  and then invokes us.notify.  

    To me it seems incredibly sloppy. It isn't documented and in a Codeless build it should have been disabled and replaced with ruleSets. No one shuold ever have to trace RAD to figure out why SM is sending unwanted notifications. 

    I mass updated every SD and IM notification defintion to false. I'm still getting repeated notifications to the incident coordinator and haven't yet tracked down the source. 

  • I aggree as well. This is not good at all. 

    I also sending out some macro mail as well that I have never seen before and cant find the orign of. I found the mail but not where it is sent from. 


    This must be fixed. 


    BR Ivis. 

  • Hello,


    I'm overjoyed to find a recent discussion on this area of the Process Designer which still needs a lot more work.


    It is so very frustrating to read in the HP documentation that the HTML Email rule set is the way to go to implement your notification requirements in Process Designer, only to find the legacy notification process has not been made redundant in any module of SM 9.40, especially Change Management as picked up on by John (and there is no excuse in my mind for not completely merging Process Designer and HTML email enablement in 9.40 for Change Management).


    I have a ticket with HP Support currently regarding a notification issue, and even they respond by advising that you configure notifications through HTML email rule sets in the workflow if you are on a codeless system!


    Aside from the issue already touched on in this thread, whereby you need to be aware of the Document Engine configuration and update the pertinent notification records (e.g. add false to conditions to stop emails being generated), I have also encountered other problem areas.  


    I lost several days to working on notifications for my customer, to either remove notifications they don't want to see or add in / enhance notifications that they do want.


    Problem areas I have encountered:


    Incident / Interaction notifications generated which cannot be stopped


    This might be isolated to my system, but I have found the following issues:


    1.  HTML email "sd.close" is being generated for interaction closure (when a related incident is closed).

    2.  HTML email "RM Visible to Customer notification" is being generated for journal update on an incident related to an interaction (when ticking "Customer visible").  


    These emails are generated in spite of the fact that they don't feature in my custom Service Desk and Incident workflows at all.


    Aside from customising the OOB workflows, I have also updated Service Desk environment settings to - "Close Interactions when Related Record closes".


    These issues are currently with HP Support to investigate, but I have used the find utility (*afind.string) to search rule sets and also produced debug logs to look for a call which might relate but I came up empty.  The only workaround I have is to set the HTML emails to inactive (uncheck "Active" flag).


    Approvers of an assignment group cannot be targeted in an HTML email rule


    There is no ability to reference approvers of an assignment group using a HTML email rule set. Although HP seem to have implemented HTML email rule sets to move away from the legacy notification process (in addition, the 9.40 help directs you to use Assignment Groups to define approvers instead of Change Management Groups), they did not replicate the functionality which is present in notification records to configure the recipients as approvers of a group.


    Due to this deficiency, I was forced to use scripting to get the approvers of a group and use the legacy notification process.

    Notification for pending approvals in Change Management is not possible through workflow / rule sets


    Even though technically there is an update to cm3r file after an approval to reset the pending approval groups in field current.pending.groups, I found through testing that this does not seem to trigger “After update” or “After successful update” rules in the Approval phase of a workflow, thus making it impossible to do some action based on an approval event e.g. notify the next round of approvers.


    Due to this deficiency, I was forced to stick with the OOB notification process using Document Engine configuration.


    Notification to delegates for pending approvals in Change Management does not consider group delegation


    This is a longstanding issue - it was present at least as far back as 7.11.


    The function checkDelegation in ApprovalDelegationGroups script does not consider that a pending approver in field current.pending.groups could be an assignment group rather than an operator (in actual fact, it is more likely to be a group rather than an operator).


    Due to this deficiency, I was forced to stick with the OOB notification process using Document Engine configuration.



    I hope this information helps someone - at the very least, it helps me out to vent my frustration. :-)




  • I aggree as well - there are some challenges to be fixed here. 

    I can help you with these: 


    1.  HTML email "sd.close" is being generated for interaction closure (when a related incident is closed).

    - Check WF ruleseton Service Desk and backend transisitions - there are two close Actions there and these are calling the close emails. 

    2.  HTML email "RM Visible to Customer notification" is being generated for journal update on an incident related to an interaction (when ticking "Customer visible").  

    - Check the activityUpdate script (or activityXXXXX something - cant remeber which script right now) in SL and there is a line there that calls the RM email. Lousy fix from HP. Comment out the line that calls the RM email. 


    About the other things I am not to sure. Need to take a further look. 


    BR Ivis. 

  • Thanks for that information, Ivis.


    Overnight I received a HP product notification email which includes a released fix for the approval delegate issue.


    ID:QCCR1E117801 Status was updated to: Completed
    Title: Scriptlibrary ApprovalDelegationGroups Function checkDelegation does not include "All" module delegates
    Products: service manager > 9.30, service manager > 9.40
    OS: Windows
    Created: Wed Oct 29 2014 00:00:00 GMT
    Last Updated: Mon Sep 07 2015 09:07:43 GMT

  • I was wrong.  


    QCCR1E117801 actually doesn't fix the longstanding issue, to handle when assignment group(s) are listed in current.pending.groups and not individual approvers (as in the operator names).

  • If you want to increase the visibility of this issue, you could try asking about it during the Onine Expert Day on the SM Customer forum next week (you have to associate your forums login with your SAID to participate in the customer forum. 


    It might he helpful to open multiple topics, one for each issue noted above. (for example, rule sets for notification have not been updated to reference assignment group approvers). That would request a response to each issue. If it's all lumped into one post, it's may be difficult to get a clear answer.


    There's a lot about the merge of groups into assignment that was poorly handled, but the notifications issue takes the cake. 

  • Update for "Unable to select Assignment Group approvers in Send An HTML Mail rule"


    You can request a hotfix available for this issue: