way to avoid auto-assignment of primary addresses, emails

We use RENXT for a lot of event registration, and when a registrant adds their address or email, this new address or email automatically becomes the new primary email address. This may be fine, but it becomes problemmatic when the "new" address/email is actually already in the system, and there's more than one address in there. For example, we have labeled their home address as primary, because that is where they want us to send their mailings. But we also have their work address. When they sign up for an event and use their work address, that new address automatically is assigned "primary" and we can't tell which address used to be the primary address.

  • Guest
  • Aug 1 2024
  • Reviewed: Voting Open
  • Attach files
  • George Weir commented
    13 Sep 17:23

    This is a MAJOR issue to use as well. We use NXT donation forms and registration forms extensively. While I have mapped the contact information (address, email, phone) to specific types related to their origin, I cannot prevent email and phone from being marked as primary (WHICH WE DO NOT WANT!). Many times the information is incorrectly entered into the form and we get an invalid address to replace one that has been carefully cultivated. I NEED CONTROL OVER THIS.

    In the span of one week we have sent several emails to our major donor list with an event registration; several registered with incorrect addresses which by default and no notification became the primary; then a high profile communication was sent and these individuals bounced because the bad address was used.

    We don't have time for the research and clean up of this mess, let alone the major donor impact of flubbed communications.

    The current functional design is woefully lacking needed functionality and should be treated as a bug fix and not a suggestion for improvement. (And this doesn't event touch on the ongoing issues we have with opt-out and hard bounce management). I'm not only willing, I'm BEGGING to be included in functional design sessions where I can provide uses case scenarios to be considered.

  • Heather MacKenzie commented
    20 Aug 17:41

    either figure out how to avoid this and let us choose, or give us the ability to view the history to see what was changed.