I'm having one of those epiphany days

I can't remember the last time I was this excited about a technology. My keyword processing list is working very well. I've even come up with an enhancement to it that I will hopefully be able to do tomorrow--why bother storing the keyword definitions in a list item (and parse them as XML) when I could use...wait for it...Another list? I still don't know how to add a property to a list, so it'll mean hard coding a list name (probably _Keywords), but it'll give me more flexibility, as well as the ability to lock security down even tighter.

But that's not what has me so excited. I've got my Supportcenter lists working. Supportcenter is made up of two lists (both of them are Keyword Processing lists). One list is the main "Issues Log" list, and the other is a "Issues Detail" list. From a 10,000ft perspective, you log the main issue in the Issues Log, and then any detail (actions, emails, etc.) goes into the Issue Detail list. But the goal is to make this system email enabled, so the users only have to email their issues, rather than manage them on a web interface. That's where workflows come in.

Note: Workflows come in only after you install the infrastructure update and set a property as detailed in Microsoft KB 953289. Sharepoint SP1 broke the ability for workflows to automatically start from list items created via email.

I started thinking logically--have the emails come into the Issues Log list, and have that list determine if it's an open issue (meaning that the item should be moved to the Detail list) or if it's new. But that meant that anyone subscribed to get alerts to the Issues Log list would be notified for every message. So I had to stand on my head to see the answer.

Emails from clients will come into the Detail list. This list processes for keyword "CaseID", and if it exists, it fills the CaseID field. It then looks up the client and who is responsible for the Case from the Issues Log and notifies just that person and/or the client (it will not notify the person that created the item). The magic happens when an item gets created *without* a CaseID.

Then, the workflow takes the list item and moves it (actually, it copies it and then deletes it) to the Issues Log list. The Issues Log has it's own new item workflow. When and Item is created, it fills the CaseID field with the value of the list item ID (always unique). It then modifies the subject line of the item to append [CaseID:].

Another workflow exists for the Issues Log that runs when an item is modified; if, after modification, CaseID no longer equals the list item ID, it assumes that the entry is actually a followup detail for an existing case, and so it moves the item to the Details list (triggering the "new item" workflow in that list; thankfully Case ID is set now). If CaseID still equals the item ID, then it looks to see if an IT representative has taken responsibility for the item (the ResponsibleIT field). If so, it creates an entry in the Detail list (which, for those of you playing at home, will notify the client and/or the responsible IT person) saying that the Case has been assigned. It also changes the status of the Case in the issues log to "In Process".

I'll probably have a few more workflows in this mix, but that's the general overview of it all.