2 Replies Latest reply on Mar 31, 2015 7:30 PM by Brendan Murray

    Notification Templates - Questions & Suggestions

    Brendan Murray
      Share This:

      I like the flexibility of being able to define your own format for the notification event, so thanks for adding that. However, I do find the UI a little confusing. That's inevitable when you give the user the ability to create a sub-object, i.e. a Notification Template, while they are defining a main object, i.e. a Notification.

      Notification Template UI.png


      1. Why are we using the term Event Route? The BPPM server or cell is the event destination, not the route.

      2. Why is the name of the event route repeated inside the template box in bold print? It looks like it's meant to be the name of something, but what? It's not, for example, the name of the selected template. Are we planning to allow multiple event routes per notification? This would only make sense if that were the plan. However, until we do that, it's confusing.

      3. The notification templates box should be named "Notification Templates" or "Event Templates". Right now, it's not clear enough that this is a set of secondary objects that are related to, but not part of, the Notification definition.

      4. Why is the Event Severity selector inside the main box? Again, this only makes sense if we plan to allow multiple event routes per notification. Right now, the Event Severity is a property of the Notification, not the Template. It should be outside the box so that is clear.

      5. Why does the name of the default template contain no spaces? It makes it look like spaces are not allowed. They are allowed as the screen shot shows.

      6. The name field and the message field are not left-aligned.

      7. There needs to be a help button that lists the macros that can be used in the template. We should not force the user to look this up in the docs.

        • 1. Re: Notification Templates - Questions & Suggestions

          Brendan, thanks for the detailed feedback and suggestions.  We wanted feedback on this and details are always a good thing.  Some the labels etc.. were just not scrutinized much up until now, so this will force a bit more focus on same and your suggestions  will be considered / assessed.


          One specific  comment that i think is important which I want more feedback on:

          Brendan>>>That's inevitable when you give the user the ability to create a sub-object, i.e. a Notification Template, while they are defining a main object, i.e. a Notification.


          I agree with you on this point and this was my main concern from the usability perspective - as  I think its going to be common to want to re-use a template but still make minor changes (otherwise customer may end up having to create way too many templates).  Any additional suggestions on how to resolve this (easily without redo)?   One thought which i think is related to your above comment , is that   is that we separate the "Edit" and "Create" of Template  from the actual  input of the Notification ( don't make them overlap as they do currently).  This would allow users to select a template and update it directly in the Notification WITHOUT changing the Template ( as Template edit and create are  done  separately). 


          • 2. Re: Notification Templates - Questions & Suggestions
            Brendan Murray

            To be honest, Joe, I am not sure how necessary the Notification Template construct really is. If you separate the Edit/Create Template functions from the definition of the Notification, then the template serves as a true template, i.e. a reusable pattern. It is a named event format that you incorporate into your notification, either 'as is' or adjusted to suit, rather than a linked sub-object that is referenced by the notification. Once the notification is saved, the event format is saved with it and is completely divorced from the template that was used to create it.


            I think this is a sensible approach, but I don't know how many templates you really need at that point. I could see myself using just one template, with standard literal text and ALL the macro variables included for reference. When I create the notification, I just use my one template and adjust it as necessary, including deciding which macros I want to use. It's not like it takes a lot of time to customize an event format. It's just some literal text and a few macros.


            That said, I certainly don't think Notification Templates are a bad idea. I may be underestimating their usefulness. I do think it will be easier to manage if the templates are copied into the notification definition statically, rather than being referenced. For one thing, this would prevent the situation where someone changes a template that is referenced by fifty Notifications and makes a big mess.


            One feature I would like to see is the ability to preview what your notification event will look like, based on the format you have defined. As it is now, you have to create your notification, run it manually and then check BPPM to see how it looks.


            One other feature I would like to see is, when you run a notification manually, there should be some indication in the UI as to whether a notification event was sent to BPPM. The way it works now, if you don't get a notification event in BPPM, you don't know if it's because something is broken, or simply that your saved search didn't get a match.