When changing a constituent's address, best practice is to copy the previous address to an alternate before applying the change. This preserves the old address information. The current NXT process simply over-writes the current address. Would like the process to mimic the database view approach.
This is crucial; address history is very important for researchers.
Best news ever that this is planned!!!!!
Great. This feature assist us in identifying duplicate records.
This feature is crucial for consistent, easy data entry!!!!
Preserves address history and prevents bad data from replacing good data. Helps identify duplicates.
This ensures multiple records are not being created for the same individual as well as keeping constituent solicitation preferences accurate in case a duplicate record is created.
This helps with keeping accurate information
This function is crucial to our data integrity. Please add it to webview.
This is necessary to keep our students connected with their parents. Please ensure this is included ASAP!
With the USPS taking so long to return incorrect addresses, I use the previous address on the record to ensure that I am not updating to another incorrect address.
This efficient and essential process is a key element in maintaining accurate address data in database view. Sometimes records with similar names get "tangled," or inaccurate information is entered, and address histories help sort out where errors were made. Other users have provided numerous excellent reasons why this functionality should not be sacrificed. Maintaining address histories is critical; doing so with a minimum of manual data entry (and opportunities for error) is vital.
This is an imperative feature that helps maintain a clean database. It is a simple feature that encourages those who update records to use it and, thus, retain old address history. Any other workaround invites errors, typos, omissions, and missing steps. All of which will result in a "dirty" database.
Having a history of addresses has helped me
1. to identify duplicates,
2. match spouses,
3. link children,
4. identify when an address provided for a donor by a layperson (or looked up online) is an old address and so shouldn't override the address on the record,
5. confirm a deceased donor: an updated address may be one of a child or executor in a different state from the one where the donor resided. I may have a John Smith with an address in Nebraska but the obituary I find for John Smith says he resided in Illinois. Without an address history, I won't know that my John Smith previously resided in Illinois and that his change in address coincides with the date of death mentioned in the obit.
Before my time at my organization, old addresses were not retained and bad addresses were simply erased, even when an updated address was not available. This has resulted in an unknown number of duplicate donors and donors who may be deceased but are not so marked. And without significant effort and time (and who has that?) this situation cannot be remedied.
Please move the feature to WV.
We use this feature for all address updates. Great history when tracking alumni and matching in data appends.
Needed feature. The sales pitch along has been that web view will have all the function of db view. Still hoping.
In db view, the copy to alternate quickly allows us to maintain good data while archiving historical addresses (which can be very critical when trying to determine if you have a match to an existing record).
In db, copy preferred address to alternate creates a new address record on the constituent to archive it. It removed the preferred address indicator, unchecks send mail to this address, adds a Date To address of today, and has an indicator of Alternate. For us, it also marks the Address Type as Previous Address.
It also then keeps the original address for the constituent there for you to change. And the important part of that is that that original address is shared with the spouse.
Using the Copy to Alternate in conjunction with changing the original and choosing to update all records that share the address is a quick and effective way to archive and keep data current.
In web view, if you modify the existing address to previous and then add a new address, the spouse address is still shared to the now old address that you just made previous.
To replicate the actions of db view, you would need to add a new address to the constituent record and manually enter the address which is now old with the previous address indicators and such. Then go and modify the existing address to the new address so that the shared with spouse address is now updated correctly.
I'm perplexed that the status of this idea is "Need Further Info". Please don't reinvent the wheel. This should work the same way as the "Copy preferred address to alternate" functionality in database view. What it does:
Makes an copy of the preferred address (primary address in RE NXT), including date from, source info, seasonal dates, etc.
Changes the address type of the copy to the one set in our Business Rules for copying preferred addresses to alternate (for us, it's "Previous address").
Deactivates the copy by unmarking the Send mail to this address checkbox (or marking the Do not mail box in RE NXT).
Enters today's date in the Valid date to field.
This allows us to then overwrite the preferred address with new address information, confident that the old one has been backed up as an alternate address.
Agree, this is much needed along with the important data management fields of Date From, Date To, Region Code and Source.
To NOT roll this out in webview is short-sighted. It is absolutely best practice to preserve address history and I have relied on it many, many times to merge duplicate records, prevent old addresses from resurfacing, and clarify other mailing list concerns.
Because this is tagged as "Reviewed: need further info", I'm curious to know what further info is desired? If there are specific questions that need answers, I'm sure the community would be happy to provide!
I agree, that we need to be able to do this in NXT. If this is added, we do need to be able to restrict access so everyone does not have the ability to update address information in NXT like what we can do in database view now. At our organization, there are only a few of us that can update address/contact information.
Ron, The request is for a function in NXT that is similar to the the function in the database view for Copy Preferred Address to Alternate. I use this function when we have a new address. I doubt many users use this function just to make a simple edit or correction to an address.
I have a report built on the Date to and the Address type of the former address, which is automatically populated from the "Copy preferred address to alternate". When there are multiple steps in NXT to do the same thing, there is more room for human error.
Yes, you can manually achieve the same as 'copy address to alt', but as Drew mentioned, this falls down for shared addresses. Response from my customer success manager about it, indicating better workflow coming:
It’s the same sort of process, but without the one click option to copy to alternate (yet 😊)
You would need to: