In Part 1 of this article series, we looked at how Lotus Notes Calendar and Scheduling (C&S) preferences work and how they affect C&S operations. In Part 2, we turn our attention to C&S components such as Schedule Manager, autoprocessing, and the workflow behind To Do functionality. We also discuss several troubleshooting tips that can help keep your C&S features running smoothly.
As with Part 1 of this series, you don't need to be a C&S expert to understand this article, although some familiarity with basic C&S functionality is helpful. If you haven't already done so, we suggest you read Part 1 before reading this article.
The Schedule Manager server task manages busytime for people, rooms, and resources. It is therefore critical for this task to run on all Domino servers that host calendar users’ mail files. The Schedule Manager maintains a busytime database (busytime.nsf on non-clustered servers, clubusy.nsf on clustered servers) where the schedule information is maintained for all users, rooms, and resources. The busytime database does not require any manual maintenance. By default, only the server has access to the busytime database because data contained in it is not stored in "human readable" format and is accessible only using the published APIs.
Users’ mail files and Resource Reservations databases are automatically registered for monitoring by the Schedule Manager. So when entries are added, removed, or updated on a person’s calendar or in the Resource Reservations database, the Schedule Manager updates the busytime record for that person, room, or resource in the busytime database. It uses the $BusyName and $BusyPriority items on the entries to identify the record to be updated and to determine whether or not it needs to be marked as busy. If you pencil-in an entry or tentatively accept a meeting invitation, the $BusyPriority item has a value of 2. This indicates to the Schedule Manager that you are not to be marked as busy for the duration of that entry. The $BusyPriority item is set to 1 in all other cases.
Figure 1. $BusyName and $BusyPriority items on a calendar entry
If there is no existing busytime record for a person, room, or resource, the Schedule Manager creates one. Along with the information about the existing calendar entries, it saves the work hours of a person, room, or resource (as listed in the calendar profile or room/resource profile) in the busytime record.
All queries for a person’s or resource’s free time are handled by the Domino server, which looks up the busytime data to determine availability for that date and time. All busytime requests are sent to the person's home server (as defined in the current Location document in Lotus Notes). Lotus Domino handles the request for any users it can find locally and then "fans out" the request to the correct server for each remaining user, room, or resource (via the Calendar Connector task). In addition, the server command
tell sched show <personroomorresource> (where <personroomorresource> is the full hierarchical name) returns the busytime information for a person, room, or resource, but only if it can be found locally:
Figure 2. tell sched show server command results
The Schedule Manager performs a validation check at server startup and on a scheduled basis once a day. It confirms that the users, rooms, and resources listed in the busytime database still have the current server (or one of its cluster mates) set as the home server in the Domino Directory user entry and deletes the busytime records for those that no longer do. This ensures the deletion of busytime records for people, rooms, or resources that are no longer in the organization or that have changed home servers. It also confirms that each entry in a busytime record is in sync with the calendar entry in the mail file or Resource Reservations database on the rare chance that some update was missed.
Users who find it counterproductive to sift through endless meeting invitations find the autoprocessing feature invaluable -- something akin to their own personal assistant. Autoprocessing options can be of service in two contexts: responding to meeting invitations and responding to resource requests (as a room or resource owner).
To examine the autoprocessing of meeting invitations, we need to revisit the preferences available on the calendar profile (see Part 1 of this article series), specifically the Calendar & To Do - Autoprocess tab:
Figure 3. Autoprocessing options
Selecting the “Enable automatic responses to meeting invitations" option allows you to specify exactly what you want to do. You can start by selecting which invitations you want autoprocessing to act on. You can choose invitations received by anyone, from a specified list of people, or from anyone but the specified list of people. Next, you can specify the action to be taken upon the qualifying meeting invitations. If you are available for the duration of the meeting, you can instruct the autoprocessor to automatically accept the invitation or delegate it to a specified person. If you are not available for the duration of the meeting, you can instruct the autoprocessor to decline the invitation or to let you decide by not doing anything.
Another autoprocessing option is available when providing other users with access to your mail file via the Access & Delegation tab on the calendar profile. You can choose to automatically forward meeting notices to the chosen persons. This can be especially useful for a manager who prefers that an assistant manage her calendar. You can specify whether or not you want autoforwarding enabled for meetings in which you are an invitee or for meetings chaired by you. For notices marked private, you can select a different course of action. The autoforwarding option is not available if you have selected the "Access is for everyone" option.
Figure 4. Autoforwarding meeting notices
When you create a room or resource in the Resource Reservations database, Autoprocessing is one of the options under Owner restrictions. This option allows you to specify an owner and a list of people who can book the room or resource via autoprocessing. This instructs the autoprocessor to automatically accept or reject reservation requests from the specified list of people, depending on the availability of the requested room or resource. Any requests from people not specified in the list must be manually approved or rejected by the owner of the room or resource. The options Owner only and Specific people also involve some autoprocessing when the owner himself or any of the allowed people request a reservation.
So is there really an autoprocessor task on the server to handle these requests? It is actually the Router task that performs autoprocessing. When delivering meeting invitations, reschedules, cancellation, or reservation requests, the Router checks to see whether or not any autoprocessing needs to be done. If the notice being delivered is to a user, room, or resource that has enabled autoprocessing, the Router acts per the instructions in the calendar profile or the resource document.
In Figure 5, notice that the Router delivers a reservation request to a room or resource and almost immediately delivers a response to the user who requested it that indicates that the request was autoprocessed by the Router:
Figure 5. Autoprocessing a reservation request
To Do entries can be of two types: individual To Dos and group To Dos. Individual To Dos are simple entries with no workflow involved. Group To Dos, on the other hand, are assigned to others and are similar to meetings. The chair assigns the task and the assignees receive a notice in their Inboxes, which they can respond to. The available response options are generally the same as with a meeting invitation: accept, decline, propose new date, delegate, or request more information. The one diferent action is the Completed response. Also, unlike meetings, there is no time component in To Dos because To Dos are assigned tasks that begin on a date and are due to be completed on a date. As a result, there is no busytime applicable to To Dos. If a user has a To Do on her calendar for a particular date, she is not considered busy or unavailable.
After you accept the To Do, the notice is converted to a To Do entry and appears in your mail file’s To Do view. If you have not selected the “Do not display To Do entries in the Calendar" option, it will also be displayed in your mail file’s calendar on the start date (and not the due date).
Repeating To Dos function very similarly to repeating meetings in that a parent document and an instance document are created. Rescheduling a repeating To Do may split the instances into multiple instance documents, depending on which instances were rescheduled.
Figure 6. Repeating To Do entry
To Dos are marked as completed when you select the Mark Completed action. When you mark a To Do item as completed, it shows up as completed in your mail file and sends a notice to the chair. The chair can check the status of the task for all participants via the View Invitee Status action. The status will show as completed for those participants who have marked it as completed. The status of the To Do in the chair’s mail file itself will change to Completed when the chair uses the Mark Completed action.
If you select the option “Allow Notes to update To Do status and dates for incomplete entries" on the Calendar & To Do - To Do tab of the Preferences dialog box, To Do entries that are overdue appear in your calendar on the current date. Figure 7 shows an example of an overdue To Do displayed on the current date of August 31. Its due date is August 26, but it has not been marked as completed.
Figure 7. Overdue To Do
In C&S, there are a number of options available for a user and various workflow scenarios that can play out based on user actions. Therefore, on occasion users may encounter results which are not obvious to them. This can be due to something as simple as an accidentally selected option. Or the cause may be more difficult to trace, such as an inadvertent deletion of some critical documents. Let’s examine a few such situations and discuss ways to arrive at possible solutions.
If you (1) select the autoprocess option to automatically accept meeting invitations if the time is available, and (2) choose the display option to automatically remove meeting invitations from your Inbox after you have responded, you may experience unintended results. When meeting notices arrive and the autoprocessor automatically responds, you may never see the notice in your Inbox because you have chosen not to display meeting notices in the Inbox after they have been responded to. On first pass, it can appear that the meeting notice never arrived, but you can double-check the two options and look in the Meetings view. You should find the notices there.
If the chair has chosen not to receive responses in the delivery options of a meeting invitation, the invitees only see the Add to calendar button, instead of the normal full set of response actions. This is considered a broadcast invitation, and the invitees can just add the entry to their calendars if they are interested or ignore the invitation if they are not. This is also true for invitees who were invited as FYI (Bcc) participants.
However, there can be situations in which there are no action buttons on a meeting notice. The most common cause for this is the deletion of the repeating meeting structure’s parent document in an invitee’s mail file. If such a deletion is attempted in the meetings view, it is explicitly disallowed. But the notice can be deleted from the All Documents view or via custom scripts. It is very important to retain the complete repeating meeting structure because deleting documents from the structure can break workflow.
Customizations to the mail template (such as agents or changes to forms and script libraries), which affect the values of some critical items, can also invalidate notices, rendering them without response buttons. Of particular importance are the $Ref, ApptUNID, StartDateTime, CalendarDateTime, EndDateTime, and RepeatInstanceDates items. The $Ref item is the universal ID of the parent document that is present on all response documents. In the case of a meeting structure, the $Ref assumes more importance because it connects all notices to the parent document. The ApptUNID item has the same value as the $Ref item. This means that the meeting document created on invitee mail files has the same universal ID as the meeting document on the chair’s document. It is easy to understand why changing or deleting either the $Ref or the ApptUNID items breaks the workflow. Similarly, the StartDateTime and EndDateTime items are used as keys to identify the time of the meeting. Changes to these items will also break the workflow. For repeating meetings, the RepeatInstanceDates item is used as a key to locate the repeating instance and is very critical for workflow.
The CalendarDateTime item decides the dates on which the meeting appears in the calendar view. Deleting or changing this item will not only break the workflow, but will also remove the meeting from the calendar view. External factors such as third-party software can also affect some of these items, resulting in broken workflow.
The chair can use the View Invitee Status action to check the response from invitees to her meeting. Chairs on occasion may find that some invitees who have responded are listed as No Response. This is most likely because the responses from the invitees have been deleted. After an invitee responds, the response information is not stored on the meeting document – the invitee’s response notice itself is the record of his response and therefore, deleting it can lead to loss of that information. Lotus Notes 6 offers a deletion confirmation dialog box for C&S entries as a safety measure against such accidental deletions.
Some users find that they have been invited to meetings that they cannot attend because they already have another meeting or appointment for that date and time. Didn’t the chair use due diligence and check the invitees’ busytime when scheduling the meeting? It’s possible that she did and could not get the required information. If the invitee has selected the “No one may see your schedule information" or the “Only the following people or groups may see your schedule information" options, the chair may not have had access to view the busytime information.
And then there are times in which two or more meetings claim to have booked the same room or resource for the same or overlapping time slot. Such double bookings can occur for three known reasons. The most obvious one is that the Schedule Manager was not running at the time one of the reservations was made, so the busytime information for that room or resource was not updated. This can also happen if documents in the busytime database are deleted either accidentally or by some custom process. This causes loss of busytime information because a new busytime record is created for the room or resource. By default, the ACL of the busytime database provides access only to the server as a precaution against such deletions. The third possibility is that the Resource Reservations database has a replica on another server. This is not a supported setup and can lead to situations such as double bookings.
During the course of this article series, we have covered several key components of C&S workflow. While there are numerous different paths and use cases that we have not explicitly mentioned, the basic implementation of workflow is common to all the various possibilities. We hope that the details articulated in this article are beneficial every time you use C&S -- which for many Notes users is literally every day!
Part 1 of this article series looks at how Lotus Notes Calendar and Scheduling (C&S) preferences work and how they affect C&S operations.
- See the earlier developerWorks: Lotus article, "Saving time with Notes 6 Calendar and Scheduling," to learn about all the new C&S features introduced in Lotus Notes 6.
- You can also read about C&S enhancements and all other new functionality in Lotus Notes 6 in the article, "Lotus Notes 6 technical overview."
- In addition, the Notes/Domino product documentation explains in detail how to set up and use all the features C&S has to offer.
- Get involved in the developerWorks community by participating in developerWorks blogs.
- Browse for books on these and other technical topics.
Nagendra Nyamgondalu is an Advisory Software Engineer in the Lotus Notes/Domino group at IBM. The primary purpose of his existence is to fix bugs escalated by customers, mostly related to C&S features in Lotus Notes. Nagen worked as a Lotus Notes consultant for half a decade before joining IBM and enjoys developing applications and tools for his group as a secondary charter. He likes to describe himself as a huge fan of his young daughter, the New England Patriots, and the California weather.