Re: Implementing data driven notifications
Hi Shyam, Yes, I am thinking of more towards multidimensional matrix. And possibly independent of any particualr app, like a separate module. So user can specify the form, filtering condition could be any combination of fields and values...to get notified, more data driven. Will contact you once we start implementation, right now I am just gathering some ideas. Thanks On Feb 26, 10:51 pm, Shyam Attavar atta...@sbcglobal.net wrote: Vamsi, One of the developers I worked with had built something similar on AR System 5.1.2 many years ago. It was a subscription mechanism where users could subscribe to the tickets based on certain categorization values. I had to maintaining the code for a little bit, but don't recall much of how it was built. I'll describe what I do remember and if you have further questions, email me offline and we can take this further. The whole mechanism was built as data driven architecture. There was a subscription dialog which users would launch and subscribe to get notified on based on the various categorization available in the system. The records for each user would be stored in a back-end form. When the subscription was saved a record was added to another back-end form, where the list of users that need to be notified for a given set of categorization and for a specific status value (ex: New, WIP, Resolved). When a record was either created or went to one of the states, the list of users would get notified. So, this design took into account the a categorization and status value combination (which makes a two way matrix for building the notification list). The notifications were only for one form, so this is not exactly what you are asking for, but we could extend the design further to allow for notifications from multiple forms. The one caveat that I would watch for is one would have to create a multi-dimensional matrix, so generating the list of users to be notified would be more complex. I know my description is a bit sketchy, but I hope this helps you move in the right direction with your design. Cheers, -- Shyam - Original Message - From: SriVamsi Patchipulusu vamsi...@gmail.com Newsgroups: gmane.comp.crm.arsystem.general To: arsl...@arslist.org Sent: Thursday, February 26, 2009 9:40 AM Subject: Implementing data driven notifications All, I know the following is not something that can't be done. Just would like to know what are some of the best practices people are using for notifications in custom built applications ( not ITSM) with little to none admin code changes for future maintainance. Currently we have several Notify filters spread across several forms in our custom built apps, Some are having hard coded groups,user names and some are data driven to that particular form/app. We would like to streamline this and make it generic as much as possible with mostly data driven. Anyone implemented notifications that covers all the apps? Something like triggering notifications from external form (not part of apps) as a blackbox with Subject , To , body , subscribing/removing users or groups are data driven. End users can create new notifications them self, with their own To,Subject, Body without remedy code changes. Thanks, Vamsi ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are
Re: Implementing data driven notifications
We did something similar to this for the Kinetic Request and Kinetic Survey applications when I was at Kinetic Data. It lets any authorized user via a Remedy User interface create message templates on their own. The emails were typically to fill out a survey or respond to a service request. Templates are just Remedy records stored in a Kinetic Message Template form. The message template authors put field placeholders in the email text via some drop downs based on the form they chose. We had options such as Plain Text vs. HTML, subject lines, reply-to, special link creation and other features, as well. These templates then get triggered via rules-based events. When the email is to go out, a filter pushes the record ID, and template ID and some other info to a Kinetic Message form. Some pretty complicated string substitution/SQL goes through and puts the field values from the specified record into the email. It works really well and is quite powerful. It then uses the Email Engine for the actual message delivery. Although I'm no longer at Kinetic, I'm still a big fan of their products: You could probably pick up a copy of Kinetic Survey and use just the email templating for less than it would cost you to build just this piece! -Kelly Kelly Heikkila :coderow ke...@coderow.com www.coderow.com On Feb 27, 2009, at 12:05 PM, patchsk wrote: Hi Shyam, Yes, I am thinking of more towards multidimensional matrix. And possibly independent of any particualr app, like a separate module. So user can specify the form, filtering condition could be any combination of fields and values...to get notified, more data driven. Will contact you once we start implementation, right now I am just gathering some ideas. Thanks On Feb 26, 10:51 pm, Shyam Attavar atta...@sbcglobal.net wrote: Vamsi, One of the developers I worked with had built something similar on AR System 5.1.2 many years ago. It was a subscription mechanism where users could subscribe to the tickets based on certain categorization values. I had to maintaining the code for a little bit, but don't recall much of how it was built. I'll describe what I do remember and if you have further questions, email me offline and we can take this further. The whole mechanism was built as data driven architecture. There was a subscription dialog which users would launch and subscribe to get notified on based on the various categorization available in the system. The records for each user would be stored in a back-end form. When the subscription was saved a record was added to another back-end form, where the list of users that need to be notified for a given set of categorization and for a specific status value (ex: New, WIP, Resolved). When a record was either created or went to one of the states, the list of users would get notified. So, this design took into account the a categorization and status value combination (which makes a two way matrix for building the notification list). The notifications were only for one form, so this is not exactly what you are asking for, but we could extend the design further to allow for notifications from multiple forms. The one caveat that I would watch for is one would have to create a multi-dimensional matrix, so generating the list of users to be notified would be more complex. I know my description is a bit sketchy, but I hope this helps you move in the right direction with your design. Cheers, -- Shyam - Original Message - From: SriVamsi Patchipulusu vamsi...@gmail.com Newsgroups: gmane.comp.crm.arsystem.general To: arsl...@arslist.org Sent: Thursday, February 26, 2009 9:40 AM Subject: Implementing data driven notifications All, I know the following is not something that can't be done. Just would like to know what are some of the best practices people are using for notifications in custom built applications ( not ITSM) with little to none admin code changes for future maintainance. Currently we have several Notify filters spread across several forms in our custom built apps, Some are having hard coded groups,user names and some are data driven to that particular form/app. We would like to streamline this and make it generic as much as possible with mostly data driven. Anyone implemented notifications that covers all the apps? Something like triggering notifications from external form (not part of apps) as a blackbox with Subject , To , body , subscribing/removing users or groups are data driven. End users can create new notifications them self, with their own To,Subject, Body without remedy code changes. Thanks, Vamsi ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text
Implementing data driven notifications
All, I know the following is not something that can't be done. Just would like to know what are some of the best practices people are using for notifications in custom built applications ( not ITSM) with little to none admin code changes for future maintainance. Currently we have several Notify filters spread across several forms in our custom built apps, Some are having hard coded groups,user names and some are data driven to that particular form/app. We would like to streamline this and make it generic as much as possible with mostly data driven. Anyone implemented notifications that covers all the apps? Something like triggering notifications from external form (not part of apps) as a blackbox with Subject , To , body , subscribing/removing users or groups are data driven. End users can create new notifications them self, with their own To,Subject, Body without remedy code changes. Thanks, Vamsi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are
Re: Implementing data driven notifications
Vamsi, One of the developers I worked with had built something similar on AR System 5.1.2 many years ago. It was a subscription mechanism where users could subscribe to the tickets based on certain categorization values. I had to maintaining the code for a little bit, but don't recall much of how it was built. I'll describe what I do remember and if you have further questions, email me offline and we can take this further. The whole mechanism was built as data driven architecture. There was a subscription dialog which users would launch and subscribe to get notified on based on the various categorization available in the system. The records for each user would be stored in a back-end form. When the subscription was saved a record was added to another back-end form, where the list of users that need to be notified for a given set of categorization and for a specific status value (ex: New, WIP, Resolved). When a record was either created or went to one of the states, the list of users would get notified. So, this design took into account the a categorization and status value combination (which makes a two way matrix for building the notification list). The notifications were only for one form, so this is not exactly what you are asking for, but we could extend the design further to allow for notifications from multiple forms. The one caveat that I would watch for is one would have to create a multi-dimensional matrix, so generating the list of users to be notified would be more complex. I know my description is a bit sketchy, but I hope this helps you move in the right direction with your design. Cheers, -- Shyam - Original Message - From: SriVamsi Patchipulusu vamsi...@gmail.com Newsgroups: gmane.comp.crm.arsystem.general To: arslist@ARSLIST.ORG Sent: Thursday, February 26, 2009 9:40 AM Subject: Implementing data driven notifications All, I know the following is not something that can't be done. Just would like to know what are some of the best practices people are using for notifications in custom built applications ( not ITSM) with little to none admin code changes for future maintainance. Currently we have several Notify filters spread across several forms in our custom built apps, Some are having hard coded groups,user names and some are data driven to that particular form/app. We would like to streamline this and make it generic as much as possible with mostly data driven. Anyone implemented notifications that covers all the apps? Something like triggering notifications from external form (not part of apps) as a blackbox with Subject , To , body , subscribing/removing users or groups are data driven. End users can create new notifications them self, with their own To,Subject, Body without remedy code changes. Thanks, Vamsi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are