We need NXT to match guests who are already on their Hosts RE Relationship Record to that relationship. For example if someone register's for an event and their guest is their spouse, if their spouse is listed correctly on the hosts relationship tile RE does not match the guest to this relationship. This means we do not have the guests title and when you click the spouses name on the relationship it does not show that they have attended the event. This is causing a lot of issues and needs fixing, it seems odd that RE will not check the relationship for the guests name, but knows the relationship is there as if you search on the spouses name the record of the host is located.
I think there is an important piece missing here. For example, if an alum brings a guest to an event, the guest may be given a non-constituent record, but there is currently nothing on that non-constituent record that identifies the alum who brought them, unless you happen to look at the event participation record.
This becomes even more of an issue when there is no event participation to reference. For example, if a relationship is linked to a non-constituent, there is no way to see from the non-constituent's record who they are related to. This can result in multiple non-constituent records being created for the same person because there is no clear connection back to the existing record.
Being able to link the guest to an existing constituent record and/or establish the appropriate relationship from the guest's record would give us a much more complete picture and help prevent duplicate non-constituent records.
We would like to see a feature where if someone names a guest in the registration form, we do not necessarily want to add them as a new record or a relationship on that person's record but just want the guests to be listed as attendees in the event module.
I agree we need both of the comments below added as well!
Spouse records should be able to be matched for events and a nametag selected from a custom addressee/salutation.
Expanding the functionality of Constituent Matching for Participants, to consider non-constituent relationship records (or perhaps allow the option for relationship/nonconstituent matching for Participants) could be beneficial toward a more ideal design here.