v11 Migration for Logins and Emails

We have been hearing a lot of questions about the logins and the migration, and thought it might be helpful to provide some Tessitura Network thoughts on best practices based on what we’ve observed during the upgrade process thus far. To us, it seems as though the issue is often about moving the affiliated email addresses related to web logins.  Users rightfully want to take advantage of the new constituent model by having email addresses on the individual records rather than on the household.  The migration issue arises because logins for constituents are generally marked with a Name 1/Name 2 flag of Both which in turn means that the login and email address will remain on the household during the migration because it is not possible to determine which affiliate they belong to.

Below we suggest several options to migrate the Logins and the affiliated emails to the individual records, based on your business practices and nature of your data. 

Manually Post-Upgrade - When logins are not marked as Name 1 or Name 2, it is impossible to systematically tell if a login and attached email belong to the Name 1 or Name 2 constituent.  With that in mind you may opt to leave the logins as-is during the upgrade and migration, and move the emails and logins manually as you are working with records when you are live with Version 11.  To do this in v11, go to the Contact Details tab to the Electronic Addresses page and click on the Transfer Owner icon. This will display a list of primary affiliates for the constituent--select the constituent record where you want to move the email address.  If there is no login attached the email address will be automatically be transferred.  If the email address is attached to the login you will get a pop-up message to confirm that you want to move the email address and its associated login. 

Systematically Using Eaddress Type –The name flag on the login takes precedence over the eaddress type, therefore if you have a login marked as Both it will remain on the household no matter how the eaddress type is mapped.  If you are using eaddress types which are Name1/Name 2 specific (for example: Name 1 Primary Email and Name 2 Primary Email) you may want to update the Name 1/Name 2 flag on the logins to reflect that associated email address type before you upgrade. Then the email address and the login will move to the correct individual as part of the migration.  Below is a simple sample script which will update the Name 1/Name 2 for logins where the associated emails have a specified type.  You will need to update the eaddress type and the N1N2_ind in the code for the correct results.  This script should be updated and run one email address at a time. This type of change should be done just before you stage the migration during the upgrade process and should be attempted in your Test system before being put into production. 

update T_CUST_LOGIN

set n1n2_ind = 1 -- Update to 1 for Name 1 or 2 for Name 2

from T_CUST_LOGIN a

join T_EADDRESS b on b.eaddress_no = a.eaddress_no

where b.eaddress_type = 1 --Update with the id from tr_eaddress_type to be used

Systematically Using the Best Odds – If you would like to have the majority of email addresses on individual records after the migration and you do not have name specific email address types you may still choose to update the login N1N2_ind systematically by deciding that Name 1 is the more active constituent for the bulk of your households.  If you feel that is a fair generalization for your constituents, you may opt to update all the logins which are currently marked as Both to be marked as Name 1.  This will mean that all logins and associated emails currently marked as Both will be moved to the A1 record during the migration.  If you choose this option, you may still have to make manual moves of email addresses as you get in to v11 given that there may be some email addresses which belong to the other individual in the household.  In those cases you may use the Transfer Owner option on the eaddress screen; when transferring from one individual to another in a household make sure that you are on the household record when you make the transfer. 

 update T_CUST_LOGIN

set n1n2_ind = 1

where coalesce(n1n2_ind,3) = 3

We hope that this provides some additional guidance as organizations are making decisions around the migration and upgrade process.

Anna

 

Parents Reply Children
No Data