@Chris,

I love this feature in Outlook. Why not in Notes?

First of all, an agent can already be used to accomplish the creation of an email like this in the background. Except that it's sent at the time of the agent's execution.

Also, can you give me a reason why this is needed from a individual email account? One could argue that an HR person should be able to create a mass email ahead of time and have it sent to all employees at a particular time. But this should be moved to an HR application with functionality to do this.

I don't think IBM should be focusing on this ahead of other router/mail.box enhancements. Are there uses for it? I'm sure there are. Am I a fan of this? No - thus my vote. :)

By the way, when you do this with an Exchange account, does the client or server handle the delayed processing?

@Chris,

Executive secretaries, Plant and Facilities staff, Cafeteria, IT etc. As for Outlook the client handles this feature and not the server if my memory serves me correctly.

What specifically would they need to send that would be time-sensitive? If it's sending out daily menus, then that should be done from an application. The same with IT notifications for system outages or whatever else.

As far as the client handling this, what happens if the client crashes (not that this EVER happens with Notes...)?

Chris - I don't argue with my users. They are my customers :-). If they have a need it is my job to fulfill it.

I can understand having to use Outlook to fulfill this - since there's no simple way to develop this on Exchange. However, if my customers wanted something like this, I would try to fulfill it in a manner that would exceed their expectations of "just email"...

@Chris - but if all they want to do is sent out a delayed email message how can you "exceed" their expectations? Keep it simple.

I can created a shared application where multiple people can schedule notifications. They could also share the responsibility for editing and proofing the notifications as well as view past and future messages.

I could also just modify the mail template to allow for this if I wanted to. Have you done this with OpenNTF yet? ;)

Again Chris - you are wanting to build something that Outlook already has :-). Game over. I have promoted this GREAT idea.

Thanks for the support!

Some applications:
- a happy birthday mail on time (e.g. to the spouse/a friend/a client)
- don't forget the wedding anniversary!
- send a colleague a reminder (instead of putting a reminder in my calendar to remind him)
- send some documents right on time, even when finished long before

I've been thinking about a server extension to do this but that would make the solution platform-dependent. It seems kinda easy though: if an incoming mail has a field DelayUntil, just put it on Hold and then release it at about the right time. Any server-trigger will do a clock-tick.

Typo: ... as clock-tick.

This can be done by a minor tweak to the mail template and a "Deferred Mail" mail.box, in which a single agent is responsible to sent deferred emails for all users.

The "tweak" includes: add a tab to the (Delivery Options) subform with a checkbox "Send later" and some date/time field(s) and add some lines of code to the CoreEmailClasses script library (QuerySave(), 2 times in Case MEMO_SEND, one time in Case MEMO_SEND_FILE), and create a copy of mailbox.ntf and add an scheduled agent, and perhaps some views, some fields to the Memo form, an agent to send immediately, a way to cancel,... ;-)

There's a few times I would like to have had "Send it Yesterday" ;-)

@Thomas: I've been thinking about that too, but IMHO it can hardly be called a "minor" tweak. Also, the scheduled agent cannot be guaranteed to run at the exact time the mail should be sent.

The server extension could probably do it, it requires one extra field in the mail. What I'm not quite sure about is if a Unix-like alarm(n) is permitted in an extension module. The server extension should attach itself to the incoming mail stream, check the presence of the field and put the mail on Hold if the date/time value is in the future. A parallel process should check regularly (preferably with alarm() and not actively polling) the queue of mails held in mail.box.

The idea of a separate mail.box database for deferred mail I like a lot, it would allow a corrupt mail.box database to be deleted and still the deferred mails would be sent at the right time, for they are in a separate database. The additional database should be internal to the server extension, and not be fed directly by a user's mail database.

Disadvantages of both implementations are that installation is not easy. The roll-out over an organisation may take some weeks. The server extension could be installed on the server but should in fact also be made to run on a local system.

Anyone in favour of an OpenNTF project on this matter? Or has someone already started?? :-))

I think this is a great idea - and one that has been requested by my users from time to time. However, any solution should also allow the user to manage their deferred mails - give them the opportunity to cancel/modify pending e-mails.

The I don't think it's all that difficult to implement if you do it purely client side. Use a NotesTimer coupled with a folder for deferred e-mails. You aren't going to get a high level of precision but you can get something that's mostly good enough.

