One of my clients worked with a previous contractor to build out a small but useful HR application for the enterprise.  That contractor used SharePoint Designer to implement the workflow portion of the solution.  It’s a bit of a mess.  For instance, there are nine SPD workflows in support of a single logical workflow process and up to five of them may fire simultaneously at any given time given the right conditions.  It’s not easy to debug :)

My customer has a number of still-outstanding requirements, one of which is to generally provide more context when the system sends out email alerts – both in the email itself as well as associated task forms.  As SPD workflow implementers know, the “collect data from user” SPD action actually creates a task with a custom content type.  When we use that action, we don’t get to specify much.  We can prompt for some values (e.g. “approve” or “deny”) and we can specify a hard coded value in the title and description.  That’s about it.

My customer’s requirement is two fold:

1. When SharePoint sends an email about a task assignment, include a lot of information about the task in the email body.
2. More importantly, by far - when the user clicks on the task link in the email, the task form should have all the information the approver needs in order to make his/her approve or deny decision.  Right now, the manager needs to click on the item link itself to drill down into the underlying details and no one likes that.  You have to click in the email.  Then you need to click a sort of obscure link on the task item.  Then you can look at the underlying data (an InfoPath form in this case).  Then you click back/back, etc.  Everyone hates it.

I’ve inherited this somewhat messy technical solution and I want to make changes in the least intrusive way possible.

The approach I’m taking right now is to create a custom alert template.  You can read about that here.  The flow works like this:

• SPD workflow runs.
• At some point, it assigns a task to a manager.
• SharePoint system automatically sends out an alert to that manager.  This is not part of the SPD workflow but rather “what SharePoint does.”  (The SharePoint timer service, I believe).
• A custom alert handler is invoked in favor of the standard alert process (following magic rules as described in the above referenced article).
• When my custom alert handler runs, it generates a beautiful email.  More importantly, since it has the task in hand, it also decorates the actual task with all the context information necessary to meet the business requirement.
• The user gets the email and it’s full of useful context information.
• User clicks on the task link and the task itself is full of useful context information.
• Everyone goes home to have watermelon and ice cream.

I did a quick POC and it works well in a lab environment.  I get my custom email alert as expected.  I also get to update the task description and title itself.

The only tricky bit, so far, is to avoid a situation where the alert updates the item, triggering another alert.  This doesn’t worry me.

Looks promising so far…

The great thing about this is that I don’t need to muck about with any of the existing SPD workflows.  They are blissfully unaware that an alert handler is “IIZ RUNNIN IN DA BAKGROUND, DECORATIN TEH TASK LIST WIF MOAR CONTEXT”.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Update: The format for this is basically a conference call with a couple of PPT slides to set the stage.  We have a SharePoint environment on stand by to fire up in case it helps out, but this is mainly people talking out loud.  There will be opportunities for follow up by email.

Going back to my first ever SharePoint conference, just over a year ago, I’ve been struck by how terrific a live Q&A session can be.  The conference organizers had put together a sort of ad hoc group of “experts” (i.e. people who were hanging around and weren’t afraid of looking to silly up on stage) to answer any questions that came from the audience in the room.  It was in my head back then, and periodically since then, to host a similar session but do it on line and the phone.  I don’t think it can be as good as an in-person Q&A session, but I think it could be pretty cool.

I finally got around to it and next Thursday, 07/30, my company (Arcovis) and business partner, Integrated Systems and Services group, will be hosting a Q&A like that.  I’m hoping to do these regularly, as often as weekly. 

This inaugural session will probably be a little bumpy, but the concept is this:

• If you have questions that you’d like to have answered during the session, just show up and ask.
• If you want, you can email the question in advance.

We plan to spend the first half of the Q&A on emailed questions and then open it up to anything that anyone asks after that.

The session takes place on Thursday, 07/30 starting at 12:30 and ending at 1:30 PM EDT.

If you’re interested, kindly register here: https://www323.livemeeting.com/lrs/8000043750/Registration.aspx?pageName=pxlsd9fpsm2md7h9

The panel will include me and other SharePoint luminaries.  You’ll have to sign up to find out who they are :)

If you’d like to be one of those luminaries for a future Q&A session, let me know.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

I’m still living in InfoPath Forms world and I needed to make one of those “small” changes to a form that, unfortunately, breaks a naming convention I adopted with it two weeks ago.  I thought to myself, “someone is going to look at this thing a year from now and say, ‘What was Paul thinking?  By Jove, his naming convention makes no sense!”

I realized that I could create a view on the form for this and then, once again, realized that I could have been doing something like this all along.  I added a “Developer Notes” view to the InfoPath form as such:

I’ve configured the form so that users can’t get to that view and therefore, it’s only visible with the InfoPath client in design view.  Now I feel a little inoculated against some future unknown developer looking at my form and thinking bad thoughts about me.  Phew!

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

I seem to go through InfoPath phases where, out of the blue, I’m crafting a bunch of forms.  My fingers learn how to use the tool well and then I go through nine month drought and have to learn it all over again. 

I’m in the middle of an InfoPath phase and I’m creating InfoPath forms with a lot of views. One thing you probably notice is that the InfoPath 2007 client shows views in alphabetical order.  This is a real nuisance some times.  My best technique these days is to prepend a number to the view name so that they always show in the order I want, as illustrated here:

I wish I had been doing this all along. 

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin