PermaLinkAm I The Only One Who Wants Mail Rule Actions To Execute After I Read The Message?
09:08:51 AM

Mail rules are great, so why do I still use an agent to file my messages?

Let me put it slightly differently. Let's pretend that I don't know how to write an agent. Mail rules are great, so why don't I use them?

Either way I ask the question, the answer is the same: I want to file messages in a consistent manner, but I want to see most message before they are filed -- and I want that more than I want that consistency..

Am I an oddball? (Please limit the scope of your answer strictly to the issue raised above. Thank you very much.) I suppose I could be, but I have a suspicion that I'm not. I think a lot of people would really like to see the Lotus Notes client offer the options I've sketched into version of the Mail Rules dialog that's shown above. As part of the action definition, I think it would be really useful to have three options:

  • Run this action automatically when mail arrives.

  • Run this action automatically when mail is read.

  • Prompt to run this action when mail is read.

Yes, I know about SwiftFile. I like it a lot. I'm not currently using it because I've had a few problems with it sucking up CPU. Its database seems to get corrupted every now and then. But even if it were working perfectly, I'd still like full automation better: Read it. Close it. I'm done, and it's filed. No fuss. No muss. No thinking.

My inbox would be a lot less cluttered if I could do this. Because maintaining my filing agent is a pain, I have to confess that I don't go in and add conditions and folder destinations to it all that often. Consequently, a lot of things end up staying in the Inbox. There are 1631 messages in it currently, and I won't even tell you... I'm afraid to look!... at how many messages are in the folder that I call "Unsorted Stuff", which is where I manually move a big batch of messages every couple of months in order to get them out of the Inbox.

Would you like to see this feature in the mail template? How about in the OpenNTF mail template?

This page has been accessed 221 times. .
Comments :v

1. Ben Rose02/18/2005 12:15:03 PM

A great out of the box thought, but not the easiest thing in the world. I'm sure you know this, but the standard rules work in combination with the mail router on delivery. If a rule is in place the router automatically performs the action, e.g. moving emails straight to a folder. By delaying this action until after the message is read, would require another agent to execute, possibly creating significant load and queuing on amgr; which traditional rules don't utilise. Not saying it's impossible though.

The main problem with rules is that people use it for filing things like mailing-list subscriptions, event notifications etc. Once out of the inbox, these often get ignored and just build up. This encourages poor management of the mailfile.

What I'd like to see is an agent alongside rules that does a "return to sender" if unread after x days, just like the post office does with mail that needs to be signed for.

2. Richard Schwartz02/18/2005 12:36:03 PM


Interesting idea w/r/t "return to sender". As for implementation of my idea, I don't think queueing an agent to execute would be required. The existing rules code could set a special item in the delivered message. Let's call it $DelayedRulesAction. The queryclose code in the client could check to see if that item exists. If it does, it contains "instructions" that the queryclose code would follow. Then the queryclose code would add another item, which we can call $DelayedRulesStatus, where it records the result of the action. I.e., "Message moved to folder XYZ on 02/18/2005". Obviously, on subsequent accesses, that second field would tell the queryclose code not to execute the instructions again.


3. Ben Rose02/18/2005 12:59:22 PM

All interesting stuff, but don't forget that multiple rules may apply to each message and so priorities and stuff need to be taken into account. And these may have changed between message delivery and it actually being opened. A user could easily edit the rules in-between. What if the destination folder no longer exists etc. Take ages to code all that properly.

4. Richard Schwartz02/18/2005 01:57:36 PM

Good points. And also, my implementation idea depends on IBM adding the feature to the existing rules engine in the router. An OpenNTF implementation could not depend on the the $DelayedRulesAction item being there, so the queryclose code would actually have to evaluate the rules on-the-fly and determine whether or not any applied. Given that, an OpenNTF implementation would probably not even want to share the existing rules UI.


5. Keith Strickland02/18/2005 05:36:29 PM

This is very interesting. I wouldn't say it's oddball as everyone has a different way of doing things. It doesn't matter how many options you put in the rules someone will always want something else or more options.

I say the more options you provide to the end users the better, as it gives them more freedom to work however they want to work and not be limited by the product they are using. However, a line needs to be drawn somewhere as you start getting into bloat which slows the application down, so I think it's a very fine line between "State of the Art" and "Just Freakin Slow". How you determine where that line might lie is beyond me, but it is there none-the-less.


6. Nathan T. Freeman02/19/2005 04:08:36 AM

Actually Rich, what if the OpenNTF implementation worked like this...

If in a mail rule, you set the action to "Copy to Folder" then the message gets placed in the folder AND the inbox at delivery time. OpenNTF mail could check to see if the mail had been placed in the target folder, and if so, you could have an option to remove it from the inbox after reading. This would be relatively trivial to do, and would allow you to use both the existing mail rules UI and configure this behavior easily through your preferences.

We could actually do it such that it moves out of the inbox automatically A) when read; B) when forwarded; C) when replied to. If we wanted to get fancy about it, we could allow you to control this behavior depending on which of the target folders you copied the message into.

This lets us keep the rules workload on the router, with a small check on the QueryClose event of the Memo and Reply forms. Nothing outside what we've already done.

Whatdya think?

7. Bruce Elgort02/19/2005 10:47:36 PM

I am listening..... keep talking.... Vince you got your ears on?

8. Richard Schwartz02/20/2005 05:27:06 PM

Nathan, As optional behavior, that sounds great. I didn't think enough to realize you had the capability to modify the behavior of the rules engine via template changes, but it's just a formula field, right? So you probably can set a field as I described, and you probably can put it in both the target folder and the Inbox just by modifying the generated formula. I like it!


9. Old Dawg02/21/2005 09:06:06 AM

Actually for me I prefer it the way it is. I uses a Blackberry and directing some of the less improtant mail to folders before being read saves on clutter on the Blackberry.
I keep my inbox to one screen or less (I receive 40-50 messages a day). That's my rule ! Deal with it when it is read (the message).

10. Brian Benz02/24/2005 07:29:31 PM

I suggest linking rules to LotusScript events in the client. That way you can write an agent or users can pick from more events for rules.

There are many organizations that have to categorize and file email, so this would be a great way of letting users pick when they do this, or if some mail can be automatically categorized/filed.

As the events are already there, I can't imagine that this would be a big enhancement. But I'm not the one who has to do it....

11. vesoftware11/05/2013 10:17:14 PM

Agen Bola Promo 100% SBOBET IBCBET Casino Poker Tangkas Online
ITUPOKER.COM AGEN POKER ONLINE INDONESIA TERPERCAYA : Toko belanja online murah, Promo heboh jual barang hanya Rp 1,-

12. pharmacy09/22/2016 07:06:25 AM

I from had, , for daily use price noggin INGREDIENTS visit site instructions to is this.

13. chenjinyan11/22/2016 02:54:01 AM
Homepage: http://

14. 20161125caihuali11/25/2016 12:22:30 AM

15. chenyingying12/01/2016 09:13:14 PM

Enter Comments^

Email addresses provided are not made available on this site.

You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links

:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough

Remember me    

Monthly Archive
Responses Elsewhere

About The Schwartz


All opinions expressed here are my own, and do not represent positions of my employer.