@4 - If Outlook is closed the user is prompted whether to send or cancel the e-mail when they reopen it.

@Charles: I tend to shut down my PC when I go home...

While a nice feature for the users, I am concerned about the layer of complexity it would add and the potential for troublesome support calls. Ninety five percent of the users would use it appropriately but we all know the ones that would scream murder if a mail didn't get sent when directed or their neighbor who wants to schedule a weekly reminder email for the next 10 years. I am not suggesting it should not be done, but it would need to be done right and have administrative controls to manage it.

@1 - Agree completely. Although I would like it to send immediately to the router, and let the server router worry about the delayed delivery time. Obviously, that brings another layer of complexity to the request.

Hey guys. We have this implemented in our R7 shop (worked when we were R6 as well). I can't take credit for the code, I've had it for years, and only tweaked it for my own personal needs.

Our people use it all the time. and it's user friendly so no IT involvement is needed.

It runs as a server task, and we only allow it to run once per day (agent is set to run at Midnight).

I've just started poking around idea jam, so not sure of the protocol - if you would like the code, send me an e-mail and I'll make a shell database with all the 'stuff'. After Lotusphere of course!

jjenkins@american-appraisal.com

- - - Jamie

Clarification, not a server TASK, a server agent - sorry 'bout that!

This idea will be quite useful for sending out business newsletter e-mails in large numbers at varied times, since sending out a large volume all at once may be treated as spam and blocked.

Its a good idea and I did see reference to a notes application years ago that did something like this. I don't think that it should be standard functionality for all users though as the potential for disgruntled employees or other misuuse is to high. This is mostly likely an HR or marketing style requirement so build one if they think it would be useful and just add a button in the notes mail template that lets them use it if they are authorised.

We have modified our mail template to permit Delayed Send. It's pretty popular.

A little behind the discussion here, as this idea escaped my radar earlier...

@8 @9 --> Can be handy to have a central place for frequent messages, as people can be ill, on leave, vacation, or have computer issues preventing the company-wide notification from being sent on-time. Chris' idea resolves that matter and in a way that "exceeds expectations".

@19 For larger client sites, the server's mail.box would bloat and cause mail delays as it would constantly have to skip over held mail till the targeted time--killing performance for heavy usage infrastructures. Perhaps creating a maildelay.box where a delayed message has a flag set and the router task notes this and transfers the message from the mail.box to the maildelay.box and that has a new mail agent that reads the delivery time and sets a mail delivery agent to run at that time (rather than having an agent run every :05 minutes) Just a thought...

@5 I agree with your customer management approach; so although I will promote this, I have reservations on the implementation approach.


All -- isn't this why Lotus created mail priority delivery thresholds? Just set the priority for mass messages to low and have the router send it at the appropriate time, as configured by the admin--can also set transfer times for high and normal priority as well. It's not elegant, but it works and is available now. In the short-run, this might be a better way to approach this matter.

I agree that if it is completely controlled by the client, this can lead to four scenarios:
* Issues with the mail not being sent at the desired time due to hardware changes (not all IT Teams pull the local mail.box file or check it for messages)
* Shutting-down Notes (forgetting that you have a delayed message you composed and sent four hours earlier)
* Notes crashes causing corruption to any number of local databases/applications
* Duplicate messages (as a defense mechanism from above and the user re-sending it b/c they felt it wasn't going to be sent and they needed to get it out by the boss' deadline)

Microsoft has to implement this capability via the Outlook client as it is really challenging to modify new capabilities into either Exchange or Outlook due to the lack of a properly integrated development environment. So, users of that client get lulled into thinking what they have is great, but masks limitations--IMHO.

I think it can be handled as a server-side add-in and avoided mostly on the client--with other than a checkbox in Delivery Options to delay message with a time-date field. Let Domino handle it from there. You can make an argument for a template fix and logic, but the client is less stable than the server...so I think it makes sense to move it there and avoid some support calls for missing mail.

It's a feature people like in Outlook.

It's not a hard thing to implement in the core design template.

Administrators often prevent perfectly good designers (much less, newbie users who need the feature) from enhancing the core design template, rendering the argument "Do it yourself" entirely moot. Often they won't or don't set up email so that such a feature is generally available, either.

That's enough for me to vote in favor. It's a small addition, it brings Notes mail up to Outlook in comparable features, bureaucratic hyperactive overcontrol often won't allow the easy fix.