By the time we get to line 95, all the rule parts have been processed and the variable fieldsearch$ contains the completed search string developed from the rules. At line 97 we do the search and then collect the resulting names into a variable-size array with lines 98-104. Finally, in this sub we add to the group any specified values that the group must have.

Returning to the Initialize sub at line 40, we update the Domino Directory Group document. We update the description and note that if there is one already in the directory Group document we won't replace it with a blank value. We then replace the members list, lines 40-48, checking that we don't enter a blank value. This would happen if we had an empty array of new values, because the array would have one, empty entry. At line 49 we log the fact that we might be saving a group with no members--a perfectly valid idea. Finally, between lines 50 and 55, we save the updated Group.

What else could be done?
Writing this article has, to some extent, been an interesting trip back into the past for me. This is because this application was actually written way back in 1997, when Notes 4.5 was the current version, and new at that, which is why the code refers to the Directory as a NAB (Name & Address Book). It was one of my first exercises in writing Lotuscript; indeed, partly as a result of what I learned in writing this application, I was able to pass the Lotuscript exam at Lotusphere 1998 to become a Principal CLP (Certified Lotus Professional).

During the writing of this article, I found one bug and corrected it in the code and have become somewhat painfully aware of shortcomings and of what I would now consider to be rather less than optimal coding techniques in some places. I've also created some ideas for development of this application.

For example, how about sorting the group member list? This would be easy. There are examples of Lotuscript array sorting code in Knowledge Base items 155719 and 160630 (see http://www.lotus.com/support for Knowledge Base). Even better, the R5 Personal Address book has optional sorting of the member list, and it would be easy to borrow the code from there. But it's questionable as to whether sorting the member lists is worth the effort, because people are unlikely to directly refer to the actual contents.

I would also put the agent code into a script library. That would make it easier to reuse it later, especially the sub that creates Groups, which could well be useful in other applications.

Another idea is to manage Groups in the Directory from entries in another database. Many companies keep their corporate phone book in a Domino database so that they can add new fields to it. This is something that isn't encouraged in the Domino Directory. Using another database or even matching another database with the Directory wouldn't be hard to do. Before adding a person to the list, you'd need to check that they actually have a known email address in the Directory or in a secondary directory, so that you don't end up with a group that causes undeliverable mail.