Stephen-
Good for you. Building from scratch is the only way to go, IMHO.
I have an app with data-driven notifications (and messages) now, but not
as complicated as you spelled out. Our requirements were to allow
notification content to be changed, allow fields from the source ticket
to be inserted (or not), and allow recipients to opt in or out of
certain notifications. What I don't have is a way to change a
notification's trigger conditions, but that could easily be added (see
below).
It was easier than I expected. Basically, I created a form to store
notification content, and stored all the notifications by a title and a
number. Users can change the notification content by querying the form
by title (i.e. the "Rehire" message). When triggered, the system then
queries notification content by number, (Set-fields to a hidden
display-only field) and sends the notification from there.
To accomplish the requirement of allowing fields to be included, I added
a field drop-down with all the fields approved to be in notifications,
and when a user selects one, add it as a field reference, like so:
Warning: <assocFirst> <assocLast> has a higher job grade than
<SupvFirst> <SupvLast>.
Then before a filter sends a notification, it first replaces all the
field references with their values from the ticket.
All notifications are sent to groups. So users (with certain
restrictions) can add or remove themselves from notification groups by
updating their user record.
And finally, the notifications make use of HTML content templates, so
they all look pretty.
You could add the ability to change a notifications' trigger by use of
the EXTERNAL feature. You'd have to make a rather involved user
interface on the notification content form, with the end result being
the creation of a Run-If qualification, stored with the notification.
Then each notification filter must become two filters - one that
triggers on every submit (and/or modify) and pulls the qualification,
and a second that runs using the EXTERNAL function with that
qualification.
-Aaron
* Email: [EMAIL PROTECTED]
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Heider, Stephen
Sent: Wednesday, July 26, 2006 2:34 PM
To: arslist@ARSLIST.ORG
Subject: Data Driven Notifications
List,
I plan to create a new help desk system from scratch by the end of the
year. We have ARS 6.3 and HD 5.5. When finished there will be no
HD/ITSM, only ARS. The new help desk will be based on ARS 7.0 and SQL
Server 2005 with a sprinkling of ARS API.Net 7.0, VB.Net 2005 and ASP
2.0.
Because of the new Sarbanes-Oxley requirements I want to design the new
system to be as data-driven as possible. Changing a single filter takes
a lot more documentation and approvals than changing the contents of a
field on a form.
Remedy notifications are things that get modified occasionally.
Sometimes a certain group must have a notification, and then later they
don't or want it to go to someone else or want the trigger condition
changed, etc. I have begun to contemplate how best to make most or all
of the notification trigger conditions and message content pull from a
form instead of hard-coding within filters.
ARS is a flexible product and I am 99% sure this can be accomplished. I
have a couple ideas. Has anyone done this before? Any approaches that
you could recommend.
Stephen
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
SunCom is the wireless company that's committed to doing things differently.
Things we want you to know.
This e-mail and any files transmitted with it are confidential and are intended
solely for the use of the individual or entity to whom they are addressed. This
communication may contain material protected by the attorney-client privilege.
If you are not the intended recipient or the person responsible for delivering
the e-mail to the intended recipient, be advised that you have received this
e-mail in error and that any use, dissemination, forwarding, printing or
copying of this e-mail is strictly prohibited.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
