When workflow was first added to PeopleSoft 5 back in 1995, the mantra was the three Rs: Rules, Roles, and Routings. I’ll bet that Rick Bergquist still has dreams where he is talking about rules, roles, and routings 🙂
Routings are the part that I wanted to highlight here. The two primary mechanisms for routings that PeopleSoft delivered as part of PeopleSoft 5 were worklists and email.
Worklists are great for people that spend a lot of time in PeopleSoft applications and have enough activity being routed to them that they actually check their worklist, but the broader audience does not typically login to PeopleSoft to check their worklist to see if there is anything waiting for them to do.
It’s sort of shame that more work didn’t happen on pushing out PeopleSoft worklist entries to whatever the end-user really use as their “stuff I need to do” list. There are some decent APIs that PeopleSoft delivers these days for accessing that data, but I’m not familiar with them being used for generically pushing PeopleSoft worklists into something like the Todo List functionality in Outlook or Lotus Notes.
In the absence of integrating their worklist entries with something else, most people ended up just using email as the primary mechanism of notifying people that they needed to do something like approve a purchase order in PeopleSoft.
There are some problems with relying on email though.
Historically the emails generated by PeopleSoft came from a system account, instead of being from an actual person. So PeopleSoft customers would make sure that the emails that were sent out all had text in them telling the person “please do not respond to this email”.
Makes sense, except that the whole reason that we’re sending out emails is because of it’s universality. Getting an email that you can’t respond to is kind of like getting phone calls from the robot dialers that political campaigns use; pretty annoying.
In newer releases of PeopleSoft this is less of an issue because there are more places where application developers took advantage of the ability to generate emails themselves in PeopleCode with more control than the core workflow framework provided. In fact, the Financials/Supply Chain development group did enough of this that they wrote an entire workflow framework using PeopleCode application classes.
In PeopleTools 8.48, that code (known as Approval Workflow Engine) was moved to core PeopleTools so that all applications and customers could use them. So if you’re up on an applications release 9.0 and higher, be sure to take a look at that.
We’ve talked with a number of PeopleSoft customers over the years that have ended up turning off workflow because of user complaints regarding the sheer volume of email that they receive. In fact, we just had someone searching our blog today for how to turn off notifications in PeopleSoft HCM.
The problem is that each event that happens (purchase order is entered) and the notification is tied directly to that. Immediate notification is important in some scenarios (confirmation of a customer’s order, employee terminations, etc.), but when someone in management gets 12 expense report, 15 purchase orders, 9 regularly scheduled reports, etc. showing up in their inbox scattered during the day they sometimes get annoyed.
One way of solving this problem is to re-write your notification processes so that the event and the notification are de-coupled. When the event happens, save off the data (could be in the worklist tables or some other tables) and then have a separate process that delivers the notifications separately.
The problem with re-writing these processes is that it’s time consuming and expensive, which is why a lot of people end up just turning off the notifications altogether.
It’s possible to send HTML email with PeopleTools, but a lot of the delivered workflow does not take advantage of this. On top of that the lengthy hyperlinks that can be generated for navigating directly to particular place in PeopleSoft (the navigation, plus the key values for pulling up the data) are not that attractive.
Generating notifications as worklist entries leaves a rich history of when the notification was created, worked on, and closed out. There are some nice delivered reports that come with PeopleTools that can show this sort of information. Take a look at the PeopleTools delivered Queries that start with WF. There are some Crystal Reports for those as well.
Tracking email notifications doesn’t happen unless it has been specifically coded into the notification process though. Lots of applications within PeopleSoft have added this functionality to key processes, but it’s very tied to specific processes. There’s no way to figure out what are all of the emails that a particular user is receiving (or see how many notifications are being generated for a particular process).
The topics discussed in this blog entry come direct from conversations that we have had with different PeopleSoft customers (especially from folks that are familiar with the email functionality in our Report Security and Distribution product; see the Report Notification section on the flash demo). Since we’ve seen continued interest in this topic, we went ahead and built something to fix it.
Here is a high level overview of what the Email Proxy does:
There are setup pages where you define the rules that you want for classifying the emails as well as the look and feel of the generated emails, as well as pages for being able to view the emails being generated, statistics regarding the emails, etc.
The Email Proxy server is in beta-testing now at a large PeopleSoft customer that services multi businesses with their PeopleSoft applications and should be generally available shortly.
Labels: 2009, Email, Products, Workflow