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).
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.