Processing Email Updates

Keeping member email addresses up-to-date and synchronized in more than 40 list servers, the member database other locations is too big to do manually; it has to be automated.

The next integration issue was email updates. What do you do when a member asks you to change his or her email address? ATLA had approximately 40 member oriented lists. Some members were in a large number of lists. Recall that list servers almost always treat each list as independent so any manual maintenance procedure means going into each list the member is in, and likely finding all lists that a member is in. The Lyris API provides a function for getting all lists that a specific email address is in but not in its administrative interface (or at least not when it mattered to me). At best, if the list server has an email command interface for changing an email address (not a sure thing) and the member knows all their lists, you can use a single email command to change them all. This still requires creating an email with at least one line for every list the member wants to change. Without a suitable email command interface, you'll need to work through multiple levels of administrative menus for each list.

Since list servers are typically built to treat lists as independent of each other, it is not likely that in the near future list servers will provide user interfaces that easily allow a list member to change his or her email address in multiple lists at one time. Requiring a member to change their own email address in two or possibly ten or even fifteen lists is certainly not very user or member friendly when the member is likely to have to go up and down two or more menu/page levels per list.

Quite early I built a function that preceeded the membership eligibility enforcement function described previously and which updated email addresses. If a member registered for ATLA NET, they were required to provide or confirm their email address. We assumed that this was the correct address as it just came from the member. If the new email did not exactly match the old (as stored in the member record), the user was shown both and forced to select one. Their confirmed email address was returned to the central database replacing any email address we already had. Later, these along with all other current data, including email address updates processed by the Membership department staff, were returned to the web site.

The new member file was processed on the web site. For every email address in it, a previous copy of the member file was checked and if the older version had an email address that did not match the new email, a global update was performed changing all locations on the web site where we kept a copy of the email address. These were all the lists (as defined in the private configuration file) and NT user record comment field. API's were used in both cases. For the Lyris lists, fortunately the API contained a function that would return all lists that a specific email address appeared in. This returned list was checked against the configuration file and if the list was to be kept up-to-date, the last name from the member record was compared to the last name in the list server record. This last name check was to prevent switching the email address of multiple members when only one had submitted a change.

At the successful completion of an update run, the old member file was removed. The next member data update would then cause the current member file to be saved as the old member file before being replaced by the new member file.

Whenever an email address was changed a notice was sent to both the old and new email address. Sending to the old email address caused many bad updates to be caught and reversed. The largest source of these were from directory update forms which the Membership department processed in huge quantities over several months. Often email addresses had changed by the time they were entered or sometimes staff could not read or simply miss entered what they thought were corrected email addresses. Sometimes the members provided invalid email addresses.

An organization that is making increasingly heavy use of email addresses in multiple systems must have a fully automated means of updating all stored email addresses, regardless of what system it is stored in. This results in a major labor savings and significant member benefit. Compared to email addresses, names and street addresses are static information that rarely changes. There is probably no piece of data stored on association members that will be more important in the future and no data that changes more frequently than email addresses.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.